Re: bit fields && data tearing
On Thu, 2014-09-04 at 21:06 -0700, Paul E. McKenney wrote:
> On Thu, Sep 04, 2014 at 10:47:24PM -0400, Peter Hurley wrote:
> > Hi James,
> >
> > On 09/04/2014 10:11 PM, James Bottomley wrote:
> > > On Thu, 2014-09-04 at 17:17 -0700, Paul E. McKenney wrote:
> > >> +And there are anti-guarantees:
> > >> +
> > >> + (*) These guarantees do not apply to bitfields, because compilers often
> > >> + generate code to modify these using non-atomic read-modify-write
> > >> + sequences. Do not attempt to use bitfields to synchronize parallel
> > >> + algorithms.
> > >> +
> > >> + (*) Even in cases where bitfields are protected by locks, all fields
> > >> + in a given bitfield must be protected by one lock. If two fields
> > >> + in a given bitfield are protected by different locks, the
> > >> compiler's
> > >> + non-atomic read-modify-write sequences can cause an update to one
> > >> + field to corrupt the value of an adjacent field.
> > >> +
> > >> + (*) These guarantees apply only to properly aligned and sized scalar
> > >> + variables. "Properly sized" currently means "int" and "long",
> > >> + because some CPU families do not support loads and stores of
> > >> + other sizes. ("Some CPU families" is currently believed to
> > >> + be only Alpha 21064. If this is actually the case, a different
> > >> + non-guarantee is likely to be formulated.)
> > >
> > > This is a bit unclear. Presumably you're talking about definiteness of
> > > the outcome (as in what's seen after multiple stores to the same
> > > variable).
> >
> > No, the last conditions refers to adjacent byte stores from different
> > cpu contexts (either interrupt or SMP).
> >
> > > The guarantees are only for natural width on Parisc as well,
> > > so you would get a mess if you did byte stores to adjacent memory
> > > locations.
> >
> > For a simple test like:
> >
> > struct x {
> > long a;
> > char b;
> > char c;
> > char d;
> > char e;
> > };
> >
> > void store_bc(struct x *p) {
> > p->b = 1;
> > p->c = 2;
> > }
> >
> > on parisc, gcc generates separate byte stores
> >
> > void store_bc(struct x *p) {
> >0: 34 1c 00 02 ldi 1,ret0
> >4: 0f 5c 12 08 stb ret0,4(r26)
> >8: 34 1c 00 04 ldi 2,ret0
> >c: e8 40 c0 00 bv r0(rp)
> > 10: 0f 5c 12 0a stb ret0,5(r26)
> >
> > which appears to confirm that on parisc adjacent byte data
> > is safe from corruption by concurrent cpu updates; that is,
> >
> > CPU 0| CPU 1
> > |
> > p->b = 1 | p->c = 2
> > |
> >
> > will result in p->b == 1 && p->c == 2 (assume both values
> > were 0 before the call to store_bc()).
>
> What Peter said. I would ask for suggestions for better wording, but
> I would much rather be able to say that single-byte reads and writes
> are atomic and that aligned-short reads and writes are also atomic.
>
> Thus far, it looks like we lose only very old Alpha systems, so unless
> I hear otherwise, I update my patch to outlaw these very old systems.
This isn't universally true according to the architecture manual. The
PARISC CPU can make byte to long word stores atomic against the memory
bus but not against the I/O bus for instance. Atomicity is a property
of the underlying substrate, not of the CPU. Implying that atomicity is
a CPU property is incorrect.
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: ozwpan: Fix coding style warnings
On Fri, Sep 05, 2014 at 10:08:23PM -0400, anicoara wrote: > The warnings addressed: > 1. Missing a blank line after declarations. > 2. else is not generally useful after a break or return Please break this up into 2 patches, each patch should only do one thing at a time. 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/
[PATCH -v2] f2fs: Remove lock from check_valid_map
Only one bit is read in check_valid_map, holding a lock to do that
doesn't help anything except decreasing performance.
Signed-off-by: Huang, Ying
---
v2: Fixed a build warning.
---
fs/f2fs/gc.c |3 ---
1 file changed, 3 deletions(-)
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -378,14 +378,11 @@ static void put_gc_inode(struct list_hea
static int check_valid_map(struct f2fs_sb_info *sbi,
unsigned int segno, int offset)
{
- struct sit_info *sit_i = SIT_I(sbi);
struct seg_entry *sentry;
int ret;
- mutex_lock(_i->sentry_lock);
sentry = get_seg_entry(sbi, segno);
ret = f2fs_test_bit(offset, sentry->cur_valid_map);
- mutex_unlock(_i->sentry_lock);
return ret;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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-3.16.2 queue (3.16.1+)
On Sun, Sep 07, 2014 at 02:47:55AM +0200, Matt wrote: > On Thu, Aug 28, 2014 at 9:18 PM, Matt wrote: > > On Thu, Aug 28, 2014 at 5:32 PM, Greg KH wrote: > >> On Thu, Aug 28, 2014 at 05:27:27PM +0200, Matt wrote: > >>> On Thu, Aug 28, 2014 at 5:22 PM, Greg KH > >>> wrote: > >>> > On Thu, Aug 28, 2014 at 05:16:58PM +0200, Matt wrote: > >>> >> Hi Greg, > >>> >> > >>> >> > >>> >> please consider adding the following 2 patches to 3.16.2: > >>> >> > >>> >> Jan Kara (1): > >>> >> reiserfs: Fix use after free in journal teardown > >>> >> > >>> >> Jeff Mahoney (1): > >>> >> reiserfs: fix corruption introduced by balance_leaf refactor > >>> >> > >>> >> > >>> >> > >>> >> Reason/Related: > >>> >> > >>> >> https://bugzilla.kernel.org/show_bug.cgi?id=83121 > >>> >> > >>> >> https://bugzilla.kernel.org/show_bug.cgi?id=83321 > >>> >> > >>> >> http://forums.gentoo.org/viewtopic-t-998538-postdays-0-postorder-asc-start-0.html > >>> >> > >>> >> > >>> >> Many thanks in advance > >>> > > >>> > I need git commit ids of these patches in Linus's tree, can you provide > >>> > those please? > >>> > > >>> > thanks, > >>> > > >>> > greg k-h > >>> > >>> > >>> Sure: > >>> > >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d > >>> reiserfs: fix corruption introduced by balance_leaf refactor > >>> > >>> > >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e > >>> reiserfs: Fix use after free in journal teardown > >>> > >>> > >>> > >>> are checkpatch warnings usually also fixed within stable releases ? > >> > >> No, not at all, please read Documentation/stable_kernel_patches.txt for > >> what is acceptable for stable kernel patches. > >> > >> thanks, > >> > >> greg k-h > > > > > > okay, will do > > > > thanks for pointing that out > > > > > > Regards > > > > Matt > > Hi Greg, > > could you please add the above mentioned two patches > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d > reiserfs: fix corruption introduced by balance_leaf refactor > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e > reiserfs: Fix use after free in journal teardown > > in next stable (3.16.3) kernel ? > > more and more people seem to be affected by the data corruption > introduced by the recent changes. > > > Reading through Documentation/stable_kernel_rules.txt, > http://cwe.mitre.org/data/definitions/416.html and > http://www.hpenterprisesecurity.com/vulncat/en/vulncat/cpp/use_after_free.html > > both patches seem relevant enough (concerning data integrity > filesystem-wise and security) to be included for the stable branch I'll queue this up when I get a chance, there are over 300 patches pending for the stable kernels right now :( Also, in the future, always cc sta...@vger.kernel.org for any stable requests so that they don't get lost. 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/
[PATCH] f2fs: Avoid node page to be written twice in gc_node_segment
In gc_node_segment, if node page gc is run concurrently with node page
writeback, and check_valid_map and get_node_page run after page locked
and before cur_valid_map is updated as below, it is possible for the
page to be written twice unnecessarily.
sync_node_pages
try_lock_page
...
check_valid_map f2fs_write_node_page
...
write_node_page
do_write_page
allocate_data_block
...
refresh_sit_entry /* update cur_valid_map */
...
...
unlock_page
get_node_page
...
set_page_dirty
...
f2fs_put_page
unlock_page
This can be solved via calling check_valid_map after get_node_page again.
Signed-off-by: Huang, Ying
---
fs/f2fs/gc.c |6 ++
1 file changed, 6 insertions(+)
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -421,6 +421,12 @@ next_step:
if (IS_ERR(node_page))
continue;
+ /* block may become invalid during get_node_page */
+ if (check_valid_map(sbi, segno, off) == 0) {
+ f2fs_put_page(node_page, 1);
+ continue;
+ }
+
/* set page dirty and write it */
if (gc_type == FG_GC) {
f2fs_wait_on_page_writeback(node_page, NODE);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] f2fs: Remove lock from check_valid_map
Only one bit is read in check_valid_map, holding a lock to do that doesn't help anything except decreasing performance. Signed-off-by: Huang, Ying --- fs/f2fs/gc.c |2 -- 1 file changed, 2 deletions(-) --- a/fs/f2fs/gc.c +++ b/fs/f2fs/gc.c @@ -382,10 +382,8 @@ static int check_valid_map(struct f2fs_s struct seg_entry *sentry; int ret; - mutex_lock(_i->sentry_lock); sentry = get_seg_entry(sbi, segno); ret = f2fs_test_bit(offset, sentry->cur_valid_map); - mutex_unlock(_i->sentry_lock); return ret; } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: LLVMLinux: Add missing abort() for AARCH64
On Sat, Sep 6, 2014 at 7:12 AM, Arnd Bergmann wrote:
> On Friday 05 September 2014 16:21:42 beh...@converseincode.com wrote:
>> From: Mark Charlebois
>>
>> Add missing abort for arch aarch64.
>>
>> This patch makes the aarch64 kernel able to compile with gcc or clang.
>>
>> Signed-off-by: Mark Charlebois
>> Signed-off-by: Behan Webster
>
> You don't describe why this is needed. When does clang emit an abort()
> call? Is that the expected behavior when not linking against a full
> C library?
I just tried recompiling for vexpress64 without the abort call and it
seems the patch is no longer needed. When I added this I mimicked the
behavior of abort for arm which at the time was defined in the kernel
code.
Sorry for the churn.
-Mark
>
>> arch/arm64/kernel/traps.c | 9 +
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>> index 02cd3f0..123cd6e 100644
>> --- a/arch/arm64/kernel/traps.c
>> +++ b/arch/arm64/kernel/traps.c
>> @@ -349,6 +349,15 @@ void __pgd_error(const char *file, int line, unsigned
>> long val)
>> pr_crit("%s:%d: bad pgd %016lx.\n", file, line, val);
>> }
>>
>> +void abort(void)
>> +{
>> + BUG();
>> +
>> + /* if that doesn't kill us, halt */
>> + panic("Oops failed to kill thread");
>> +}
>> +EXPORT_SYMBOL(abort);
>
> I don't see the point in doing both BUG() and panic(). Doesn't panic()
> already print all the information you want in this case?
>
> Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] deb-pkg: Add support for powerpc little endian
On Fri, 2014-09-05 at 09:09 -0300, Thadeu Lima de Souza Cascardo wrote: > On Fri, Sep 05, 2014 at 05:55:18PM +1000, Michael Neuling wrote: > > On Fri, 2014-09-05 at 09:13 +0200, Gabriel Paubert wrote: > > > On Fri, Sep 05, 2014 at 03:28:47PM +1000, Michael Neuling wrote: > > > > The Debian powerpc little endian architecture is called ppc64le. This > > > > > > Huh? ppc64le or ppc64el? > > > > ppc64el. Commit message is wrong. Fixed below. > > > > Mikey > > > > > > What about ppc64? > > Also, I sent that already a month ago. Both linuxppc-dev and Michal > Marek were on cc. > > http://marc.info/?l=linux-kernel=140744360328562=2 Anyone using powerpc (32-bit) will then need to add ppc64 as a foreign architecture before they can install a 64-bit custom kernel. This is fine in principle, except that ppc64 is not an official Debian port and its packages are not mirrored on the same servers. I just tried something similar, which is to add x32 (also unofficial) as an alternate architecture to my biarch x86 system. APT now complains: W: Failed to fetch http://http.debian.net/debian/dists/experimental/InRelease Unable to find expected entry 'main/binary-x32/Packages' in Release file (Wrong sources.list entry or malformed file) W: Failed to fetch http://http.debian.net/debian/dists/sid/Release Unable to find expected entry 'main/binary-x32/Packages' in Release file (Wrong sources.list entry or malformed file) W: Failed to fetch http://http.debian.net/debian/dists/testing/Release Unable to find expected entry 'main/binary-x32/Packages' in Release file (Wrong sources.list entry or malformed file) W: Failed to fetch http://http.debian.net/debian/dists/wheezy/Release Unable to find expected entry 'main/binary-x32/Packages' in Release file (Wrong sources.list entry or malformed file) E: Some index files failed to download. They have been ignored, or old ones used instead. So I think Michael's version, leaving big-endian kernels as powerpc by default, is preferable for now. Ben. -- Ben Hutchings Experience is directly proportional to the value of equipment destroyed. - Carolyn Scheppner signature.asc Description: This is a digitally signed message part
Re: [PATCH] arm64: LLVMLinux: Provide __aeabi_* symbols which are needed for clang
On Sat, Sep 6, 2014 at 7:16 AM, Arnd Bergmann wrote: > > On Friday 05 September 2014 16:23:14 beh...@converseincode.com wrote: > > --- /dev/null > > +++ b/arch/arm64/lib/eabi.c > > @@ -0,0 +1,32 @@ > > +/* > > + * linux/lib/eabi.c > > Please don't put the file names in the files themselves, it's redundant > and in this case actually wrong. Sorry, will fix. > > > + * Copyright (C) 2012 Mark Charlebois > > + */ > > + > > +/* > > + * EABI routines > > Does EABI specify these function names? I would think that they are > just random libgcc (whatever that is called in clang) functions. http://infocenter.arm.com/help/topic/com.arm.doc.ihi0043d/IHI0043D_rtabi.pdf See section 4.3.4 Memory copying, clearing, and setting > > Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: LLVMLinux: Provide __aeabi_* symbols which are needed for clang
On 09/06/14 07:16, Arnd Bergmann wrote: On Friday 05 September 2014 16:23:14 beh...@converseincode.com wrote: --- /dev/null +++ b/arch/arm64/lib/eabi.c @@ -0,0 +1,32 @@ +/* + * linux/lib/eabi.c Please don't put the file names in the files themselves, it's redundant and in this case actually wrong. Will fix. + * Copyright (C) 2012 Mark Charlebois + */ + +/* + * EABI routines Does EABI specify these function names? I would think that they are just random libgcc (whatever that is called in clang) functions. These specialized functions are part of the ABI for the ARM architecture (AEABI). They aren't random. Memcpy and memmove *could* might be satisfied with linker magic instead. But memset uses the reverse parameter list. Behan -- Behan Webster beh...@converseincode.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] crypto, dm: LLVMLinux: Remove VLAIS usage from dm-crypt
On 09/06/14 01:46, Milan Broz wrote:
On 09/06/2014 01:02 AM, beh...@converseincode.com wrote:
From: Jan-Simon Möller
The use of variable length arrays in structs (VLAIS) in the Linux Kernel code
precludes the use of compilers which don't implement VLAIS (for instance the
Clang compiler). This patch instead allocates the appropriate amount of memory
using an char array.
Well, if clang (or C99 code) is now preferred for kernel, why not.
Just please commit the patch series en bloc (together with the patches
removing VLAIS from crypto code you posted to cryptoapi list).
They seemed more separate than that. However, happy to post them as a
patch set.
- struct {
- struct shash_desc desc;
- char ctx[crypto_shash_descsize(lmk->hash_tfm)];
- } sdesc;
+ char sdesc[sizeof(struct shash_desc) +
+ crypto_shash_descsize(lmk->hash_tfm)] CRYPTO_MINALIGN_ATTR;
+ struct shash_desc *desc = (struct shash_desc *)sdesc;
TBH, this looks even more uglier that the previous code :-)
I'm not claiming it's prettier. Merely C99. :)
(But tglx already complained on different patch and I fully agree that crypto
code
should not use this kind of construction in the first place...
It would be very nice to introduce at least some macro hiding these crazy
stack allocations later.)
I actually agree with you and tglx. Will fix.
As I said to tglx, we were asked not to hide things with macro magic in
some of our non-crypto VLAIS removal patches. Happy to use macros in
this case.
Thanks,
Behan
--
Behan Webster
beh...@converseincode.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] security, crypto: LLVMLinux: Remove VLAIS from ima_crypto.c
On 09/06/14 03:11, Thomas Gleixner wrote:
On Fri, 5 Sep 2014, Behan Webster wrote:
On 09/05/14 17:18, Thomas Gleixner wrote:
Signed-off-by: Behan Webster
Signed-off-by: Mark Charlebois
Signed-off-by: Jan-Simon Möller
This SOB chain is completely ass backwards. See Documentation/...
"The Signed-off-by: tag indicates that the signer was involved in the
development of the patch, or that he/she was in the patch's delivery path."
All three of us were involved. Does that not satisfy this rule?
No. Read #12
The sign-off is a simple line at the end of the explanation for the
patch, which certifies that you wrote it or otherwise have the right to
pass it on as an open-source patch.
So the above chain says:
Written-by: Behan
Passed-on-by: Mark
Passed-on-by: Jan
That would be correct if you sent the patch to Mark, Mark sent it to
Jan and Jan finally submitted it to LKML.
I suppose "Reviewed-by" is probably more appropriate for the last 2
then. Will fix.
- struct {
- struct shash_desc shash;
- char ctx[crypto_shash_descsize(tfm)];
- } desc;
+ char desc[sizeof(struct shash_desc) +
+ crypto_shash_descsize(tfm)] CRYPTO_MINALIGN_ATTR;
+ struct shash_desc *shash = (struct shash_desc *)desc;
That anon struct should have never happened in the first place.
Sadly this is a design pattern used in many places through out the kernel, and
appears to be fundamental to the crypto system. I was advised *not* to change
it, so we haven't.
I agree that it's not a good practice.
Not
your problem, but you are not making it any better. You replace open
coded crap with even more unreadable crap.
Whats wrong with
SHASH_DESC_ON_STACK(shash, tfm);
Nothing is wrong with that. I would have actually preferred that. But it would
have fundamentally changed a lot more code.
Errm. Why is
#define SHASH_DESC_ON_STACK(shash, tfm) \
char __shash[sizeof(.)];\
struct shash_desc *shash = (struct shash_desc *) __shash
requiring more fundamental than open coding the same thing a gazillion
times. You still need to change ALL usage sides of the anon struct.
So in fact you could avoid the whole code change by making it
SHASH_DESC_ON_STACK(desc, tfm);
and do the anon struct or a proper struct magic in the macro.
I see. I thought you meant a more fundamental change to the crypto
system API. My misunderstanding.
Ironically we tried to stay away from macros since the last time we
tried to replace VLAIS using macros (we've attempted patches to remove
VLAIS a few times) we were told *not* to hide the implementation with
macro magic. Though, to be fair, we were using more pointer math in our
other macro-based effort, and the non-crypto uses of VLAIS are a lot
more complex to replace.
Like I said I'm actually a fan of hiding ugliness in macros. Will fix.
Again, thanks for the feedback,
Behan
--
Behan Webster
beh...@converseincode.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: OT: Open letter to the Linux World
Am 07.09.2014 01:44, schrieb Lennart Sorensen: So why C++ then if you care about making the code easy to make safe when there are clearly even better options. Why not OCAML or Erlang or one of the other much more robust languages that don't contain all the dangers of C? I would choose Prolog. ;) I don't have to provide an answer because I'm not one of those which have gone out to change this critical part of many systems. My concerns are that C is one of the worst languages for that. I'm not saying that C++ would be the best solution. But I'm pretty sure it would have been a much better solution than C. That means I haven't spend much time (around zero) to think about what an init-replacement has to do and how it would be done best. I'm just very concerned about what happens there. So here are just some thoughts: - Why do you call OCAML or Erlang more robust? Many problems in other languages just aren't well known because they are only used by a few people which don't tell you bad things about the language they've choosen. ;) - Can you achieve all goals with just using OCAML or another language? My experience is that in almost all of those "very well designed languages", you are reaching very often some limits or problems which are very ugly to solve, if it's possible at all to solve them. - How many people do you know which can program (and review) that language? - How robust are the compilers/interpreters? How are they maintained? What happens if you find a bug in the compiler/interpreter? But, as said above, I don't have to provide a solution because I'm not the one who has gone out to change PID 1 into something more complicated. ;) Regards, Alexander Holler -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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-3.16.2 queue (3.16.1+)
On Thu, Aug 28, 2014 at 9:18 PM, Matt wrote: > On Thu, Aug 28, 2014 at 5:32 PM, Greg KH wrote: >> On Thu, Aug 28, 2014 at 05:27:27PM +0200, Matt wrote: >>> On Thu, Aug 28, 2014 at 5:22 PM, Greg KH wrote: >>> > On Thu, Aug 28, 2014 at 05:16:58PM +0200, Matt wrote: >>> >> Hi Greg, >>> >> >>> >> >>> >> please consider adding the following 2 patches to 3.16.2: >>> >> >>> >> Jan Kara (1): >>> >> reiserfs: Fix use after free in journal teardown >>> >> >>> >> Jeff Mahoney (1): >>> >> reiserfs: fix corruption introduced by balance_leaf refactor >>> >> >>> >> >>> >> >>> >> Reason/Related: >>> >> >>> >> https://bugzilla.kernel.org/show_bug.cgi?id=83121 >>> >> >>> >> https://bugzilla.kernel.org/show_bug.cgi?id=83321 >>> >> >>> >> http://forums.gentoo.org/viewtopic-t-998538-postdays-0-postorder-asc-start-0.html >>> >> >>> >> >>> >> Many thanks in advance >>> > >>> > I need git commit ids of these patches in Linus's tree, can you provide >>> > those please? >>> > >>> > thanks, >>> > >>> > greg k-h >>> >>> >>> Sure: >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d >>> reiserfs: fix corruption introduced by balance_leaf refactor >>> >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e >>> reiserfs: Fix use after free in journal teardown >>> >>> >>> >>> are checkpatch warnings usually also fixed within stable releases ? >> >> No, not at all, please read Documentation/stable_kernel_patches.txt for >> what is acceptable for stable kernel patches. >> >> thanks, >> >> greg k-h > > > okay, will do > > thanks for pointing that out > > > Regards > > Matt Hi Greg, could you please add the above mentioned two patches https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=27d0e5bc85f3341b9ba66f0c23627cf9d7538c9d reiserfs: fix corruption introduced by balance_leaf refactor https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=01777836c87081e4f68c4a43c9abe6114805f91e reiserfs: Fix use after free in journal teardown in next stable (3.16.3) kernel ? more and more people seem to be affected by the data corruption introduced by the recent changes. Reading through Documentation/stable_kernel_rules.txt, http://cwe.mitre.org/data/definitions/416.html and http://www.hpenterprisesecurity.com/vulncat/en/vulncat/cpp/use_after_free.html both patches seem relevant enough (concerning data integrity filesystem-wise and security) to be included for the stable branch Thanks & Regards Matt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: staging: rtl8723au: Fix '"(foo*)" should be "(foo *)"' errors
Fix checkpatch.pl '"(foo*)" should be "(foo *)"' errors
Signed-off-by: Greg Donald
---
drivers/staging/rtl8723au/core/rtw_ap.c| 14 --
drivers/staging/rtl8723au/core/rtw_cmd.c | 6 +++---
drivers/staging/rtl8723au/core/rtw_mlme.c | 4 ++--
drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 12 ++--
drivers/staging/rtl8723au/core/rtw_wlan_util.c | 2 +-
5 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/drivers/staging/rtl8723au/core/rtw_ap.c
b/drivers/staging/rtl8723au/core/rtw_ap.c
index 888abeb..be85b7e 100644
--- a/drivers/staging/rtl8723au/core/rtw_ap.c
+++ b/drivers/staging/rtl8723au/core/rtw_ap.c
@@ -143,7 +143,7 @@ static void update_BCNTIM(struct rtw_adapter *padapter)
*dst_ie++ = 0;
if (tim_ielen == 4) {
- *dst_ie++ = *(u8*)_bitmap_le;
+ *dst_ie++ = *(u8 *)_bitmap_le;
} else if (tim_ielen == 5) {
memcpy(dst_ie, _bitmap_le, 2);
dst_ie+= 2;
@@ -463,7 +463,8 @@ static void update_bmc_sta(struct rtw_adapter *padapter)
psta->ieee8021x_blocked = 0;
- memset((void*)>sta_stats, 0, sizeof(struct
stainfo_stats));
+ memset((void *)>sta_stats, 0,
+ sizeof(struct stainfo_stats));
/* prepare for add_RATid23a */
supportRateNum =
rtw_get_rateset_len23a((u8*)_network->SupportedRates);
@@ -599,7 +600,7 @@ void update_sta_info23a_apmode23a(struct rtw_adapter
*padapter, struct sta_info
/* todo: init other variables */
- memset((void*)>sta_stats, 0, sizeof(struct stainfo_stats));
+ memset((void *)>sta_stats, 0, sizeof(struct stainfo_stats));
spin_lock_bh(>lock);
psta->state |= _FW_LINKED;
@@ -1021,7 +1022,7 @@ int rtw_check_beacon_data23a(struct rtw_adapter *padapter,
pbss_network->Length = get_wlan_bssid_ex_sz(pbss_network);
/* issue beacon to start bss network */
- start_bss_network(padapter, (u8*)pbss_network);
+ start_bss_network(padapter, (u8 *)pbss_network);
/* alloc sta_info for ap itself */
psta = rtw_get_stainfo23a(>stapriv, pbss_network->MacAddress);
@@ -1674,7 +1675,8 @@ u8 ap_free_sta23a(struct rtw_adapter *padapter, struct
sta_info *psta, bool acti
/* clear cam entry / key */
/* clear_cam_entry23a(padapter, (psta->mac_id + 3)); */
- rtw_clearstakey_cmd23a(padapter, (u8*)psta, (u8)(psta->mac_id + 3),
true);
+ rtw_clearstakey_cmd23a(padapter, (u8 *)psta, (u8)(psta->mac_id + 3),
+ true);
spin_lock_bh(>lock);
psta->state &= ~_FW_LINKED;
@@ -1829,7 +1831,7 @@ void rtw_ap_restore_network(struct rtw_adapter *padapter)
set_channel_bwmode23a(padapter, pmlmeext->cur_channel,
pmlmeext->cur_ch_offset, pmlmeext->cur_bwmode);
- start_bss_network(padapter, (u8*)>cur_network.network);
+ start_bss_network(padapter, (u8 *)>cur_network.network);
if (padapter->securitypriv.dot11PrivacyAlgrthm ==
WLAN_CIPHER_SUITE_TKIP ||
diff --git a/drivers/staging/rtl8723au/core/rtw_cmd.c
b/drivers/staging/rtl8723au/core/rtw_cmd.c
index 71a0878..9fd9b10 100644
--- a/drivers/staging/rtl8723au/core/rtw_cmd.c
+++ b/drivers/staging/rtl8723au/core/rtw_cmd.c
@@ -677,7 +677,7 @@ int rtw_setstakey_cmd23a(struct rtw_adapter *padapter, u8
*psta, u8 unicast_key)
struct set_stakey_rsp *psetstakey_rsp = NULL;
struct mlme_priv *pmlmepriv = >mlmepriv;
struct security_priv *psecuritypriv = >securitypriv;
- struct sta_info *sta = (struct sta_info*)psta;
+ struct sta_info *sta = (struct sta_info *)psta;
int res = _SUCCESS;
ph2c = kzalloc(sizeof(struct cmd_obj), GFP_KERNEL);
@@ -1493,7 +1493,7 @@ void rtw_setstaKey_cmdrsp_callback23a(struct rtw_adapter
*padapter,
struct sta_info *psta;
pstapriv = >stapriv;
- psetstakey_rsp = (struct set_stakey_rsp*) (pcmd->rsp);
+ psetstakey_rsp = (struct set_stakey_rsp *) (pcmd->rsp);
psta = rtw_get_stainfo23a(pstapriv, psetstakey_rsp->addr);
if (!psta) {
@@ -1518,7 +1518,7 @@ void rtw_setassocsta_cmdrsp_callback23a(struct
rtw_adapter *padapter,
struct sta_info *psta;
passocsta_parm = (struct set_assocsta_parm *)(pcmd->parmbuf);
- passocsta_rsp = (struct set_assocsta_rsp*) (pcmd->rsp);
+ passocsta_rsp = (struct set_assocsta_rsp *) (pcmd->rsp);
psta = rtw_get_stainfo23a(pstapriv, passocsta_parm->addr);
if (psta == NULL) {
diff --git a/drivers/staging/rtl8723au/core/rtw_mlme.c
b/drivers/staging/rtl8723au/core/rtw_mlme.c
index 57f93f5..099ef8c 100644
--- a/drivers/staging/rtl8723au/core/rtw_mlme.c
+++ b/drivers/staging/rtl8723au/core/rtw_mlme.c
@@ -1256,7 +1256,7 @@ void rtw_stassoc_event_callback23a(struct rtw_adapter
*adapter, const u8 *pbuf)
{
struct sta_info *psta;
struct mlme_priv
[PATCH] Removing textsearch_put reference from the comments.
There is no function named textsearch_put(). Removing it from the comments to avoid misunderstanding. Textsearch prepare no longer needs textsearch_put. Signed-off-by: Raphael Silva --- lib/textsearch.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/lib/textsearch.c b/lib/textsearch.c index 0c7e9ab..0b79908 100644 --- a/lib/textsearch.c +++ b/lib/textsearch.c @@ -249,9 +249,7 @@ EXPORT_SYMBOL(textsearch_find_continuous); * @flags: search flags * * Looks up the search algorithm module and creates a new textsearch - * configuration for the specified pattern. Upon completion all - * necessary refcnts are held and the configuration must be put back - * using textsearch_put() after usage. + * configuration for the specified pattern. * * Note: The format of the pattern may not be compatible between * the various search algorithms. -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OT: Open letter to the Linux World
On Sat, Sep 06, 2014 at 10:01:29PM +0200, Alexander Holler wrote:
> I've brought up the critics about using C in a critical and very
> security sensitive piece of software in userland, so I've decided a
> bit more explanations might make sense.
>
> First, as you don't seem to have noticed or you don't know or you
> ignore the difference, let me repeat that this thread is about a
> piece of SW which runs in userland. So, please, keep away with any
> comments from Linus where he talks about kernelspace. I'm pretty
> sure he knows the difference.
>
> Now let me bring up a very small piece of code which you can find in
> a similiar fashion in almost every piece of software which gets in
> contact with strings. And not just in one place or function, but in
> dozens or even hundred of places (inline, not in functions) in one
> project.
>
> First in C++:
>
> void foo_bar(const std::string& foo, const std::string& bar,
> std::string& foobar)
> {
> foobar = foo + bar;
> }
>
> For those which don't know C++, this concatenates the two strings
> named foo and bar and puts the result into foobar.
>
> Now an example how you would have to do that in C:
>
> char *foo_bar(const char *foo, const char *bar)
> {
> char *foobar = malloc(strlen(foo) + strlen(bar));
>
> strcpy(foobar, foo);
> strcat(foobar, bar);
>
> return foobar;
> }
>
> Do you see the difference and spot all the problems?
>
> First I've though about not posting the answer to see the response,
> but that would just have ended up with a lot of people calling me a
> fool and/or assuming I can't write proper C. And it bears the
> problem that some inexperienced people might copy and paste and use
> it.
>
> So at first: THE ABOVE EXAMPLE IN C IS BROKEN.
>
> The very first problem is that foobar is allocated with the wrong
> size, because it doesn't take care of the terminating null byte. A
> very common problem already found at uncountable places.
>
> But there are several more problems:
>
> - What happens if foo or bar isn't terminated with a null byte?
>
> - What happens if malloc fails?
>
> - Who is the owner of foo, bar and/or foobar? Does the caller still
> owns foo and bar afterwards? Will the caller own foobar? (That means
> who is repsonsible to free foo, bar and foobar if they aren't used
> anymore).
>
> So now we extend the above C example:
>
> char *foo_bar(const char *foo, const char *bar)
> {
> char *foobar;
>
> if (!foo || !bar)
> return NULL;
>
> foobar = malloc(strlen(foo) + strlen(bar) + 1);
>
> if (!foobar)
> return NULL;
>
> strcpy(foobar, foo);
> strcat(foobar, bar);
>
> return foobar;
> }
>
> This has still some problems. First, the caller has to check if
> foo_bar() hasn't returned NULL. A very common bug already found in
> uncountable places too.
>
> Next, there is still the unsolvable problem about what happens if
> foo or bar isn't terminated with a null byte (in other words they
> aren't C strings).
> So you have to check all callers up to the source of foo and bar to
> be sure the program doesn't crash in the possible far far away place
> called foo_bar().
>
> And still no comment about ownership. That means someone who just
> looks at the prototype or sees a call of foo_bar() somewhere has no
> idea about the ownership of foo, bar and the returned foobar without
> a comment.
>
> So just this very simple functionality about string handling in C
> already contains several still open questions and is 17 lines long
> which have to be reviewed very carefull (e.g. to not miss the
> off-by-one bug).
> Compare this with the 4 lines in C++ which are almost impossible to
> do or to use wrong.
>
> And, again, this thread is about a piece of software which runs with
> process ID 1, wants to control the whole system and owns all
> permissions to modify the system in almost every possible way. It
> doesn't run as some user with restricted permissions or in chroot
> or something similar. Some parts might do, but for sure not all
> (read again the above "far far away").
>
> And now some stats. I've just checked out systemd:
>
> git grep -E "strcat|strncat|strcpy|strncpy|strlen" | wc -l
> 570
>
> git grep -E "strcat|strncat|strcpy|strncpy|memcpy|strlen" | wc -l
> 850
>
> Ok, not every of those places might be part of pid 1. And several
> places are trivial calls like strlen("ATTR"), but it gives an idea
> about how many places do exist in systemd which might contain a
> problem wich isn't trivial to spot.
>
> And regardless how clever and experienced these people are which are
> writing this piece of software, everyone is prone to do e.g. such an
> off-by-one bug.
> Maybe he writes the piece of code after having worked 12 hours,
> maybe he got interrupted while writing the code and continued it a
> day later, maybe it's full moon or maybe his last meal wasn't like
> it should have been.
>
> Whatever.
>
> This means,
[PATCH] drivers: staging: rtl8821ae: Fix '"(foo*)" should be "(foo *)"' errors
Fix checkpatch.pl '"(foo*)" should be "(foo *)"' errors
Signed-off-by: Greg Donald
---
drivers/staging/rtl8821ae/base.h | 26 +++---
drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.c | 8 +++
drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.h | 4 ++--
drivers/staging/rtl8821ae/core.c | 6 ++---
drivers/staging/rtl8821ae/debug.h | 2 +-
drivers/staging/rtl8821ae/pci.c| 6 ++---
drivers/staging/rtl8821ae/rtl8821ae/def.h | 2 +-
drivers/staging/rtl8821ae/rtl8821ae/dm.c | 2 +-
8 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/rtl8821ae/base.h b/drivers/staging/rtl8821ae/base.h
index 629d14f..cf166f3 100644
--- a/drivers/staging/rtl8821ae/base.h
+++ b/drivers/staging/rtl8821ae/base.h
@@ -78,33 +78,33 @@ enum ap_peer {
SET_BITS_TO_LE_2BYTE(_hdr, 8, 1, _val)
#define SET_80211_PS_POLL_AID(_hdr, _val) \
- WRITEEF2BYTE(((u8*)(_hdr))+2, _val)
+ WRITEEF2BYTE(((u8 *)(_hdr))+2, _val)
#define SET_80211_PS_POLL_BSSID(_hdr, _val)\
- CP_MACADDR(((u8*)(_hdr))+4, (u8*)(_val))
+ CP_MACADDR(((u8 *)(_hdr))+4, (u8 *)(_val))
#define SET_80211_PS_POLL_TA(_hdr, _val) \
- CP_MACADDR(((u8*)(_hdr))+10, (u8*)(_val))
+ CP_MACADDR(((u8 *)(_hdr))+10, (u8 *)(_val))
#define SET_80211_HDR_DURATION(_hdr, _val) \
- WRITEEF2BYTE((u8*)(_hdr)+FRAME_OFFSET_DURATION, _val)
+ WRITEEF2BYTE((u8 *)(_hdr)+FRAME_OFFSET_DURATION, _val)
#define SET_80211_HDR_ADDRESS1(_hdr, _val) \
- CP_MACADDR((u8*)(_hdr)+FRAME_OFFSET_ADDRESS1, (u8*)(_val))
+ CP_MACADDR((u8 *)(_hdr)+FRAME_OFFSET_ADDRESS1, (u8 *)(_val))
#define SET_80211_HDR_ADDRESS2(_hdr, _val) \
- CP_MACADDR((u8*)(_hdr)+FRAME_OFFSET_ADDRESS2, (u8*)(_val))
+ CP_MACADDR((u8 *)(_hdr)+FRAME_OFFSET_ADDRESS2, (u8 *)(_val))
#define SET_80211_HDR_ADDRESS3(_hdr, _val) \
- CP_MACADDR((u8*)(_hdr)+FRAME_OFFSET_ADDRESS3, (u8*)(_val))
+ CP_MACADDR((u8 *)(_hdr)+FRAME_OFFSET_ADDRESS3, (u8 *)(_val))
#define SET_80211_HDR_FRAGMENT_SEQUENCE(_hdr, _val) \
- WRITEEF2BYTE((u8*)(_hdr)+FRAME_OFFSET_SEQUENCE, _val)
+ WRITEEF2BYTE((u8 *)(_hdr)+FRAME_OFFSET_SEQUENCE, _val)
#define SET_BEACON_PROBE_RSP_TIME_STAMP_LOW(__phdr, __val) \
- WRITEEF4BYTE(((u8*)(__phdr)) + 24, __val)
+ WRITEEF4BYTE(((u8 *)(__phdr)) + 24, __val)
#define SET_BEACON_PROBE_RSP_TIME_STAMP_HIGH(__phdr, __val) \
- WRITEEF4BYTE(((u8*)(__phdr)) + 28, __val)
+ WRITEEF4BYTE(((u8 *)(__phdr)) + 28, __val)
#define SET_BEACON_PROBE_RSP_BEACON_INTERVAL(__phdr, __val) \
- WRITEEF2BYTE(((u8*)(__phdr)) + 32, __val)
+ WRITEEF2BYTE(((u8 *)(__phdr)) + 32, __val)
#define GET_BEACON_PROBE_RSP_CAPABILITY_INFO(__phdr) \
- READEF2BYTE(((u8*)(__phdr)) + 34)
+ READEF2BYTE(((u8 *)(__phdr)) + 34)
#define SET_BEACON_PROBE_RSP_CAPABILITY_INFO(__phdr, __val) \
- WRITEEF2BYTE(((u8*)(__phdr)) + 34, __val)
+ WRITEEF2BYTE(((u8 *)(__phdr)) + 34, __val)
#define MASK_BEACON_PROBE_RSP_CAPABILITY_INFO(__phdr, __val) \
SET_BEACON_PROBE_RSP_CAPABILITY_INFO(__phdr, \
(GET_BEACON_PROBE_RSP_CAPABILITY_INFO(__phdr) & (~(__val
diff --git a/drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.c
b/drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.c
index 01f5a74..5fbdf33 100644
--- a/drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.c
+++ b/drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.c
@@ -285,10 +285,10 @@ static bool halbtc_get(void *void_btcoexist, u8 get_type,
void *out_buf)
struct rtl_phy *rtlphy = &(rtlpriv->phy);
struct rtl_mac *mac = rtl_mac(rtlpriv);
struct rtl_hal *rtlhal = rtl_hal(rtlpriv);
- bool *bool_tmp = (bool*)out_buf;
- int *s32_tmp = (int*)out_buf;
- u32 *u32_tmp = (u32*)out_buf;
- u8 *u8_tmp = (u8*)out_buf;
+ bool *bool_tmp = (bool *)out_buf;
+ int *s32_tmp = (int *)out_buf;
+ u32 *u32_tmp = (u32 *)out_buf;
+ u8 *u8_tmp = (u8 *)out_buf;
bool tmp = false;
diff --git a/drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.h
b/drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.h
index fd233cc..2d4b4ef 100644
--- a/drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.h
+++ b/drivers/staging/rtl8821ae/btcoexist/halbtcoutsrc.h
@@ -109,7 +109,7 @@ extern u32 btc_dbg_type[];
do {\
if(unlikely(btc_dbg_type[dbgtype] & dbgflag)) { \
int __i;\
- u8* __ptr = (u8*)_Ptr; \
+ u8 *__ptr = (u8 *)_Ptr; \
printk printstr;\
for( __i = 0; __i < 6; __i++ ) \
printk("%02X%s", __ptr[__i],
Re: [PATCH] pci/probe: Enable CRS for Intel Haswell root ports
On Sat, Sep 6, 2014 at 2:21 PM, Bjorn Helgaas wrote: > > But as you point out, we don't see the "not responding" message. We > only print that if we read 0x0001 (device/vendor ID). But lspci > claims the vendor:device ID is 0001:8168. So my new theory is: [snip] Sounds like a very reasonable theory and quite possible. And if Josh actually still has the hardware, it would be lovely to hear the results. Josh? Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] virtio_blk: merge S/G list entries by default
Most virtio setups have a fairly limited number of ring entries available. Enable S/G entry merging by default to fit into less of them. This restores the behavior at time of the virtio-blk blk-mq conversion, which was changed by commit "block: add queue flag for disabling SG merging" which made the behavior optional, but didn't update the existing drivers to keep their previous behavior. Signed-off-by: Christoph Hellwig --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 0a58140..311b857 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -634,7 +634,7 @@ static int virtblk_probe(struct virtio_device *vdev) vblk->tag_set.ops = _mq_ops; vblk->tag_set.queue_depth = virtblk_queue_depth; vblk->tag_set.numa_node = NUMA_NO_NODE; - vblk->tag_set.flags = BLK_MQ_F_SHOULD_MERGE; + vblk->tag_set.flags = BLK_MQ_F_SHOULD_MERGE | BLK_MQ_F_SG_MERGE; vblk->tag_set.cmd_size = sizeof(struct virtblk_req) + sizeof(struct scatterlist) * sg_elems; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] block: remove artifical max_hw_sectors cap
Set max_sectors to the value the drivers provides as hardware limit by
default. Linux had proper I/O throttling for a long time and doesn't
rely on a artifically small maximum I/O size anymore. By not limiting
the I/O size by default we remove an annoying tuning step required for
most Linux installation.
Note that both the user, and if absolutely required the driver can still
impose a limit for FS requests below max_hw_sectors_kb.
Signed-off-by: Christoph Hellwig
---
block/blk-settings.c | 4 +---
drivers/block/aoe/aoeblk.c | 2 +-
include/linux/blkdev.h | 1 -
3 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/block/blk-settings.c b/block/blk-settings.c
index f1a1795..f52c223 100644
--- a/block/blk-settings.c
+++ b/block/blk-settings.c
@@ -257,9 +257,7 @@ void blk_limits_max_hw_sectors(struct queue_limits *limits,
unsigned int max_hw_
__func__, max_hw_sectors);
}
- limits->max_hw_sectors = max_hw_sectors;
- limits->max_sectors = min_t(unsigned int, max_hw_sectors,
- BLK_DEF_MAX_SECTORS);
+ limits->max_sectors = limits->max_hw_sectors = max_hw_sectors;
}
EXPORT_SYMBOL(blk_limits_max_hw_sectors);
diff --git a/drivers/block/aoe/aoeblk.c b/drivers/block/aoe/aoeblk.c
index dd73e1f..46c282f 100644
--- a/drivers/block/aoe/aoeblk.c
+++ b/drivers/block/aoe/aoeblk.c
@@ -395,7 +395,7 @@ aoeblk_gdalloc(void *vp)
WARN_ON(d->flags & DEVFL_TKILL);
WARN_ON(d->gd);
WARN_ON(d->flags & DEVFL_UP);
- blk_queue_max_hw_sectors(q, BLK_DEF_MAX_SECTORS);
+ blk_queue_max_hw_sectors(q, 1024);
q->backing_dev_info.name = "aoe";
q->backing_dev_info.ra_pages = READ_AHEAD / PAGE_CACHE_SIZE;
d->bufpool = mp;
diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
index 518b465..7e3c172 100644
--- a/include/linux/blkdev.h
+++ b/include/linux/blkdev.h
@@ -1192,7 +1192,6 @@ extern int blk_verify_command(unsigned char *cmd, fmode_t
has_write_perm);
enum blk_default_limits {
BLK_MAX_SEGMENTS= 128,
BLK_SAFE_MAX_SECTORS= 255,
- BLK_DEF_MAX_SECTORS = 1024,
BLK_MAX_SEGMENT_SIZE= 65536,
BLK_SEG_BOUNDARY_MASK = 0xUL,
};
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: /proc//exe symlink behavior change in >=3.15.
On Sat, Sep 6, 2014 at 11:44 PM, Piotr Karbowski wrote: > Hi, > > Starting with kernel 3.15 the 'exe' symlink under /proc// acts diffrent > than it used to in all the pre-3.15 kernels. > > The usecase: > > run /root/testbin (app that just sleeps) > cp /root/testbin /root/testbin.new > mv /root/testbin.new /root/testbin > ls -al /proc/`pidof testbin`/exe > > <=3.14: /root/testbin (deleted) >>=3.15: /root/testbin.new (deleted) > > Was the change intentional? It does render my system unusable and I failed > to find a information about such change in the ChangeLog. Can you please find the offending commit? Using an automated bisect run this should be easily doable. -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
HELLO
hello, my name is Miss Rita please i am writing this message to you with tears and a heavy load in my heart please i see you as a good person after looking through your profile, please i will like to have a contact with you it is very necessary please, please for the Love of God i need to talk to you please, i will wait for your reply as soon as you get this mail so that i will explain to you why i mailed you and tell you all about myself please -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
/proc//exe symlink behavior change in >=3.15.
Hi, Starting with kernel 3.15 the 'exe' symlink under /proc// acts diffrent than it used to in all the pre-3.15 kernels. The usecase: run /root/testbin (app that just sleeps) cp /root/testbin /root/testbin.new mv /root/testbin.new /root/testbin ls -al /proc/`pidof testbin`/exe <=3.14: /root/testbin (deleted) >=3.15: /root/testbin.new (deleted) Was the change intentional? It does render my system unusable and I failed to find a information about such change in the ChangeLog. -- Piotr. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] pci/probe: Enable CRS for Intel Haswell root ports
[+cc Josh] On Tue, Sep 2, 2014 at 1:30 PM, Linus Torvalds wrote: > On Mon, Sep 1, 2014 at 9:14 PM, Bjorn Helgaas wrote: >> >> I'm not a fan of adding a whitelist for devices that work correctly. >> I don't think that's a maintainable solution. Since we haven't had >> many systems yet that care about CRS, some kind of "enable CRS on >> machines newer than X" might work. > > I'd suggest trying to just enable CRS unconditionally (ie revert my > old commit ad7edfe04908). We've done other changes in this area since, > and in particular, it's entirely possible that the original problem we > had doesn't even trigger any more. > > In particular, looking at one of the old reports, I don't see that > "Device %04x:%02x:%02x.%d not responding" warning that we *should* > have triggered in pci_scan_device(). So I wonder if we had some case > that read the vendor ID without that whole loop, and that _that_ was > our fundamental problem. > > It would be great if somebody could test with the old hardware that > triggered the problem originally, but those reports are from 2007, so > it might be hard to find anything relevant today. But trying to just > go back to unconditionally enabling CRS (say, in 3.18-rc1) and seeing > if anybody hollers, might just be the right approach. Josh actually does still have the hardware, so he *might* be able to test it. My original theory was that the device didn't advertise CRS SV capability, and something went wrong when we enabled it anyway. But lspci incorrectly decoded CRS SV from the RootCap, so we don't know whether it was advertised, and I didn't have an explanation for what could be going wrong if we enabled it. But as you point out, we don't see the "not responding" message. We only print that if we read 0x0001 (device/vendor ID). But lspci claims the vendor:device ID is 0001:8168. So my new theory is: - Root Port issues Configuration Request to read four bytes at 0x0. - Device generates Completion with Config Request Retry Status, returning data of 10ec:8168. - Root Port (with SV disabled) retries the Config Request until it succeeds, then returns 0x816810ec. In this configuration, these boards work correctly today. - Root Port (with SV enabled) replaces Vendor ID with 0001 but fails to replace Device ID with , so it returns 0x81680001. This is a hardware defect per PCIe r3.0, sec 2.3.2. - Linux sees 0x81680001, but we're looking for 0x0001, so we think everything's fine and we don't retry or warn about it. So I think we should try two patches: 1) Enable CRS SV if support is advertised, i.e., Rajat's current patch 2) Change pci_bus_read_dev_vendor_id() to test only the two bytes of the vendor ID and ignore the device ID I suspect that if Josh tested patch 1) alone, he would see the same problem he originally reported, and that if he tested both together, it would work correctly. Obviously, if it works out this way, I would apply them in the reverse order to avoid a bisection problem. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] eeepc-laptop: remove possible use of uninitialized value
On Friday, September 05, 2014 07:17:57 PM Darren Hart wrote:
> On Thu, Sep 04, 2014 at 09:08:08AM +0200, Paul Bolle wrote:
> > On Thu, 2014-09-04 at 00:53 +0200, Frans Klaver wrote:
> > > In store_sys_acpi, if count equals zero, or parse_arg()s sscanf call
> > > fails, 'value' remains possibly uninitialized. In that case 'value'
> > > shouldn't be used to produce the store_sys_acpi()s return value.
> > >
> > > Only test the return value of set_acpi() if we can actually call it.
> > > Return rv otherwise.
> > >
> > > Signed-off-by: Frans Klaver
> > > ---
> > > drivers/platform/x86/eeepc-laptop.c | 8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/drivers/platform/x86/eeepc-laptop.c
> > > b/drivers/platform/x86/eeepc-laptop.c
> > > index bd533c2..41f12ba 100644
> > > --- a/drivers/platform/x86/eeepc-laptop.c
> > > +++ b/drivers/platform/x86/eeepc-laptop.c
> > > @@ -279,10 +279,10 @@ static ssize_t store_sys_acpi(struct device *dev,
> > > int cm,
> > > int rv, value;
> > >
> > > rv = parse_arg(buf, count, );
> > > - if (rv > 0)
> > > - value = set_acpi(eeepc, cm, value);
> > > - if (value < 0)
> > > - return -EIO;
> > > + if (rv > 0) {
> > > + if (set_acpi(eeepc, cm, value) < 0)
> > > + return -EIO;
> > > + }
> > > return rv;
> > > }
> > >
> >
> > The warning that this code (currently) generated triggered me to submit
> > https://lkml.org/lkml/2014/7/1/150 , which uses a different approach to
> > get rid of it. I received no reactions so far. Here's that patch again:
>
> Thanks for resending.
>
> >
> > >8
> > From: Paul Bolle
> > Subject: [PATCH] eeepc-laptop: simplify parse_arg()
> >
> > parse_arg() has three possible return values:
> > -EINVAL if sscanf(), in short, fails;
> > zero if "count" is zero; and
> > "count" in all other cases
> >
> > But "count" will never be zero. See, parse_arg() is called by the
> > various store functions. And the callchain of these functions starts
> > with sysfs_kf_write(). And that function checks for a zero "count". So
> > we can stop checking for a zero "count", drop the "count" argument
> > entirely, and transform parse_arg() into a function that returns zero on
> > success or a negative error. That, in turn, allows to make those store
> > functions just return "count" on success. The net effect is that the
> > code becomes a bit easier to understand.
> >
>
> Seems reasonable.
>
> > A nice side effect is that this GCC warning is silenced too:
> > drivers/platform/x86/eeepc-laptop.c: In function ‘store_sys_acpi’:
> > drivers/platform/x86/eeepc-laptop.c:279:10: warning: ‘value’ may be
> > used uninitialized in this function [-Wmaybe-uninitialized]
> > int rv, value;
> >
> > Which is, of course, the reason to have a look at parse_arg().
> >
> > Signed-off-by: Paul Bolle
> > ---
> > drivers/platform/x86/eeepc-laptop.c | 34 +-
> > 1 file changed, 17 insertions(+), 17 deletions(-)
> >
> > diff --git a/drivers/platform/x86/eeepc-laptop.c
> > b/drivers/platform/x86/eeepc-laptop.c
> > index bd533c22be57..78515b850165 100644
> > --- a/drivers/platform/x86/eeepc-laptop.c
> > +++ b/drivers/platform/x86/eeepc-laptop.c
> > @@ -263,13 +263,11 @@ static int acpi_setter_handle(struct eeepc_laptop
> > *eeepc, int cm,
> > /*
> > * Sys helpers
> > */
> > -static int parse_arg(const char *buf, unsigned long count, int *val)
> > +static int parse_arg(const char *buf, int *val)
> > {
> > - if (!count)
> > - return 0;
> > if (sscanf(buf, "%i", val) != 1)
> > return -EINVAL;
> > - return count;
> > + return 0;
> > }
> >
> > static ssize_t store_sys_acpi(struct device *dev, int cm,
> > @@ -278,12 +276,13 @@ static ssize_t store_sys_acpi(struct device *dev, int
> > cm,
> > struct eeepc_laptop *eeepc = dev_get_drvdata(dev);
> > int rv, value;
> >
> > - rv = parse_arg(buf, count, );
> > - if (rv > 0)
> > - value = set_acpi(eeepc, cm, value);
> > + rv = parse_arg(buf, );
> > + if (rv < 0)
> > + return rv;
> > + value = set_acpi(eeepc, cm, value);
> > if (value < 0)
>
> I suppose it's harmless, but it would be more explicit to reuse rv here
> instead
> of value.
>
> > return -EIO;
>
> And as with Frans' version, I suggest propogating the error. We're talking
> about
> a missing/invalid ACPI control method name here, ENODEV seems approprirate.
>
> Rafael, do you have a strong preference about what to return in such an event?
No, I don't, although -ENXIO could be used here too.
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 04/10] perf record: Filter out POLLHUP'ed file descriptors
On Fri, Sep 05, 2014 at 11:07:56AM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Sep 05, 2014 at 11:42:59AM +0300, Adrian Hunter escreveu: > > On 09/04/2014 06:19 PM, Arnaldo Carvalho de Melo wrote: > > > Em Thu, Sep 04, 2014 at 03:32:08PM +0300, Adrian Hunter escreveu: > > No I was meaning something different. For example, 'perf record' opens an > > event for 2 processes per-cpu and gets 4 file descriptors: > > > task1 task2 > > cpu0fd0 fd1 > > cpu1fd2 fd3 > > > Now, perf record will mmap fd0 and fd2 and set-output fd1->fd0 > > and fd3->fd2. > > > pollfds includes only fd0 and fd2. > > > But if task2 exits, the POLLHUP will appear on fd1 and fd3. > > So? We are not interested in fd1 and fd3, since all our reading is done > on fd0 and fd2 mmaps, no? hm, what if task1 (fd0, fd2) exits first.. perf record will exit, but it still has to read task2..? > > I.e. when we ask the kernel to point fd B to fd A's mmap (what you > called set-output) and fd B inserts an event into fd A's mmap ring > buffer, we get fd A poll return as POLLRD, no? > > Have to check... Otherwise we would have to poll all fds all the time, > not just the ones mmaping, right? > > > I think Jiri's patchset changed pollfds to include all fds for that reason. hm, I did not think of that.. ;-) I needed more grained feedback for future features like cpu hotplug > > It did? I have to look again, probably went together with other changes, > has it? it was done by replacing 'int' with 'struct poll_item' for evsel::fd xyarray jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ext4: include journal blocks of internal journal in df overhead calcs
On Fri, Aug 15, 2014 at 02:42:51PM +0800, Chin-Tsung Cheng wrote:
> The journal blocks of external journal device should not
> be counted as overhead.
Hi Ted,
Would you mind queueing this one up for 3.17? It fixes this problem:
# df /mnt
/dev/sda 64Z 64Z 2.8G 100% /mnt
...which is a regression introduced in commit 0875a2b448 ("ext4: include
journal blocks in df overhead calcs") when one creates an ext4 with an
external journal.
It doesn't look like this patch is in any upstream tree.
--D
>
> Signed-off-by: Chin-Tsung Cheng
> ---
> fs/ext4/super.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index 32b43ad..a80b122 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3316,8 +3316,8 @@ int ext4_calculate_overhead(struct super_block *sb)
> memset(buf, 0, PAGE_SIZE);
> cond_resched();
> }
> - /* Add the journal blocks as well */
> - if (sbi->s_journal)
> + /* Add the internal journal blocks as well */
> + if (sbi->s_journal && !sbi->journal_bdev)
> overhead += EXT4_NUM_B2C(sbi, sbi->s_journal->j_maxlen);
>
> sbi->s_overhead = overhead;
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v4] x86: only load initrd above 4g on second try
On Sat, Sep 6, 2014 at 11:09 PM, Mantas Mikulėnas wrote:
> On Sat, Sep 6, 2014 at 1:16 AM, Matt Fleming wrote:
>> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>>>
>>> I am fine with this patch, but at the same time I do want to note that
>>> there is an alternative to double-buffer the patch and/or (if that
>>> applies to the buggy BIOS) round up the size of the target buffer.
>>
>> I took a whack at the double-buffer strategy, and I think the patch is
>> conceptually pretty straight forward.
>>
>> Could someone try out the following patch? It works around the problem
>> on my ASUS machine.
>>
>> ---
>>
>> From 89e7fdaeb04f79d9834678e486215974986d4ac8 Mon Sep 17 00:00:00 2001
>> From: Matt Fleming
>> Date: Fri, 5 Sep 2014 23:15:11 +0100
>> Subject: [PATCH] x86/efi: Workaround firmware bug with double-buffer read
>> MIME-Version: 1.0
>> Content-Type: text/plain; charset=UTF-8
>> Content-Transfer-Encoding: 8bit
>>
>> Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
>> loaded above 4G"), the kernel freezes at the earliest possible moment
>> when trying to boot via UEFI on Asus laptop.
>>
>> The cause of the freeze appears to be a firmware bug when reading file
>> data into buffers above 4GB, though the exact reason is unknown. Mantas
>> reports that the hang can be avoided if the file size is a multiple of
>> 512 bytes, but I've seen some ASUS firmware simply corrupting the file
>> data rather than freezing.
>>
>> Since the bug has only been reported when reading into a buffer above
>> 4GB, we can workaround the problem by doing a double-buffer read, where
>> we read a partial file chunk into a buffer < 4GB then copy it to the
>> buffer (potentially) above 4GB.
>>
>> Laszlo fixed an issue in the upstream EDK2 DiskIO code in Aug 2013 which
>> may possibly be related, commit 4e39b75e ("MdeModulePkg/DiskIoDxe: fix
>> source/destination pointer of overrun transfer"). Whatever the cause,
>> it's unlikely that a fix will be forthcoming from the vendor, hence the
>> workaround.
>>
>> Cc: Yinghai Lu
>> Cc: Laszlo Ersek
>> Reported-by: Mantas Mikulėnas
>> Reported-by: Harald Hoyer
>> Signed-off-by: Matt Fleming
>> ---
>> drivers/firmware/efi/libstub/efi-stub-helper.c | 28
>> --
>> 1 file changed, 26 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c
>> b/drivers/firmware/efi/libstub/efi-stub-helper.c
>> index 32d5cca30f49..470793ce2617 100644
>> --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
>> +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
>> @@ -297,6 +297,7 @@ efi_status_t handle_cmdline_files(efi_system_table_t
>> *sys_table_arg,
>> {
>> struct file_info *files;
>> unsigned long file_addr;
>> + unsigned long chunkbuf;
>> u64 file_size_total;
>> efi_file_handle_t *fh = NULL;
>> efi_status_t status;
>> @@ -416,6 +417,24 @@ efi_status_t handle_cmdline_files(efi_system_table_t
>> *sys_table_arg,
>> goto free_file_total;
>> }
>>
>> + /*
>> +* Allocate a bounce buffer below 4GB.
>> +*
>> +* Some firmware implementations cannot perform file
>> +* reads into buffers above 4G and at best corrupt the
>> +* buffer, at worst they hang completely.
>> +*
>> +* Pass chunkbuf to the firmware to perform reads in
>> +* chunksize bytes and copy them to the target buffer
>> +* 'file_addr'.
>> +*/
>> + status = efi_high_alloc(sys_table_arg, EFI_READ_CHUNK_SIZE,
>> + 0x1000, , 0x);
>> + if (status != EFI_SUCCESS) {
>> + pr_efi_err(sys_table_arg, "Failed to alloc file
>> chunk buffer\n");
>> + goto free_chunk;
>> + }
>> +
>> addr = file_addr;
>> for (j = 0; j < nr_files; j++) {
>> unsigned long size;
>> @@ -430,11 +449,13 @@ efi_status_t handle_cmdline_files(efi_system_table_t
>> *sys_table_arg,
>>
>> status = efi_file_read(files[j].handle,
>>,
>> - (void *)addr);
>> + (void *)chunkbuf);
>> if (status != EFI_SUCCESS) {
>> pr_efi_err(sys_table_arg, "Failed to
>> read file\n");
>> - goto free_file_total;
>> + goto free_chunk;
>> }
>> +
>> + memcpy((void *)addr, (void *)chunkbuf,
>> chunksize);
>> addr += chunksize;
>>
Re: [PATCH -v4] x86: only load initrd above 4g on second try
On Sat, Sep 6, 2014 at 1:16 AM, Matt Fleming wrote:
> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>>
>> I am fine with this patch, but at the same time I do want to note that
>> there is an alternative to double-buffer the patch and/or (if that
>> applies to the buggy BIOS) round up the size of the target buffer.
>
> I took a whack at the double-buffer strategy, and I think the patch is
> conceptually pretty straight forward.
>
> Could someone try out the following patch? It works around the problem
> on my ASUS machine.
>
> ---
>
> From 89e7fdaeb04f79d9834678e486215974986d4ac8 Mon Sep 17 00:00:00 2001
> From: Matt Fleming
> Date: Fri, 5 Sep 2014 23:15:11 +0100
> Subject: [PATCH] x86/efi: Workaround firmware bug with double-buffer read
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
> loaded above 4G"), the kernel freezes at the earliest possible moment
> when trying to boot via UEFI on Asus laptop.
>
> The cause of the freeze appears to be a firmware bug when reading file
> data into buffers above 4GB, though the exact reason is unknown. Mantas
> reports that the hang can be avoided if the file size is a multiple of
> 512 bytes, but I've seen some ASUS firmware simply corrupting the file
> data rather than freezing.
>
> Since the bug has only been reported when reading into a buffer above
> 4GB, we can workaround the problem by doing a double-buffer read, where
> we read a partial file chunk into a buffer < 4GB then copy it to the
> buffer (potentially) above 4GB.
>
> Laszlo fixed an issue in the upstream EDK2 DiskIO code in Aug 2013 which
> may possibly be related, commit 4e39b75e ("MdeModulePkg/DiskIoDxe: fix
> source/destination pointer of overrun transfer"). Whatever the cause,
> it's unlikely that a fix will be forthcoming from the vendor, hence the
> workaround.
>
> Cc: Yinghai Lu
> Cc: Laszlo Ersek
> Reported-by: Mantas Mikulėnas
> Reported-by: Harald Hoyer
> Signed-off-by: Matt Fleming
> ---
> drivers/firmware/efi/libstub/efi-stub-helper.c | 28
> --
> 1 file changed, 26 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/efi-stub-helper.c
> b/drivers/firmware/efi/libstub/efi-stub-helper.c
> index 32d5cca30f49..470793ce2617 100644
> --- a/drivers/firmware/efi/libstub/efi-stub-helper.c
> +++ b/drivers/firmware/efi/libstub/efi-stub-helper.c
> @@ -297,6 +297,7 @@ efi_status_t handle_cmdline_files(efi_system_table_t
> *sys_table_arg,
> {
> struct file_info *files;
> unsigned long file_addr;
> + unsigned long chunkbuf;
> u64 file_size_total;
> efi_file_handle_t *fh = NULL;
> efi_status_t status;
> @@ -416,6 +417,24 @@ efi_status_t handle_cmdline_files(efi_system_table_t
> *sys_table_arg,
> goto free_file_total;
> }
>
> + /*
> +* Allocate a bounce buffer below 4GB.
> +*
> +* Some firmware implementations cannot perform file
> +* reads into buffers above 4G and at best corrupt the
> +* buffer, at worst they hang completely.
> +*
> +* Pass chunkbuf to the firmware to perform reads in
> +* chunksize bytes and copy them to the target buffer
> +* 'file_addr'.
> +*/
> + status = efi_high_alloc(sys_table_arg, EFI_READ_CHUNK_SIZE,
> + 0x1000, , 0x);
> + if (status != EFI_SUCCESS) {
> + pr_efi_err(sys_table_arg, "Failed to alloc file chunk
> buffer\n");
> + goto free_chunk;
> + }
> +
> addr = file_addr;
> for (j = 0; j < nr_files; j++) {
> unsigned long size;
> @@ -430,11 +449,13 @@ efi_status_t handle_cmdline_files(efi_system_table_t
> *sys_table_arg,
>
> status = efi_file_read(files[j].handle,
>,
> - (void *)addr);
> + (void *)chunkbuf);
> if (status != EFI_SUCCESS) {
> pr_efi_err(sys_table_arg, "Failed to
> read file\n");
> - goto free_file_total;
> + goto free_chunk;
> }
> +
> + memcpy((void *)addr, (void *)chunkbuf,
> chunksize);
> addr += chunksize;
> size -= chunksize;
> }
> @@ -442,6 +463,7 @@ efi_status_t handle_cmdline_files(efi_system_table_t
> *sys_table_arg,
>
Re: OT: Open letter to the Linux World
Am 05.09.2014 08:31, schrieb Alexander Holler:
Am 04.09.2014 21:18, schrieb Rob Landley:
What's actually wrong with C++ at a language design level.
Short version:
OMG.
It's better than C. In almost every aspect. Stop. Nothing else. Of
course, if you want to write something like systemd in Python, Perl,
Pascal, Modula or Erlang, feel free to so. And if you want more security
bugs, feel free to still use C for string handling instead of
std::string, Or still write your sorted list for every structure (or
just don't and go the slow way, because you don't find the time to do it
right in C). And ...
You don't have to understand how templates do work to use e.g.
std::string. Other people do hard stuff for you. So don't panic.
I've brought up the critics about using C in a critical and very
security sensitive piece of software in userland, so I've decided a bit
more explanations might make sense.
First, as you don't seem to have noticed or you don't know or you ignore
the difference, let me repeat that this thread is about a piece of SW
which runs in userland. So, please, keep away with any comments from
Linus where he talks about kernelspace. I'm pretty sure he knows the
difference.
Now let me bring up a very small piece of code which you can find in a
similiar fashion in almost every piece of software which gets in contact
with strings. And not just in one place or function, but in dozens or
even hundred of places (inline, not in functions) in one project.
First in C++:
void foo_bar(const std::string& foo, const std::string& bar,
std::string& foobar)
{
foobar = foo + bar;
}
For those which don't know C++, this concatenates the two strings named
foo and bar and puts the result into foobar.
Now an example how you would have to do that in C:
char *foo_bar(const char *foo, const char *bar)
{
char *foobar = malloc(strlen(foo) + strlen(bar));
strcpy(foobar, foo);
strcat(foobar, bar);
return foobar;
}
Do you see the difference and spot all the problems?
First I've though about not posting the answer to see the response, but
that would just have ended up with a lot of people calling me a fool
and/or assuming I can't write proper C. And it bears the problem that
some inexperienced people might copy and paste and use it.
So at first: THE ABOVE EXAMPLE IN C IS BROKEN.
The very first problem is that foobar is allocated with the wrong size,
because it doesn't take care of the terminating null byte. A very common
problem already found at uncountable places.
But there are several more problems:
- What happens if foo or bar isn't terminated with a null byte?
- What happens if malloc fails?
- Who is the owner of foo, bar and/or foobar? Does the caller still owns
foo and bar afterwards? Will the caller own foobar? (That means who is
repsonsible to free foo, bar and foobar if they aren't used anymore).
So now we extend the above C example:
char *foo_bar(const char *foo, const char *bar)
{
char *foobar;
if (!foo || !bar)
return NULL;
foobar = malloc(strlen(foo) + strlen(bar) + 1);
if (!foobar)
return NULL;
strcpy(foobar, foo);
strcat(foobar, bar);
return foobar;
}
This has still some problems. First, the caller has to check if
foo_bar() hasn't returned NULL. A very common bug already found in
uncountable places too.
Next, there is still the unsolvable problem about what happens if foo or
bar isn't terminated with a null byte (in other words they aren't C
strings).
So you have to check all callers up to the source of foo and bar to be
sure the program doesn't crash in the possible far far away place called
foo_bar().
And still no comment about ownership. That means someone who just looks
at the prototype or sees a call of foo_bar() somewhere has no idea about
the ownership of foo, bar and the returned foobar without a comment.
So just this very simple functionality about string handling in C
already contains several still open questions and is 17 lines long which
have to be reviewed very carefull (e.g. to not miss the off-by-one bug).
Compare this with the 4 lines in C++ which are almost impossible to do
or to use wrong.
And, again, this thread is about a piece of software which runs with
process ID 1, wants to control the whole system and owns all permissions
to modify the system in almost every possible way. It doesn't run as
some user with restricted permissions or in chroot or something
similar. Some parts might do, but for sure not all (read again the above
"far far away").
And now some stats. I've just checked out systemd:
git grep -E "strcat|strncat|strcpy|strncpy|strlen" | wc -l
570
git grep -E "strcat|strncat|strcpy|strncpy|memcpy|strlen" | wc -l
850
Ok, not every of those places might be part of pid 1. And several places
are trivial calls like strlen("ATTR"), but it gives an idea about how
many places
[PATCH 2/3] mm: introduce VM_BUG_ON_MM
Very similar to VM_BUG_ON_PAGE and VM_BUG_ON_VMA, dump struct_mm
when the bug is hit.
Signed-off-by: Sasha Levin
---
include/linux/mmdebug.h | 10 +++
mm/debug.c | 69 +++
2 files changed, 79 insertions(+)
diff --git a/include/linux/mmdebug.h b/include/linux/mmdebug.h
index 569e4c8..5116d4b 100644
--- a/include/linux/mmdebug.h
+++ b/include/linux/mmdebug.h
@@ -5,11 +5,13 @@
struct page;
struct vm_area_struct;
+struct mm_struct;
extern void dump_page(struct page *page, const char *reason);
extern void dump_page_badflags(struct page *page, const char *reason,
unsigned long badflags);
void dump_vma(const struct vm_area_struct *vma);
+void dump_mm(const struct mm_struct *mm);
#ifdef CONFIG_DEBUG_VM
#define VM_BUG_ON(cond) BUG_ON(cond)
@@ -27,6 +29,13 @@ void dump_vma(const struct vm_area_struct *vma);
BUG(); \
} \
} while (0)
+#define VM_BUG_ON_MM(cond, mm) \
+do { \
+if (unlikely(cond)) { \
+dump_mm(mm); \
+BUG(); \
+} \
+} while (0)
#define VM_WARN_ON(cond) WARN_ON(cond)
#define VM_WARN_ON_ONCE(cond) WARN_ON_ONCE(cond)
#define VM_WARN_ONCE(cond, format...) WARN_ONCE(cond, format)
@@ -34,6 +43,7 @@ void dump_vma(const struct vm_area_struct *vma);
#define VM_BUG_ON(cond) BUILD_BUG_ON_INVALID(cond)
#define VM_BUG_ON_PAGE(cond, page) VM_BUG_ON(cond)
#define VM_BUG_ON_VMA(cond, vma) VM_BUG_ON(cond)
+#define VM_BUG_ON_MM(cond, mm) VM_BUG_ON(cond)
#define VM_WARN_ON(cond) BUILD_BUG_ON_INVALID(cond)
#define VM_WARN_ON_ONCE(cond) BUILD_BUG_ON_INVALID(cond)
#define VM_WARN_ONCE(cond, format...) BUILD_BUG_ON_INVALID(cond)
diff --git a/mm/debug.c b/mm/debug.c
index c19af12..8418893 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -1,3 +1,10 @@
+/*
+ * mm/debug.c
+ *
+ * mm/ specific debug routines.
+ *
+ */
+
#include
#include
#include
@@ -158,4 +165,66 @@ void dump_vma(const struct vm_area_struct *vma)
}
EXPORT_SYMBOL(dump_vma);
+void dump_mm(const struct mm_struct *mm)
+{
+ printk(KERN_ALERT
+ "mm %p mmap %p seqnum %d task_size %lu\n"
+#ifdef CONFIG_MMU
+ "get_unmapped_area %p\n"
+#endif
+ "mmap_base %lu mmap_legacy_base %lu highest_vm_end %lu\n"
+ "pgd %p mm_users %d mm_count %d nr_ptes %lu map_count %d\n"
+ "hiwater_rss %lx hiwater_vm %lx total_vm %lx locked_vm %lx\n"
+ "pinned_vm %lx shared_vm %lx exec_vm %lx stack_vm %lx\n"
+ "start_code %lx end_code %lx start_data %lx end_data %lx\n"
+ "start_brk %lx brk %lx start_stack %lx\n"
+ "arg_start %lx arg_end %lx env_start %lx env_end %lx\n"
+ "binfmt %p flags %lx core_state %p\n"
+#ifdef CONFIG_AIO
+ "ioctx_table %p\n"
+#endif
+ "owner %p exe_file %p\n"
+#ifdef CONFIG_MMU_NOTIFIER
+ "mmu_notifier_mm %p\n"
+#endif
+#ifdef CONFIG_NUMA_BALANCING
+ "numa_next_scan %lu numa_scan_offset %lu numa_scan_seq %d\n"
+#endif
+#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
+ "tlb_flush_pending %d\n",
+#endif
+ mm, mm->mmap, mm->vmacache_seqnum, mm->task_size,
+#ifdef CONFIG_MMU
+ mm->get_unmapped_area,
+#endif
+ mm->mmap_base, mm->mmap_legacy_base, mm->highest_vm_end,
+ mm->pgd, atomic_read(>mm_users),
+ atomic_read(>mm_count),
+ atomic_long_read((atomic_long_t *)>nr_ptes),
+ mm->map_count,
+ mm->hiwater_rss, mm->hiwater_vm, mm->total_vm, mm->locked_vm,
+ mm->pinned_vm, mm->shared_vm, mm->exec_vm, mm->stack_vm,
+ mm->start_code, mm->end_code, mm->start_data, mm->end_data,
+ mm->start_brk, mm->brk, mm->start_stack,
+ mm->arg_start, mm->arg_end, mm->env_start, mm->env_end,
+ mm->binfmt, mm->flags, mm->core_state,
+#ifdef CONFIG_AIO
+ mm->ioctx_table,
+#endif
+ mm->owner, mm->exe_file,
+#ifdef CONFIG_MMU_NOTIFIER
+ mm->mmu_notifier_mm,
+#endif
+#ifdef CONFIG_NUMA_BALANCING
+ mm->numa_next_scan, mm->numa_scan_offset, mm->numa_scan_seq,
+#endif
+#if defined(CONFIG_NUMA_BALANCING) || defined(CONFIG_COMPACTION)
+ mm->tlb_flush_pending
+#endif
+ );
+
+ dump_flags(mm->def_flags, vmaflags_names,
+ ARRAY_SIZE(vmaflags_names));
+}
+
#endif
[PATCH 3/3] mm: use VM_BUG_ON_MM where possible
Dump the contents of the relevant struct_mm when we hit the
bug condition.
Signed-off-by: Sasha Levin
---
kernel/fork.c|3 +--
kernel/sys.c |2 +-
mm/huge_memory.c |2 +-
mm/mlock.c |2 +-
mm/mmap.c|7 ---
mm/pagewalk.c|2 +-
6 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 0cf9cdb..7953519 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -601,9 +601,8 @@ static void check_mm(struct mm_struct *mm)
printk(KERN_ALERT "BUG: Bad rss-counter state "
"mm:%p idx:%d val:%ld\n", mm, i, x);
}
-
#if defined(CONFIG_TRANSPARENT_HUGEPAGE) && !USE_SPLIT_PMD_PTLOCKS
- VM_BUG_ON(mm->pmd_huge_pte);
+ VM_BUG_ON_MM(mm->pmd_huge_pte, mm);
#endif
}
diff --git a/kernel/sys.c b/kernel/sys.c
index b59294d..037fd76 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -1642,7 +1642,7 @@ static int prctl_set_mm_exe_file_locked(struct mm_struct
*mm, unsigned int fd)
struct inode *inode;
int err;
- VM_BUG_ON(!rwsem_is_locked(>mmap_sem));
+ VM_BUG_ON_MM(!rwsem_is_locked(>mmap_sem), mm);
exe = fdget(fd);
if (!exe.file)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index d81f8ba..ba5dc2f 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2045,7 +2045,7 @@ int __khugepaged_enter(struct mm_struct *mm)
return -ENOMEM;
/* __khugepaged_exit() must not run from under us */
- VM_BUG_ON(khugepaged_test_exit(mm));
+ VM_BUG_ON_MM(khugepaged_test_exit(mm), mm);
if (unlikely(test_and_set_bit(MMF_VM_HUGEPAGE, >flags))) {
free_mm_slot(mm_slot);
return 0;
diff --git a/mm/mlock.c b/mm/mlock.c
index d5d09d0..03aa851 100644
--- a/mm/mlock.c
+++ b/mm/mlock.c
@@ -235,7 +235,7 @@ long __mlock_vma_pages_range(struct vm_area_struct *vma,
VM_BUG_ON(end & ~PAGE_MASK);
VM_BUG_ON_VMA(start < vma->vm_start, vma);
VM_BUG_ON_VMA(end > vma->vm_end, vma);
- VM_BUG_ON(!rwsem_is_locked(>mmap_sem));
+ VM_BUG_ON_MM(!rwsem_is_locked(>mmap_sem), mm);
gup_flags = FOLL_TOUCH | FOLL_MLOCK;
/*
diff --git a/mm/mmap.c b/mm/mmap.c
index 9351482..d2f1a0a 100644
--- a/mm/mmap.c
+++ b/mm/mmap.c
@@ -408,8 +408,9 @@ static void validate_mm_rb(struct rb_root *root, struct
vm_area_struct *ignore)
for (nd = rb_first(root); nd; nd = rb_next(nd)) {
struct vm_area_struct *vma;
vma = rb_entry(nd, struct vm_area_struct, vm_rb);
- BUG_ON(vma != ignore &&
- vma->rb_subtree_gap != vma_compute_subtree_gap(vma));
+ VM_BUG_ON_VMA(vma != ignore &&
+ vma->rb_subtree_gap != vma_compute_subtree_gap(vma),
+ vma);
}
}
@@ -443,7 +444,7 @@ static void validate_mm(struct mm_struct *mm)
pr_info("map_count %d rb %d\n", mm->map_count, i);
bug = 1;
}
- BUG_ON(bug);
+ VM_BUG_ON_MM(bug, mm);
}
#else
#define validate_mm_rb(root, ignore) do { } while (0)
diff --git a/mm/pagewalk.c b/mm/pagewalk.c
index 2beeabf..ad83195 100644
--- a/mm/pagewalk.c
+++ b/mm/pagewalk.c
@@ -177,7 +177,7 @@ int walk_page_range(unsigned long addr, unsigned long end,
if (!walk->mm)
return -EINVAL;
- VM_BUG_ON(!rwsem_is_locked(>mm->mmap_sem));
+ VM_BUG_ON_MM(!rwsem_is_locked(>mm->mmap_sem), walk->mm);
pgd = pgd_offset(walk->mm, addr);
do {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] mm: move debug code out of page_alloc.c
dump_page() and dump_vma() are not specific to page_alloc.c, move
them out so page_alloc.c won't turn into the unofficial debug
repository.
Signed-off-by: Sasha Levin
---
mm/Makefile |2 +-
mm/debug.c | 161 +++
mm/page_alloc.c | 158 -
3 files changed, 162 insertions(+), 159 deletions(-)
create mode 100644 mm/debug.c
diff --git a/mm/Makefile b/mm/Makefile
index b2f18dc..25fdc12 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -18,7 +18,7 @@ obj-y := filemap.o mempool.o oom_kill.o
fadvise.o \
mm_init.o mmu_context.o percpu.o slab_common.o \
compaction.o vmacache.o \
interval_tree.o list_lru.o workingset.o \
- iov_iter.o $(mmu-y)
+ iov_iter.o debug.o $(mmu-y)
obj-y += init-mm.o
diff --git a/mm/debug.c b/mm/debug.c
new file mode 100644
index 000..c19af12
--- /dev/null
+++ b/mm/debug.c
@@ -0,0 +1,161 @@
+#include
+#include
+#include
+#include
+
+static const struct trace_print_flags pageflag_names[] = {
+ {1UL << PG_locked, "locked"},
+ {1UL << PG_error, "error" },
+ {1UL << PG_referenced, "referenced"},
+ {1UL << PG_uptodate,"uptodate" },
+ {1UL << PG_dirty, "dirty" },
+ {1UL << PG_lru, "lru" },
+ {1UL << PG_active, "active"},
+ {1UL << PG_slab,"slab" },
+ {1UL << PG_owner_priv_1,"owner_priv_1" },
+ {1UL << PG_arch_1, "arch_1"},
+ {1UL << PG_reserved,"reserved" },
+ {1UL << PG_private, "private" },
+ {1UL << PG_private_2, "private_2" },
+ {1UL << PG_writeback, "writeback" },
+#ifdef CONFIG_PAGEFLAGS_EXTENDED
+ {1UL << PG_head,"head" },
+ {1UL << PG_tail,"tail" },
+#else
+ {1UL << PG_compound,"compound" },
+#endif
+ {1UL << PG_swapcache, "swapcache" },
+ {1UL << PG_mappedtodisk,"mappedtodisk" },
+ {1UL << PG_reclaim, "reclaim" },
+ {1UL << PG_swapbacked, "swapbacked"},
+ {1UL << PG_unevictable, "unevictable" },
+#ifdef CONFIG_MMU
+ {1UL << PG_mlocked, "mlocked" },
+#endif
+#ifdef CONFIG_ARCH_USES_PG_UNCACHED
+ {1UL << PG_uncached,"uncached" },
+#endif
+#ifdef CONFIG_MEMORY_FAILURE
+ {1UL << PG_hwpoison,"hwpoison" },
+#endif
+#ifdef CONFIG_TRANSPARENT_HUGEPAGE
+ {1UL << PG_compound_lock, "compound_lock" },
+#endif
+};
+
+static void dump_flags(unsigned long flags,
+ const struct trace_print_flags *names, int count)
+{
+ const char *delim = "";
+ unsigned long mask;
+ int i;
+
+ printk(KERN_ALERT "flags: %#lx(", flags);
+
+ /* remove zone id */
+ flags &= (1UL << NR_PAGEFLAGS) - 1;
+
+ for (i = 0; i < count && flags; i++) {
+
+ mask = names[i].mask;
+ if ((flags & mask) != mask)
+ continue;
+
+ flags &= ~mask;
+ printk("%s%s", delim, names[i].name);
+ delim = "|";
+ }
+
+ /* check for left over flags */
+ if (flags)
+ printk("%s%#lx", delim, flags);
+
+ printk(")\n");
+}
+
+void dump_page_badflags(struct page *page, const char *reason,
+ unsigned long badflags)
+{
+ printk(KERN_ALERT
+ "page:%p count:%d mapcount:%d mapping:%p index:%#lx\n",
+ page, atomic_read(>_count), page_mapcount(page),
+ page->mapping, page->index);
+ BUILD_BUG_ON(ARRAY_SIZE(pageflag_names) != __NR_PAGEFLAGS);
+ dump_flags(page->flags, pageflag_names, ARRAY_SIZE(pageflag_names));
+ if (reason)
+ pr_alert("page dumped because: %s\n", reason);
+ if (page->flags & badflags) {
+ pr_alert("bad because of flags:\n");
+ dump_flags(page->flags & badflags,
+ pageflag_names, ARRAY_SIZE(pageflag_names));
+ }
+ mem_cgroup_print_bad_page(page);
+}
+
+void dump_page(struct page *page, const char *reason)
+{
+ dump_page_badflags(page, reason, 0);
+}
+EXPORT_SYMBOL(dump_page);
+
+#ifdef CONFIG_DEBUG_VM
+
+static const struct trace_print_flags vmaflags_names[] = {
+ {VM_READ, "read" },
+ {VM_WRITE, "write" },
+ {VM_EXEC, "exec" },
+ {VM_SHARED, "shared"},
+ {VM_MAYREAD,
Re: [PATCH v4 2/3] perf tools: parse the pmu event prefix and surfix
On Tue, Sep 02, 2014 at 11:29:29AM -0400, kan.li...@intel.com wrote:
SNIP
> {
> YY_BUFFER_STATE buffer;
> @@ -906,7 +1006,10 @@ int parse_events(struct perf_evlist *evlist, const char
> *str)
> };
> int ret;
>
> + /* scan kernel pmu events from sysfs */
> + scan_kernel_pmu_events_list();
> ret = parse_events__scanner(str, , PE_START_EVENTS);
> + release_kernel_pmu_events_list();
> if (!ret) {
> int entries = data.idx - evlist->nr_entries;
> perf_evlist__splice_list_tail(evlist, , entries);
> diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
> index df094b4..d06fec4 100644
> --- a/tools/perf/util/parse-events.h
> +++ b/tools/perf/util/parse-events.h
> @@ -35,6 +35,19 @@ extern int parse_filter(const struct option *opt, const
> char *str, int unset);
>
> #define EVENTS_HELP_MAX (128*1024)
>
> +#define KERNEL_PMU_EVENT_MAX 1024
hum.. so roughly for 15 (+-) strings of size around 20 bytes we will
use 15K of memory.. seems like overkill
seems better to allocate each symbol string separatelly, and
update the release function
> +enum kernel_pmu_event_type {
> + NONE_KERNEL_PMU_EVENT, /* not a PMU EVENT */
> + KERNEL_PMU_EVENT, /* normal style PMU event */
> + KERNEL_PMU_EVENT_PREFIX,/* prefix of pre-suf style event */
> + KERNEL_PMU_EVENT_SUFFIX,/* suffix of pre-suf style event */
> +};
> +
> +struct kernel_pmu_event_symbol {
> + charsymbol[KERNEL_PMU_EVENT_MAX];
> + enum kernel_pmu_event_type type;
> +};
> +
also, I think this is more pmu object related stuff.. how about:
enum perf_pmu_event_symbol_type
struct perf_pmu_event_symbol
perf_pmu__parse_init
perf_pmu__parse_cleanup
perf_pmu__parse_check
with perf_pmu__parse_init being called from perf_pmu__parse_check
in case it's needed..
and perf_pmu__parse_cleanup being called from parse_events same as
release_kernel_pmu_events_list
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] perf tools: Add support to new style format of kernel PMU event
On Tue, Sep 02, 2014 at 11:29:30AM -0400, kan.li...@intel.com wrote:
> From: Kan Liang
SNIP
> }
> +|
> +PE_KERNEL_PMU_EVENT
> +{
> + struct parse_events_evlist *data = _data;
> + struct list_head *head = malloc(sizeof(*head));
> + struct parse_events_term *term;
> + struct list_head *list;
> +
> + ABORT_ON(parse_events_term__num(, PARSE_EVENTS__TERM_TYPE_USER,
> + $1, 1));
> + ABORT_ON(!head);
> + INIT_LIST_HEAD(head);
> + list_add_tail(>list, head);
> +
> + ALLOC_LIST(list);
> + ABORT_ON(parse_events_add_pmu(list, >idx, "cpu", head));
> + parse_events__free_terms(head);
> + $$ = list;
> +}
> +|
> +PE_PMU_EVENT_PRE '-' PE_PMU_EVENT_SUF
so, how about the event alias has more than 2 parts a-b-c ?
if I remove 'stalled-cycles-frontend' from lexer (patch attached),
I'll get error parsing it with this code:
---
[jolsa@krava perf]$ ls -l /sys/devices/cpu/events/stalled-cycles-frontend
-r--r--r-- 1 root root 4096 Sep 6 21:17
/sys/devices/cpu/events/stalled-cycles-frontend
[jolsa@krava perf]$ ./perf record -e stalled-cycles-frontend ls
invalid or unsupported event: 'stalled-cycles-frontend'
Run 'perf list' for a list of valid events
usage: perf record [] []
or: perf record [] -- []
-e, --eventevent selector. use 'perf list' to list available
events
---
and.. if we will actually handle this correctly, I think maybe we want
to remove all the PERF_TYPE_HARDWARE equivalents?
thanks,
jirka
---
diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 4dd7f0467dd1..c1a354f651ca 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -176,8 +176,6 @@ branch_type { return term(yyscanner,
PARSE_EVENTS__TERM_TYPE_BRANCH_SAMPLE_TYPE
}
cpu-cycles|cycles { return sym(yyscanner,
PERF_TYPE_HARDWARE, PERF_COUNT_HW_CPU_CYCLES); }
-stalled-cycles-frontend|idle-cycles-frontend { return sym(yyscanner,
PERF_TYPE_HARDWARE, PERF_COUNT_HW_STALLED_CYCLES_FRONTEND); }
-stalled-cycles-backend|idle-cycles-backend { return sym(yyscanner,
PERF_TYPE_HARDWARE, PERF_COUNT_HW_STALLED_CYCLES_BACKEND); }
instructions { return sym(yyscanner,
PERF_TYPE_HARDWARE, PERF_COUNT_HW_INSTRUCTIONS); }
cache-references { return sym(yyscanner,
PERF_TYPE_HARDWARE, PERF_COUNT_HW_CACHE_REFERENCES); }
cache-misses { return sym(yyscanner,
PERF_TYPE_HARDWARE, PERF_COUNT_HW_CACHE_MISSES); }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 3/3] perf tools: Add support to new style format of kernel PMU event
On Tue, Sep 02, 2014 at 11:29:30AM -0400, kan.li...@intel.com wrote:
SNIP
> +++ b/tools/perf/util/parse-events.y
> @@ -47,6 +47,7 @@ static inc_group_count(struct list_head *list,
> %token PE_NAME_CACHE_TYPE PE_NAME_CACHE_OP_RESULT
> %token PE_PREFIX_MEM PE_PREFIX_RAW PE_PREFIX_GROUP
> %token PE_ERROR
> +%token PE_PMU_EVENT_PRE PE_PMU_EVENT_SUF PE_KERNEL_PMU_EVENT
> %type PE_VALUE
> %type PE_VALUE_SYM_HW
> %type PE_VALUE_SYM_SW
> @@ -58,6 +59,7 @@ static inc_group_count(struct list_head *list,
> %type PE_MODIFIER_EVENT
> %type PE_MODIFIER_BP
> %type PE_EVENT_NAME
> +%type PE_PMU_EVENT_PRE PE_PMU_EVENT_SUF PE_KERNEL_PMU_EVENT
> %type value_sym
> %type event_config
> %type event_term
> @@ -210,6 +212,46 @@ PE_NAME '/' event_config '/'
> parse_events__free_terms($3);
> $$ = list;
> }
> +|
> +PE_KERNEL_PMU_EVENT
> +{
> + struct parse_events_evlist *data = _data;
> + struct list_head *head = malloc(sizeof(*head));
could you please use ALLOC_LIST(head) ?
> + struct parse_events_term *term;
> + struct list_head *list;
> +
> + ABORT_ON(parse_events_term__num(, PARSE_EVENTS__TERM_TYPE_USER,
> + $1, 1));
> + ABORT_ON(!head);
> + INIT_LIST_HEAD(head);
> + list_add_tail(>list, head);
> +
> + ALLOC_LIST(list);
> + ABORT_ON(parse_events_add_pmu(list, >idx, "cpu", head));
> + parse_events__free_terms(head);
> + $$ = list;
> +}
> +|
> +PE_PMU_EVENT_PRE '-' PE_PMU_EVENT_SUF
> +{
> + struct parse_events_evlist *data = _data;
> + struct list_head *head = malloc(sizeof(*head));
same here
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] perf tools: parse the pmu event prefix and surfix
On Tue, Sep 02, 2014 at 11:29:29AM -0400, kan.li...@intel.com wrote:
> From: Kan Liang
SNIP
> + * Read the pmu events list from sysfs
> + * Save it into kernel_pmu_events_list
> + */
> +static void scan_kernel_pmu_events_list(void)
> +{
> +
> + struct perf_pmu *pmu = NULL;
> + struct perf_pmu_alias *alias;
> + int len = 0;
> +
> + while ((pmu = perf_pmu__scan(pmu)) != NULL)
> + list_for_each_entry(alias, >aliases, list) {
Why do we need to call scan here? Looks like:
pmu = pmu_lookup("cpu")
should be enough.. and could be used below as well
> + if (!strcmp(pmu->name, "cpu")) {
> + if (strchr(alias->name, '-'))
> + len++;
> + len++;
> + }
> + }
> + if (len == 0)
> + return;
> + kernel_pmu_events_list =
> + malloc(sizeof(struct kernel_pmu_event_symbol) * len);
> + kernel_pmu_events_list_num = len;
> +
> + pmu = NULL;
> + len = 0;
> + while ((pmu = perf_pmu__scan(pmu)) != NULL)
> + list_for_each_entry(alias, >aliases, list) {
> + if (!strcmp(pmu->name, "cpu")) {
> + struct kernel_pmu_event_symbol *p =
> + kernel_pmu_events_list + len;
> + char *tmp = strchr(alias->name, '-');
> +
> + if (tmp != NULL) {
> + strlcpy(p->symbol, alias->name,
> + tmp - alias->name + 1);
> + p->type = KERNEL_PMU_EVENT_PREFIX;
> + tmp++;
> + p++;
> + strcpy(p->symbol, tmp);
> + p->type = KERNEL_PMU_EVENT_SUFFIX;
> + len += 2;
> + } else {
> + strcpy(p->symbol, alias->name);
> + p->type = KERNEL_PMU_EVENT;
> + len++;
> + }
> + }
> + }
> + qsort(kernel_pmu_events_list, len,
> + sizeof(struct kernel_pmu_event_symbol), comp_pmu);
> +
> +}
SNIP
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] memfd: Add memfd.h to uapi headers
Hi David, >> It seems like a good idea to actually expose include/uapi/linux/memfd.h >> so that it gets installed and can be used by userspace. >> >> Signed-off-by: Marcel Holtmann > > Already in -mmots, will probably be pulled by Linus next week: > > http://ozlabs.org/~akpm/mmots/broken-out/shm-add-memfdh-to-uapi-export-list.patch might be a good idea to get it in before 3.17-rc4 and not have it dangling around for another week. Just an idea ;) Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] x86: only load initrd above 4g on second try
* Matt Fleming [140906 00:16]: > On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote: > > I am fine with this patch, but at the same time I do want to note that > > there is an alternative to double-buffer the patch and/or (if that > > applies to the buggy BIOS) round up the size of the target buffer. > I took a whack at the double-buffer strategy, and I think the patch is > conceptually pretty straight forward. > Could someone try out the following patch? It works around the problem > on my ASUS machine. Your patch works around the problem on my Dell machine also. With that one applied, it boots fine! Thus, Tested-by: Anders Darander Cheers, Anders -- All the troubles you have will pass away very quickly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] memfd: Add memfd.h to uapi headers
Hi On Sat, Sep 6, 2014 at 8:40 PM, Marcel Holtmann wrote: > It seems like a good idea to actually expose include/uapi/linux/memfd.h > so that it gets installed and can be used by userspace. > > Signed-off-by: Marcel Holtmann Already in -mmots, will probably be pulled by Linus next week: http://ozlabs.org/~akpm/mmots/broken-out/shm-add-memfdh-to-uapi-export-list.patch Thanks David > --- > include/uapi/linux/Kbuild | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild > index 24e9033f8b3f..939df6973102 100644 > --- a/include/uapi/linux/Kbuild > +++ b/include/uapi/linux/Kbuild > @@ -240,6 +240,7 @@ header-y += matroxfb.h > header-y += mdio.h > header-y += media.h > header-y += mei.h > +header-y += memfd.h > header-y += mempolicy.h > header-y += meye.h > header-y += mic_common.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/
[BUG] perf tools: Demangle kernel and kernel module symbols too
hi, Jan Stancek found test 1 breakage, probably caused by following patch: 950b8354716e perf tools: Demangle kernel and kernel module symbols too it seems to break test 1: --- [jolsa@krava perf]$ ./perf test -v 1 1: vmlinux symtab matches kallsyms: --- start --- test child forked, pid 6288 Looking at the vmlinux_path (6 entries long) SNIP 0x8142dba0: diff name v: event_queue virtual table k: __vt_event_queue 0x8142dc00: diff name v: event_dequeue virtual table k: __vt_event_dequeue 0x8142dd90: diff name v: event_wait::israpart:: virtual table k: __vt_event_wait.isra.0.part.1 --- Avi, could you please update the tests/vmlinux-kallsyms.c to reflect the demangle change? thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] memfd: Add memfd.h to uapi headers
It seems like a good idea to actually expose include/uapi/linux/memfd.h so that it gets installed and can be used by userspace. Signed-off-by: Marcel Holtmann --- include/uapi/linux/Kbuild | 1 + 1 file changed, 1 insertion(+) diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 24e9033f8b3f..939df6973102 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -240,6 +240,7 @@ header-y += matroxfb.h header-y += mdio.h header-y += media.h header-y += mei.h +header-y += memfd.h header-y += mempolicy.h header-y += meye.h header-y += mic_common.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/
Re: ARM kirkwood: 1 Gb memory 25% unusable due to vmalloc region overlap
On Sat, Sep 06, 2014 at 07:32:07PM +0200, Jurriaan wrote: > I updated my Qnap TS-212 with 256 Mb memory to a new TS-221 with 1 Gb > memory. > > On booting, I see that a large chunk of that new memory is not used by > linux: > > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Initializing cgroup subsys cpuset > [0.00] Initializing cgroup subsys cpu > [0.00] Initializing cgroup subsys cpuacct > [0.00] Linux version 3.14-2-kirkwood (debian-ker...@lists.debian.org) > (gcc version 4.8.3 (Debian 4.8.3-7) ) #1 Debian 3.14.15-2 (2014-08-09) > [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), > cr=00053977 > [0.00] CPU: VIVT data cache, VIVT instruction cache > [0.00] Machine: QNAP TS-119/TS-219 > [0.00] Ignoring unrecognised tag 0x41000403 > [0.00] Truncating RAM at 2000-3fff to -2f7f (vmalloc > region overlap). > > Whoops! You can either enable highmem (which has been available on ARM for ages now, there's little excuse not to use it) or reduce the available userspace virtual memory by enabling VMSPLIT_2G. -- 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/
Re: [PATCH 2/3] staging: lustre: fix pointer whitespace style
On Sat, 2014-09-06 at 13:38 -0400, Spencer Baugh wrote:
> Fix errors reported by checkpatch of this kind:
[]
> diff --git a/drivers/staging/lustre/lustre/include/lustre_import.h
> b/drivers/staging/lustre/lustre/include/lustre_import.h
[]
> @@ -103,9 +103,9 @@ enum lustre_imp_state {
> };
>
> /** Returns test string representation of numeric import state \a state */
> -static inline char * ptlrpc_import_state_name(enum lustre_imp_state state)
> +static inline char *ptlrpc_import_state_name(enum lustre_imp_state state)
> {
> - static char* import_state_names[] = {
> + static char *import_state_names[] = {
> "", "CLOSED", "NEW", "DISCONN",
> "CONNECTING", "REPLAY", "REPLAY_LOCKS", "REPLAY_WAIT",
> "RECOVER", "FULL", "EVICTED",
This likely shouldn't be static inline, but an actual
function somewhere.
The return should probably be const char *.
Indexing a string array with an enum is generally unsafe.
I think it better to use a switch/case like:
const char *ptlrpc_import_state_name(enum lustre_imp_state state)
{
switch (state) {
case LUSTRE_IMP_CLOSED:
return "CLOSED";
case LUSTRE_IMP_NEW:
return "NEW";
case LUSTRE_IMP_DISCON:
return "DISCONN";
case LUSTRE_IMP_CONNECTING:
return "CONNECTING";
case LUSTRE_IMP_REPLAY:
return "REPLAY";
case LUSTRE_IMP_REPLAY_LOCKS:
return "REPLAY_LOCKS";
case LUSTRE_IMP_REPLAY_WAIT:
return "REPLAY_WAIT";
case LUSTRE_IMP_RECOVER:
return "RECOVER";
case LUSTRE_IMP_FULL:
return "FULL";
case LUSTRE_IMP_EVICTED:
return "EVICTED";
default:
return "UNKNOWN";
}
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: Tree for Sep 5: build error due to 'ath5k: added debugfs file for dumping eeprom'
On Sat, Sep 6, 2014 at 5:32 PM, Guenter Roeck wrote:
> I see the following build error on linux-next-20140905.
>
> Guenter
>
> ---
>
> Building alpha:allmodconfig ... failed
> Building sparc64:allmodconfig ... failed
>
> drivers/net/wireless/ath/ath5k/debug.c: In function 'open_file_eeprom':
> drivers/net/wireless/ath/ath5k/debug.c:933:2: error:
> implicit declaration of function 'vmalloc'
> [-Werror=implicit-function-declaration]
> drivers/net/wireless/ath/ath5k/debug.c:933:6: warning:
> assignment makes pointer from integer without a cast [enabled by
> default]
> drivers/net/wireless/ath/ath5k/debug.c:960:2: error:
> implicit declaration of function 'vfree'
> [-Werror=implicit-function-declaration]
> cc1: some warnings being treated as errors
Missing #include ?
> make[5]: *** [drivers/net/wireless/ath/ath5k/debug.o] Error 1
> make[4]: *** [drivers/net/wireless/ath/ath5k] Error 2
> make[3]: *** [drivers/net/wireless/ath] Error 2
>
> Bisect results:
>
> db906eb2101b0564b0c65edf4a8647395196342e is the first bad commit
> commit db906eb2101b0564b0c65edf4a8647395196342e
> Author: Jade Bilkey
> Date: Sat Aug 30 15:14:14 2014 -0400
>
> ath5k: added debugfs file for dumping eeprom
>
> Signed-off-by: Jade Bilkey
> Signed-off-by: John W. Linville
--
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 4/4] clocksource: tcb_clksrc: sanitize IRQ request
The clock is not unprepared in case of the request IRQ fails.
Also update to request_irq.
Signed-off-by: Gaël PORTAY
Acked-by: Daniel Lezcano
Acked-by: Boris Brezillon
---
drivers/clocksource/tcb_clksrc.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index f922e81..8bdbc45 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -178,12 +178,6 @@ static irqreturn_t ch2_irq(int irq, void *handle)
return IRQ_NONE;
}
-static struct irqaction tc_irqaction = {
- .name = "tc_clkevt",
- .flags = IRQF_TIMER,
- .handler= ch2_irq,
-};
-
static int __init setup_clkevents(struct atmel_tc *tc, int clk32k_divisor_idx)
{
int ret;
@@ -198,15 +192,16 @@ static int __init setup_clkevents(struct atmel_tc *tc,
int clk32k_divisor_idx)
clkevt.regs = tc->regs;
clkevt.clk = t2_clk;
- tc_irqaction.dev_id =
timer_clock = clk32k_divisor_idx;
clkevt.clkevt.cpumask = cpumask_of(0);
- ret = setup_irq(irq, _irqaction);
- if (ret)
+ ret = request_irq(irq, ch2_irq, IRQF_TIMER, "tc_clkevt", );
+ if (ret) {
+ clk_disable_unprepare(t2_clk);
return ret;
+ }
clockevents_config_and_register(, 32768, 1, 0x);
--
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/
[PATCHv4 1/4] ARM: at91/tclib: prefer using of devm_* functions
Signed-off-by: Gaël PORTAY
Acked-by: Boris Brezillon
---
drivers/misc/atmel_tclib.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
index c8d8e38..b514a2d 100644
--- a/drivers/misc/atmel_tclib.c
+++ b/drivers/misc/atmel_tclib.c
@@ -150,17 +150,15 @@ static int __init tc_probe(struct platform_device *pdev)
if (irq < 0)
return -EINVAL;
- tc = kzalloc(sizeof(struct atmel_tc), GFP_KERNEL);
+ tc = devm_kzalloc(>dev, sizeof(struct atmel_tc), GFP_KERNEL);
if (!tc)
return -ENOMEM;
tc->pdev = pdev;
- clk = clk_get(>dev, "t0_clk");
- if (IS_ERR(clk)) {
- kfree(tc);
- return -EINVAL;
- }
+ clk = devm_clk_get(>dev, "t0_clk");
+ if (IS_ERR(clk))
+ return PTR_ERR(clk);
/* Now take SoC information if available */
if (pdev->dev.of_node) {
@@ -171,10 +169,10 @@ static int __init tc_probe(struct platform_device *pdev)
}
tc->clk[0] = clk;
- tc->clk[1] = clk_get(>dev, "t1_clk");
+ tc->clk[1] = devm_clk_get(>dev, "t1_clk");
if (IS_ERR(tc->clk[1]))
tc->clk[1] = clk;
- tc->clk[2] = clk_get(>dev, "t2_clk");
+ tc->clk[2] = devm_clk_get(>dev, "t2_clk");
if (IS_ERR(tc->clk[2]))
tc->clk[2] = clk;
--
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/
[PATCHv4 2/4] ARM: at91/tclib: move initialization from alloc to probe
Move resource retrieval from atmel_tc_alloc to tc_probe to avoid lately
reporting resource related issues when a TC block user request a TC block.
Moreover, resources retrieval are usually done in the probe function,
thus moving them add some consistency with other drivers.
Initialization is done once, ie not every time a tc block is requested.
If it fails, the device is not appended to the list of tc blocks.
Furhermore, the device id is retrieved at probe as well, avoiding parsing
DT every time the user requests of tc block.
Signed-off-by: Gaël PORTAY
Acked-by: Thierry Reding
Acked-by: Boris Brezillon
---
drivers/clocksource/tcb_clksrc.c | 2 +-
drivers/misc/atmel_tclib.c | 71 +---
drivers/pwm/pwm-atmel-tcb.c | 2 +-
include/linux/atmel_tc.h | 8 +++--
4 files changed, 29 insertions(+), 54 deletions(-)
diff --git a/drivers/clocksource/tcb_clksrc.c b/drivers/clocksource/tcb_clksrc.c
index a8d7ea1..f922e81 100644
--- a/drivers/clocksource/tcb_clksrc.c
+++ b/drivers/clocksource/tcb_clksrc.c
@@ -279,7 +279,7 @@ static int __init tcb_clksrc_init(void)
int i;
int ret;
- tc = atmel_tc_alloc(CONFIG_ATMEL_TCB_CLKSRC_BLOCK, clksrc.name);
+ tc = atmel_tc_alloc(CONFIG_ATMEL_TCB_CLKSRC_BLOCK);
if (!tc) {
pr_debug("can't alloc TC for clocksource\n");
return -ENODEV;
diff --git a/drivers/misc/atmel_tclib.c b/drivers/misc/atmel_tclib.c
index b514a2d..d505d1e 100644
--- a/drivers/misc/atmel_tclib.c
+++ b/drivers/misc/atmel_tclib.c
@@ -35,60 +35,31 @@ static LIST_HEAD(tc_list);
/**
* atmel_tc_alloc - allocate a specified TC block
* @block: which block to allocate
- * @name: name to be associated with the iomem resource
*
* Caller allocates a block. If it is available, a pointer to a
* pre-initialized struct atmel_tc is returned. The caller can access
* the registers directly through the "regs" field.
*/
-struct atmel_tc *atmel_tc_alloc(unsigned block, const char *name)
+struct atmel_tc *atmel_tc_alloc(unsigned block)
{
struct atmel_tc *tc;
struct platform_device *pdev = NULL;
- struct resource *r;
- size_t size;
spin_lock(_list_lock);
list_for_each_entry(tc, _list, node) {
- if (tc->pdev->dev.of_node) {
- if (of_alias_get_id(tc->pdev->dev.of_node, "tcb")
- == block) {
- pdev = tc->pdev;
- break;
- }
- } else if (tc->pdev->id == block) {
+ if (tc->allocated)
+ continue;
+
+ if ((tc->pdev->dev.of_node && tc->id == block) ||
+ (tc->pdev->id == block)) {
pdev = tc->pdev;
+ tc->allocated = true;
break;
}
}
-
- if (!pdev || tc->iomem)
- goto fail;
-
- r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!r)
- goto fail;
-
- size = resource_size(r);
- r = request_mem_region(r->start, size, name);
- if (!r)
- goto fail;
-
- tc->regs = ioremap(r->start, size);
- if (!tc->regs)
- goto fail_ioremap;
-
- tc->iomem = r;
-
-out:
spin_unlock(_list_lock);
- return tc;
-fail_ioremap:
- release_mem_region(r->start, size);
-fail:
- tc = NULL;
- goto out;
+ return pdev ? tc : NULL;
}
EXPORT_SYMBOL_GPL(atmel_tc_alloc);
@@ -96,19 +67,14 @@ EXPORT_SYMBOL_GPL(atmel_tc_alloc);
* atmel_tc_free - release a specified TC block
* @tc: Timer/counter block that was returned by atmel_tc_alloc()
*
- * This reverses the effect of atmel_tc_alloc(), unmapping the I/O
- * registers, invalidating the resource returned by that routine and
- * making the TC available to other drivers.
+ * This reverses the effect of atmel_tc_alloc(), invalidating the resource
+ * returned by that routine and making the TC available to other drivers.
*/
void atmel_tc_free(struct atmel_tc *tc)
{
spin_lock(_list_lock);
- if (tc->regs) {
- iounmap(tc->regs);
- release_mem_region(tc->iomem->start, resource_size(tc->iomem));
- tc->regs = NULL;
- tc->iomem = NULL;
- }
+ if (tc->allocated)
+ tc->allocated = false;
spin_unlock(_list_lock);
}
EXPORT_SYMBOL_GPL(atmel_tc_free);
@@ -142,9 +108,7 @@ static int __init tc_probe(struct platform_device *pdev)
struct atmel_tc *tc;
struct clk *clk;
int irq;
-
- if (!platform_get_resource(pdev, IORESOURCE_MEM, 0))
- return -EINVAL;
+ struct resource *r;
irq = platform_get_irq(pdev, 0);
if (irq < 0)
@@ -160,12 +124,21 @@ static int __init
[PATCHv4 3/4] ARM: at91/tclib: mask interruptions at shutdown and probe
Shutdown properly the timer counter block by masking interruptions. Otherwise, a segmentation may happen when kexec-ing a new kernel (see backtrace below). An interruption may happen before the handler is set, leading to a kernel segmentation fault. Furthermore, we make sure the interruptions are masked when the driver is initialized. This will prevent freshly kexec-ed kernel from crashing when launched from a kernel which does not properly mask interruptions at shutdown. The backtrace below happened after kexec-ing a new kernel, from a kernel that did not shut down properly leaving interruptions unmasked. Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 8005 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0+ #144 task: c1828aa0 ti: c182a000 task.ti: c182a000 PC is at 0x0 LR is at ch2_irq+0x28/0x30 pc : [<>]lr : []psr: 00d3 sp : c182bd38 ip : c182bd48 fp : c182bd44 r10: c0373390 r9 : c1825b00 r8 : 6053 r7 : r6 : r5 : 0013 r4 : c036e800 r3 : r2 : 2004 r1 : c036e760 r0 : c036e760 Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 20004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc182a1c0) Stack: (0xc182bd38 to 0xc182c000) bd20: c182bd7c c182bd48 bd40: c0045430 c01db8ec c18c6f40 c182bd74 c1825b00 c035cec4 bd60: c182be2c 6053 c1825b34 c182bd94 c182bd80 c0045570 c0045408 bd80: c1825b00 c182bdac c182bd98 c0047f34 c0045550 0013 c036619c bda0: c182bdc4 c182bdb0 c0044da4 c0047e98 007f 0013 c182bde4 c182bdc8 bdc0: c0009e34 c0044d8c fefff000 c0046728 6053 c182bdf4 c182bde8 bde0: c00086a8 c0009ddc c182be74 c182bdf8 c000cb80 c0008674 0013 be00: 00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34 be20: c182be74 c182be20 c182be40 c0047994 c0046728 6053 be40: 0013 c036e800 c182be64 c1825b00 0013 c036e800 c035ed98 c03874bc be60: 0004 c036e700 c182be94 c182be78 c004689c c0046398 c036e760 c18c6080 be80: c035ed10 c182bedc c182be98 c0348b08 c004684c 000c c034dac8 bea0: 004c4b3f c028c338 c036e760 0013 c014ecc8 c18e67e0 c035b9c0 c0348884 bec0: c035b9c0 c182a020 c182bf54 c182bee0 c00089fc c0348894 bee0: c00da51c c1ffcc78 c182bf0c c182bef8 c002d100 c002d09c c1ffcc78 bf00: c182bf54 c182bf10 c002d308 c0336570 c182bf3c c0334e44 0003 0003 bf20: 0030 c0334b44 c0044d74 0003 0003 c034dac8 c0350a94 c0373440 bf40: c0373440 0030 c182bf94 c182bf58 c0336d24 c000890c 0003 0003 bf60: c0336560 c182bf64 c182bf64 6e616e0d c0272fc8 bf80: c182bfac c182bf98 c0272fd8 c0336bd8 c182a000 bfa0: c182bfb0 c00095d0 c0272fd8 bfc0: bfe0: 0013 374d27cd 33cc33e4 Backtrace: [] (ch2_irq) from [] (handle_irq_event_percpu+0x38/0x148) [] (handle_irq_event_percpu) from [] (handle_irq_event+0x30/0x40) r10: r9:c1825b34 r8:6053 r7:c182be2c r6: r5:c035cec4 r4:c1825b00 [] (handle_irq_event) from [] (handle_fasteoi_irq+0xac/0x11c) r4:c1825b00 r3: [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x28/0x38) r5:c036619c r4:0013 [] (generic_handle_irq) from [] (handle_IRQ+0x68/0x88) r4:0013 r3:007f [] (handle_IRQ) from [] (at91_aic_handle_irq+0x44/0x4c) r6: r5:6053 r4:c0046728 r3:fefff000 [] (at91_aic_handle_irq) from [] (__irq_svc+0x40/0x4c) Exception stack(0xc182bdf8 to 0xc182be40) bde0: 0013 be00: 00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34 be20: c182be74 c182be20 c182be40 c0047994 c0046728 6053 [] (__setup_irq) from [] (setup_irq+0x60/0x8c) r10:c036e700 r9:0004 r8:c03874bc r7:c035ed98 r6:c036e800 r5:0013 r4:c1825b00 [] (setup_irq) from [] (tcb_clksrc_init+0x284/0x31c) r6:c035ed10 r5: r4:c18c6080 r3:c036e760 [] (tcb_clksrc_init) from [] (do_one_initcall+0x100/0x1b4) r10: r9: r8:c182a020 r7:c035b9c0 r6:c0348884 r5:c035b9c0 r4:c18e67e0 [] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x224) r9:0030 r8:c0373440 r7:c0373440 r6:c0350a94 r5:c034dac8 r4:0003 [] (kernel_init_freeable) from [] (kernel_init+0x10/0xec) r9: r8: r7: r6: r5:c0272fc8 r4: [] (kernel_init) from [] (ret_from_fork+0x14/0x24) r4: r3:c182a000 Code: bad PC value ---[ end trace 5b30f0017e282e47 ]--- Kernel panic - not syncing: Fatal exception in interrupt Signed-off-by: Gaël PORTAY Acked-by: Boris Brezillon
[PATCHv4 0/4] ARM: at91/tclib: fix segmentation fault
Hi every one, This set of patches fix a segmentation fault happening when kexec-ing kernel on an at91 platform (see backtrace below). While the previous kernel shuts down, the tcb_clksrc driver leaves its interruptions unmasked. When the new kernel initiliazes any tclib making use of a TC block, an interruption may happen before the interrupt handler is set, causing a kernel segmentation fault. To prevent from such cases from happening, the last patch sets up the shutdown callback which masks interruptions when the machine is shutdown. Furthermore, it also masks the interruptions at probe to make sure no interruption happens before the handler is set. This will prevent freshly kexec-ed kernel from crashing when launched from a kernel which does not properly mask interruptions at shutdown. Unable to handle kernel NULL pointer dereference at virtual address pgd = c0004000 [] *pgd= Internal error: Oops: 8005 [#1] ARM Modules linked in: CPU: 0 PID: 1 Comm: swapper Not tainted 3.16.0+ #144 task: c1828aa0 ti: c182a000 task.ti: c182a000 PC is at 0x0 LR is at ch2_irq+0x28/0x30 pc : [<>]lr : []psr: 00d3 sp : c182bd38 ip : c182bd48 fp : c182bd44 r10: c0373390 r9 : c1825b00 r8 : 6053 r7 : r6 : r5 : 0013 r4 : c036e800 r3 : r2 : 2004 r1 : c036e760 r0 : c036e760 Flags: nzcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel Control: 0005317f Table: 20004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc182a1c0) Stack: (0xc182bd38 to 0xc182c000) bd20: c182bd7c c182bd48 bd40: c0045430 c01db8ec c18c6f40 c182bd74 c1825b00 c035cec4 bd60: c182be2c 6053 c1825b34 c182bd94 c182bd80 c0045570 c0045408 bd80: c1825b00 c182bdac c182bd98 c0047f34 c0045550 0013 c036619c bda0: c182bdc4 c182bdb0 c0044da4 c0047e98 007f 0013 c182bde4 c182bdc8 bdc0: c0009e34 c0044d8c fefff000 c0046728 6053 c182bdf4 c182bde8 bde0: c00086a8 c0009ddc c182be74 c182bdf8 c000cb80 c0008674 0013 be00: 00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34 be20: c182be74 c182be20 c182be40 c0047994 c0046728 6053 be40: 0013 c036e800 c182be64 c1825b00 0013 c036e800 c035ed98 c03874bc be60: 0004 c036e700 c182be94 c182be78 c004689c c0046398 c036e760 c18c6080 be80: c035ed10 c182bedc c182be98 c0348b08 c004684c 000c c034dac8 bea0: 004c4b3f c028c338 c036e760 0013 c014ecc8 c18e67e0 c035b9c0 c0348884 bec0: c035b9c0 c182a020 c182bf54 c182bee0 c00089fc c0348894 bee0: c00da51c c1ffcc78 c182bf0c c182bef8 c002d100 c002d09c c1ffcc78 bf00: c182bf54 c182bf10 c002d308 c0336570 c182bf3c c0334e44 0003 0003 bf20: 0030 c0334b44 c0044d74 0003 0003 c034dac8 c0350a94 c0373440 bf40: c0373440 0030 c182bf94 c182bf58 c0336d24 c000890c 0003 0003 bf60: c0336560 c182bf64 c182bf64 6e616e0d c0272fc8 bf80: c182bfac c182bf98 c0272fd8 c0336bd8 c182a000 bfa0: c182bfb0 c00095d0 c0272fd8 bfc0: bfe0: 0013 374d27cd 33cc33e4 Backtrace: [] (ch2_irq) from [] (handle_irq_event_percpu+0x38/0x148) [] (handle_irq_event_percpu) from [] (handle_irq_event+0x30/0x40) r10: r9:c1825b34 r8:6053 r7:c182be2c r6: r5:c035cec4 r4:c1825b00 [] (handle_irq_event) from [] (handle_fasteoi_irq+0xac/0x11c) r4:c1825b00 r3: [] (handle_fasteoi_irq) from [] (generic_handle_irq+0x28/0x38) r5:c036619c r4:0013 [] (generic_handle_irq) from [] (handle_IRQ+0x68/0x88) r4:0013 r3:007f [] (handle_IRQ) from [] (at91_aic_handle_irq+0x44/0x4c) r6: r5:6053 r4:c0046728 r3:fefff000 [] (at91_aic_handle_irq) from [] (__irq_svc+0x40/0x4c) Exception stack(0xc182bdf8 to 0xc182be40) bde0: 0013 be00: 00014200 c1825b00 c036e800 0013 c035ed98 6053 c1825b34 be20: c182be74 c182be20 c182be40 c0047994 c0046728 6053 [] (__setup_irq) from [] (setup_irq+0x60/0x8c) r10:c036e700 r9:0004 r8:c03874bc r7:c035ed98 r6:c036e800 r5:0013 r4:c1825b00 [] (setup_irq) from [] (tcb_clksrc_init+0x284/0x31c) r6:c035ed10 r5: r4:c18c6080 r3:c036e760 [] (tcb_clksrc_init) from [] (do_one_initcall+0x100/0x1b4) r10: r9: r8:c182a020 r7:c035b9c0 r6:c0348884 r5:c035b9c0 r4:c18e67e0 [] (do_one_initcall) from [] (kernel_init_freeable+0x15c/0x224) r9:0030 r8:c0373440 r7:c0373440 r6:c0350a94 r5:c034dac8 r4:0003 [] (kernel_init_freeable) from [] (kernel_init+0x10/0xec) r9: r8: r7: r6: r5:c0272fc8 r4: [] (kernel_init) from [] (ret_from_fork+0x14/0x24)
3.16.2: kernel BUG at fs/buffer.c:3018!
Well, definitely I made a mistake during my first attempts to mount a qcow2 image file via a loop devices - but the BUG shouldn't occur, or ? : System is a 32 bit stable Gentoo. ep 6 19:37:05 n22 kernel: kernel BUG at fs/buffer.c:3018! Sep 6 19:37:05 n22 kernel: invalid opcode: [#1] SMP Sep 6 19:37:05 n22 kernel: Modules linked in: nbd nfsd auth_rpcgss oid_registry ip6t_REJECT ip6table_filter ip6_tables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat xt_owner xt_LOG xt_limit xt_multiport ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 xt_tcpudp xt_recent xt_conntrack iptable_filter ip_tables x_tables nf_conntrack_ftp nf_conntrack ctr ccm af_packet bridge stp ipv6 llc tun x86_pkg_temp_thermal coretemp kvm_intel kvm snd_hda_codec_conexant snd_hda_codec_generic i915 snd_hda_intel snd_hda_controller sdhci_pci snd_hda_codec psmouse arc4 iwldvm sdhci mac80211 evdev uvcvideo videobuf2_vmalloc fbcon videobuf2_memops videobuf2_core bitblit cfbfillrect softcursor v4l2_common cfbimgblt font videodev i2c_algo_bit cfbcopyarea thinkpad_acpi snd_pcm atkbd drm_kms_helper snd_timer nvram mmc_core drm intel_gtt snd thermal iwlwifi agpgart wmi video 8250_pci 8250 serial_core soundcore e1000e ac battery cfg80211 tpm_tis i2c_i801 i2c_core fb fbdev rfkill ptp button tpm pps_core acpi_cpufreq p rocessor thermal_sys hwmon aesni_intel xts aes_i586 lrw gf128mul ablk_helper cryptd cbc fuse nfs lockd sunrpc btrfs xor raid6_pq dm_crypt dm_mod hid_monterey hid_microsoft hid_logitech hid_ezkey hid_cypress hid_chicony hid_cherry hid_belkin hid_apple hid_a4tech hid_generic usbhid uhci_hcd hid sr_mod cdrom sg [last unloaded: microcode] Sep 6 19:37:05 n22 kernel: CPU: 2 PID: 27864 Comm: umount Not tainted 3.16.2 #9 Sep 6 19:37:05 n22 kernel: Hardware name: LENOVO 4180F65/4180F65, BIOS 83ET75WW (1.45 ) 05/10/2013 Sep 6 19:37:05 n22 kernel: task: e38c0b30 ti: e3e5c000 task.ti: e3e5c000 Sep 6 19:37:05 n22 kernel: EIP: 0060:[] EFLAGS: 00010246 CPU: 2 Sep 6 19:37:05 n22 kernel: EIP is at _submit_bh+0x257/0x260 Sep 6 19:37:05 n22 kernel: EAX: 0005 EBX: ECX: EDX: e8b8bc78 Sep 6 19:37:05 n22 kernel: ESI: e8b8bc78 EDI: 0411 EBP: e3e5de8c ESP: e3e5de60 Sep 6 19:37:05 n22 kernel: DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Sep 6 19:37:05 n22 kernel: CR0: 80050033 CR2: 093ef038 CR3: 30b54000 CR4: 000407f0 Sep 6 19:37:05 n22 kernel: Stack: Sep 6 19:37:05 n22 kernel: 0001 0046 c12610b5 0282 e6c878fc 0282 e3e5de88 0282 Sep 6 19:37:05 n22 kernel: e8b8bc78 0411 e8b8bc78 e3e5dea0 c1173d8e 7914 e6c85000 Sep 6 19:37:05 n22 kernel: e3e5dea8 c1173e12 e3e5dedc c11c6c2a c13ffe82 c15fa700 e3e5ded4 0001 Sep 6 19:37:05 n22 kernel: Call Trace: Sep 6 19:37:05 n22 kernel: [] ? __percpu_counter_sum+0x85/0xa0 Sep 6 19:37:05 n22 kernel: [] __sync_dirty_buffer+0x5e/0xd0 Sep 6 19:37:05 n22 kernel: [] sync_dirty_buffer+0x12/0x20 Sep 6 19:37:05 n22 kernel: [] ext4_commit_super+0x19a/0x230 Sep 6 19:37:05 n22 kernel: [] ? _raw_spin_unlock+0x22/0x30 Sep 6 19:37:05 n22 kernel: [] ext4_put_super+0xb0/0x300 Sep 6 19:37:05 n22 kernel: [] ? dispose_list+0x32/0x40 Sep 6 19:37:05 n22 kernel: [] ? evict_inodes+0xe2/0xf0 Sep 6 19:37:05 n22 kernel: [] generic_shutdown_super+0x67/0xe0 Sep 6 19:37:05 n22 kernel: [] ? unregister_shrinker+0x40/0x50 Sep 6 19:37:05 n22 kernel: [] kill_block_super+0x22/0x70 Sep 6 19:37:05 n22 kernel: [] deactivate_locked_super+0x3d/0x50 Sep 6 19:37:05 n22 kernel: [] deactivate_super+0x43/0x60 Sep 6 19:37:05 n22 kernel: [] mntput_no_expire+0xf5/0x180 Sep 6 19:37:05 n22 kernel: [] ? mntput_no_expire+0x12/0x180 Sep 6 19:37:05 n22 kernel: [] SyS_oldumount+0x75/0xb0 Sep 6 19:37:05 n22 kernel: [] sysenter_do_call+0x12/0x12 Sep 6 19:37:05 n22 kernel: Code: f0 80 66 01 f7 e9 1e fe ff ff 8d 76 00 8d bc 27 00 00 00 00 39 45 e8 76 8b e9 1e ff ff ff 0f 0b 0f 0b 0f 0b f3 90 e9 c2 fe ff ff <0f> 0b 0f 0b 90 8d 74 26 00 55 89 e5 66 66 66 66 90 31 c9 e8 91 Sep 6 19:37:05 n22 kernel: EIP: [] _submit_bh+0x257/0x260 SS:ESP 0068:e3e5de60 Sep 6 19:37:05 n22 kernel: ---[ end trace d75285e0ad72f2d1 ]--- Sep 6 19:37:18 n22 kernel: block nbd0: NBD_DISCONNECT S FWIW my mistake was to to run the commands $> qemu-nbd -c /dev/nbd0 -P 3 /var/lib/libvirt/images/Gentoo-clone.qcow2 $> mount /dev/nbd0 /mnt/ramdisk/n0 $> umount /mnt/ramdisk/n0 in the wrong order. -- Toralf pgp key: 0076 E94E -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] staging: lustre: fix pointer whitespace style
Fix errors reported by checkpatch of this kind:
ERROR: "foo * bar" should be "foo *bar"
Signed-off-by: Spencer Baugh
---
drivers/staging/lustre/lustre/include/lustre_import.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_import.h
b/drivers/staging/lustre/lustre/include/lustre_import.h
index feb4291..b71877b 100644
--- a/drivers/staging/lustre/lustre/include/lustre_import.h
+++ b/drivers/staging/lustre/lustre/include/lustre_import.h
@@ -103,9 +103,9 @@ enum lustre_imp_state {
};
/** Returns test string representation of numeric import state \a state */
-static inline char * ptlrpc_import_state_name(enum lustre_imp_state state)
+static inline char *ptlrpc_import_state_name(enum lustre_imp_state state)
{
- static char* import_state_names[] = {
+ static char *import_state_names[] = {
"", "CLOSED", "NEW", "DISCONN",
"CONNECTING", "REPLAY", "REPLAY_LOCKS", "REPLAY_WAIT",
"RECOVER", "FULL", "EVICTED",
--
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/3] staging: lustre: remove trailing whitespace
Fix errors reported by checkpatch of this kind:
ERROR: trailing whitespace
Signed-off-by: Spencer Baugh
---
drivers/staging/lustre/lustre/include/lustre_import.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_import.h
b/drivers/staging/lustre/lustre/include/lustre_import.h
index b71877b..51f3e98 100644
--- a/drivers/staging/lustre/lustre/include/lustre_import.h
+++ b/drivers/staging/lustre/lustre/include/lustre_import.h
@@ -346,7 +346,7 @@ static inline unsigned int at_timeout2est(unsigned int val)
return (max((val << 2) / 5, 5U) - 4);
}
-static inline void at_reset(struct adaptive_timeout *at, int val)
+static inline void at_reset(struct adaptive_timeout *at, int val)
{
spin_lock(>at_lock);
at->at_current = val;
@@ -354,7 +354,7 @@ static inline void at_reset(struct adaptive_timeout *at,
int val)
at->at_worst_time = get_seconds();
spin_unlock(>at_lock);
}
-static inline void at_init(struct adaptive_timeout *at, int val, int flags)
+static inline void at_init(struct adaptive_timeout *at, int val, int flags)
{
memset(at, 0, sizeof(*at));
spin_lock_init(>at_lock);
@@ -362,7 +362,7 @@ static inline void at_init(struct adaptive_timeout *at, int
val, int flags)
at_reset(at, val);
}
extern unsigned int at_min;
-static inline int at_get(struct adaptive_timeout *at)
+static inline int at_get(struct adaptive_timeout *at)
{
return (at->at_current > at_min) ? at->at_current : at_min;
}
--
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/3] staging: lustre: fix function definition style
Fix errors reported by checkpatch of this kind:
ERROR: open brace '{' following function declarations go on the next line
Signed-off-by: Spencer Baugh
---
drivers/staging/lustre/lustre/include/lustre_import.h | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/lustre/lustre/include/lustre_import.h
b/drivers/staging/lustre/lustre/include/lustre_import.h
index 8304a55..feb4291 100644
--- a/drivers/staging/lustre/lustre/include/lustre_import.h
+++ b/drivers/staging/lustre/lustre/include/lustre_import.h
@@ -346,21 +346,24 @@ static inline unsigned int at_timeout2est(unsigned int
val)
return (max((val << 2) / 5, 5U) - 4);
}
-static inline void at_reset(struct adaptive_timeout *at, int val) {
+static inline void at_reset(struct adaptive_timeout *at, int val)
+{
spin_lock(>at_lock);
at->at_current = val;
at->at_worst_ever = val;
at->at_worst_time = get_seconds();
spin_unlock(>at_lock);
}
-static inline void at_init(struct adaptive_timeout *at, int val, int flags) {
+static inline void at_init(struct adaptive_timeout *at, int val, int flags)
+{
memset(at, 0, sizeof(*at));
spin_lock_init(>at_lock);
at->at_flags = flags;
at_reset(at, val);
}
extern unsigned int at_min;
-static inline int at_get(struct adaptive_timeout *at) {
+static inline int at_get(struct adaptive_timeout *at)
+{
return (at->at_current > at_min) ? at->at_current : at_min;
}
int at_measured(struct adaptive_timeout *at, unsigned int val);
--
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/
ARM kirkwood: 1 Gb memory 25% unusable due to vmalloc region overlap
I updated my Qnap TS-212 with 256 Mb memory to a new TS-221 with 1 Gb memory. On booting, I see that a large chunk of that new memory is not used by linux: [0.00] Booting Linux on physical CPU 0x0 [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 3.14-2-kirkwood (debian-ker...@lists.debian.org) (gcc version 4.8.3 (Debian 4.8.3-7) ) #1 Debian 3.14.15-2 (2014-08-09) [0.00] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 [0.00] CPU: VIVT data cache, VIVT instruction cache [0.00] Machine: QNAP TS-119/TS-219 [0.00] Ignoring unrecognised tag 0x41000403 [0.00] Truncating RAM at 2000-3fff to -2f7f (vmalloc region overlap). Whoops! [0.00] Memory policy: Data cache writeback [0.00] On node 0 totalpages: 194560 [0.00] free_area_init_node: node 0, pgdat c05af874, node_mem_map ef20b000 [0.00] DMA zone: 1520 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 194560 pages, LIFO batch:31 [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 193040 [0.00] Kernel command line: console=ttyS0,115200 root=/dev/ram initrd=0xa0,0x90 ramdisk=34816 [0.00] PID hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) [0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) [0.00] Memory: 755820K/778240K available (3869K kernel code, 352K rwdata, 1412K rodata, 202K init, 417K bss, 22420K reserved) [0.00] Virtual kernel memory layout: [0.00] vector : 0x - 0x1000 ( 4 kB) [0.00] fixmap : 0xfff0 - 0xfffe ( 896 kB) [0.00] vmalloc : 0xf000 - 0xff00 ( 240 MB) [0.00] lowmem : 0xc000 - 0xef80 ( 760 MB) [0.00] modules : 0xbf00 - 0xc000 ( 16 MB) [0.00] .text : 0xc0008000 - 0xc053097c (5283 kB) [0.00] .init : 0xc0531000 - 0xc0563b34 ( 203 kB) [0.00] .data : 0xc0564000 - 0xc05bc128 ( 353 kB) [0.00].bss : 0xc05bc128 - 0xc06246c4 ( 418 kB) [0.00] NR_IRQS:114 As far as I've been able to determine, this config is used in the debian linux-image-3.14-2-kirkwood package: CONFIG_ARCH_KIRKWOOD=y CONFIG_PCI=y CONFIG_UACCESS_WITH_MEMCPY=y CONFIG_ZBOOT_ROM_TEXT=0x0 CONFIG_ZBOOT_ROM_BSS=0x0 CONFIG_ARM_APPENDED_DTB=y CONFIG_ARM_ATAG_DTB_COMPAT=y CONFIG_CMDLINE="" CONFIG_KEXEC=y CONFIG_ATAGS_PROC=y CONFIG_FPE_NWFPE=y CONFIG_MACH_D2NET_V2=y CONFIG_MACH_DOCKSTAR=y CONFIG_MACH_ESATA_SHEEVAPLUG=y CONFIG_MACH_GURUPLUG=y CONFIG_MACH_INETSPACE_V2=y CONFIG_MACH_MV88F6281GTW_GE=y CONFIG_MACH_NET2BIG_V2=y CONFIG_MACH_NET5BIG_V2=y CONFIG_MACH_NETSPACE_MAX_V2=y CONFIG_MACH_NETSPACE_V2=y CONFIG_MACH_OPENRD_BASE=y CONFIG_MACH_OPENRD_CLIENT=y CONFIG_MACH_OPENRD_ULTIMATE=y CONFIG_MACH_RD88F6192_NAS=y CONFIG_MACH_RD88F6281=y CONFIG_MACH_SHEEVAPLUG=y CONFIG_MACH_T5325=y CONFIG_MACH_TS219=y CONFIG_MACH_TS41X=y CONFIG_ARCH_KIRKWOOD_DT=y CONFIG_MACH_DLINK_KIRKWOOD_DT=y CONFIG_MACH_DOCKSTAR_DT=y CONFIG_MACH_DREAMPLUG_DT=y CONFIG_MACH_GOFLEXNET_DT=y CONFIG_MACH_GURUPLUG_DT=y CONFIG_MACH_IB62X0_DT=y CONFIG_MACH_ICONNECT_DT=y CONFIG_MACH_INETSPACE_V2_DT=y CONFIG_MACH_IOMEGA_IX2_200_DT=y CONFIG_MACH_KM_KIRKWOOD_DT=y CONFIG_MACH_LSXL_DT=y CONFIG_MACH_MPLCEC4_DT=y CONFIG_MACH_NETSPACE_LITE_V2_DT=y CONFIG_MACH_NETSPACE_MAX_V2_DT=y CONFIG_MACH_NETSPACE_MINI_V2_DT=y CONFIG_MACH_NETSPACE_V2_DT=y CONFIG_MACH_OPENBLOCKS_A6_DT=y CONFIG_MACH_TOPKICK_DT=y CONFIG_MACH_TS219_DT=y CONFIG_ARM_THUMB=y CONFIG_ACORN_PARTITION=y CONFIG_ACORN_PARTITION_ICS=y CONFIG_ACORN_PARTITION_RISCIX=y CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y CONFIG_ATARI_PARTITION=y CONFIG_MAC_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y CONFIG_SOLARIS_X86_PARTITION=y CONFIG_UNIXWARE_DISKLABEL=y CONFIG_LDM_PARTITION=y CONFIG_SGI_PARTITION=y CONFIG_ULTRIX_PARTITION=y CONFIG_SUN_PARTITION=y CONFIG_ATA=m CONFIG_SATA_AHCI=m CONFIG_ATA_SFF=y CONFIG_SATA_MV=m CONFIG_BT_HCIBCM203X=m CONFIG_BT_HCIBPA10X=m CONFIG_BT_HCIBFUSB=m CONFIG_BT_HCIVHCI=m CONFIG_CPU_IDLE=y CONFIG_CRYPTO_DEV_MV_CESA=m CONFIG_DMADEVICES=y CONFIG_MV_XOR=y CONFIG_GPIO_SYSFS=y CONFIG_SENSORS_GPIO_FAN=m CONFIG_I2C=y CONFIG_I2C_CHARDEV=y CONFIG_I2C_MV64XXX=y CONFIG_GAMEPORT=m CONFIG_INPUT_JOYSTICK=y CONFIG_KEYBOARD_GPIO=m CONFIG_INPUT_TOUCHSCREEN=y CONFIG_ISDN=y CONFIG_ISDN_CAPI=m CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON=y CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=m CONFIG_ISDN_CAPI_CAPIDRV=m CONFIG_CAPI_AVM=y CONFIG_ISDN_DRV_AVMB1_B1PCI=m CONFIG_ISDN_DRV_AVMB1_B1PCIV4=y CONFIG_ISDN_DRV_AVMB1_B1PCMCIA=m
Re: 回复： Re: 回复： Re: 回复： Re: 回复： Status of 'unicore32' architecture in Linux kernel
On 09/04/2014 11:13 PM, Xuetao Guan wrote: - Guenter Roeck 写道： On 09/03/2014 01:32 AM, Xuetao Guan wrote: [ ... ] Please try the following patch. That seems to do it. I am sure it can be improved, but it is a start. Thanks, Guenter Thanks. I'll test it. BTW, Qemu codestyle is different, and tab should be replaced with blanks. Here is where I am. User space code (busybox) was compiled using the unicore toolchain available on the web. ... serio: i8042 KBD port at 0x6eb00060,0x6eb00064 irq 22 mousedev: PS/2 mouse device common for all mice Enable UniCore-F64 support. Warning: unable to open an initial console. Freeing unused kernel memory: 1156K (c0408000 - c0529000) Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b The kernel tries to execute the init program, which fails with SIGSEGV. I confirmed that the init program is loaded and starts to execute. Any idea what might cause such a problem ? Thanks, Guenter 'slink /init /bin/busybox 777 0 0' should be inserted in initramfs config Also, I recommend compile busybox statically for initramfs. I need more information, including full kmsg and initramfs configs Hi, I made everything I have available at http://server.roeck-us.net/qemu/unicore32/. I tried multiple variants for creating the root file system, including the one on https://github.com/gxt/UniCore32.git and the one using mkrootfs.sh in the link above. No difference - I always see the same crash. Note that the 'init' program is loading, but crashes with above error (0x000b is SIGSEGV unless I am missing something). Note that I used the latest qemu for unicore from upstream sources; I was unable to compile it from g...@github.com:gxt/QEMU.git. Qemu configuration did not seem to make a difference. The toolchain was extracted from uc4-1.0.5-hard.tgz. Hope this helps, 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/
[PATCH 1/4] tty: vt8500_serial: add support for UART in WM8880 chips
Newer WonderMedia chips introduced another flag in the UART line control
register, which controls whether RTS/CTS signalling should be handled in
the driver or by the hardware itself.
This patch ensures that the kernel can control RTS/CTS (including
disabling it altogether) by forcing this flag to software mode on affected
chips (only WM8880 so far).
Also remove the redundant copy of the binding doc, while we are here.
Signed-off-by: Alexey Charkov
---
.../devicetree/bindings/serial/via,vt8500-uart.txt | 17 --
.../devicetree/bindings/serial/vt8500-uart.txt | 3 +-
drivers/tty/serial/vt8500_serial.c | 70 +-
3 files changed, 58 insertions(+), 32 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/serial/via,vt8500-uart.txt
diff --git a/Documentation/devicetree/bindings/serial/via,vt8500-uart.txt
b/Documentation/devicetree/bindings/serial/via,vt8500-uart.txt
deleted file mode 100644
index 5feef1e..000
--- a/Documentation/devicetree/bindings/serial/via,vt8500-uart.txt
+++ /dev/null
@@ -1,17 +0,0 @@
-VIA/Wondermedia VT8500 UART Controller
--
-
-Required properties:
-- compatible : "via,vt8500-uart"
-- reg : Should contain 1 register ranges(address and length)
-- interrupts : UART interrupt
-- clocks : phandle to the uart source clock (usually a 24Mhz fixed clock)
-
-Example:
-
- uart@d821 {
- compatible = "via,vt8500-uart";
- reg = <0xd821 0x1040>;
- interrupts = <47>;
- clocks = <>;
- };
diff --git a/Documentation/devicetree/bindings/serial/vt8500-uart.txt
b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
index 795c393..2b64e61 100644
--- a/Documentation/devicetree/bindings/serial/vt8500-uart.txt
+++ b/Documentation/devicetree/bindings/serial/vt8500-uart.txt
@@ -1,7 +1,8 @@
* VIA VT8500 and WonderMedia WM8xxx UART Controller
Required properties:
-- compatible: should be "via,vt8500-uart"
+- compatible: should be "via,vt8500-uart" (for VIA/WonderMedia chips up to and
+ including WM8850/WM8950), or "wm,wm8880-uart" (for WM8880 and later)
- reg: base physical address of the controller and length of memory mapped
region.
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 15ad6fc..f225719 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -33,8 +33,8 @@
#include
#include
#include
-#include
#include
+#include
#include
/*
@@ -78,6 +78,29 @@
#define RX_FIFO_INTS (RXFAF | RXFF | RXOVER | PER | FER | RXTOUT)
#define TX_FIFO_INTS (TXFAE | TXFE | TXUDR)
+/*
+ * Line control bits
+ */
+
+#define VT8500_TXEN(1 << 0)/* Enable transmit logic */
+#define VT8500_RXEN(1 << 1)/* Enable receive logic */
+#define VT8500_CS8 (1 << 2)/* 8-bit data length (vs. 7-bit) */
+#define VT8500_CSTOPB (1 << 3)/* 2 stop bits (vs. 1) */
+#define VT8500_PARENB (1 << 4)/* Enable parity */
+#define VT8500_PARODD (1 << 5)/* Odd parity (vs. even) */
+#define VT8500_RTS (1 << 6)/* Ready to send */
+#define VT8500_LOOPBK (1 << 7)/* Enable internal loopback */
+#define VT8500_DMA (1 << 8)/* Enable DMA mode (needs FIFO) */
+#define VT8500_BREAK (1 << 9)/* Initiate break signal */
+#define VT8500_PSLVERR (1 << 10) /* APB error upon empty RX FIFO read */
+#define VT8500_SWRTSCTS(1 << 11) /* Software-controlled RTS/CTS
*/
+
+/*
+ * Capability flags (driver-internal)
+ */
+
+#define VT8500_HAS_SWRTSCTS_SWITCH (1 << 1)
+
#define VT8500_MAX_PORTS 6
struct vt8500_port {
@@ -85,6 +108,7 @@ struct vt8500_port {
charname[16];
struct clk *clk;
unsigned intier;
+ unsigned intvt8500_uart_flags;
};
/*
@@ -272,7 +296,8 @@ static void vt8500_set_mctrl(struct uart_port *port,
unsigned int mctrl)
static void vt8500_break_ctl(struct uart_port *port, int break_ctl)
{
if (break_ctl)
- vt8500_write(port, vt8500_read(port, VT8500_URLCR) | (1 << 9),
+ vt8500_write(port,
+vt8500_read(port, VT8500_URLCR) | VT8500_BREAK,
VT8500_URLCR);
}
@@ -347,31 +372,35 @@ static void vt8500_set_termios(struct uart_port *port,
/* calculate parity */
lcr = vt8500_read(_port->uart, VT8500_URLCR);
- lcr &= ~((1 << 5) | (1 << 4));
+ lcr &= ~(VT8500_PARENB | VT8500_PARODD);
if (termios->c_cflag & PARENB) {
- lcr |= (1 << 4);
+ lcr |= VT8500_PARENB;
termios->c_cflag &= ~CMSPAR;
if (termios->c_cflag & PARODD)
- lcr |= (1 << 5);
+ lcr |= VT8500_PARODD;
}
/* calculate bits per char */
-
[PATCH 2/4] tty: vt8500_serial: add missing support for RTS setting
Signed-off-by: Alexey Charkov
---
drivers/tty/serial/vt8500_serial.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index f225719..47e74f9 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -291,6 +291,14 @@ static unsigned int vt8500_get_mctrl(struct uart_port
*port)
static void vt8500_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
+ unsigned int lcr = vt8500_read(port, VT8500_URLCR);
+
+ if (mctrl & TIOCM_RTS)
+ lcr |= VT8500_RTS;
+ else
+ lcr &= ~VT8500_RTS;
+
+ vt8500_write(port, lcr, VT8500_URLCR);
}
static void vt8500_break_ctl(struct uart_port *port, int break_ctl)
--
2.0.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/4] tty: vt8500_serial: explicitly calculate base baud rate
Current code relies on the UART clock pre-divisor to be already
configured in the baud rate register. Calculate it in the driver
and set explicitly instead, also return the "real" effective baud
rate, which is generally slightly different from the requested value.
While at this, also ensure that break signal timing is updated when
baud rate changes.
Signed-off-by: Alexey Charkov
---
drivers/tty/serial/vt8500_serial.c | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index 47e74f9..bfcebfd 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -101,12 +101,15 @@
#define VT8500_HAS_SWRTSCTS_SWITCH (1 << 1)
+#define VT8500_RECOMMENDED_CLK 1200
+#define VT8500_OVERSAMPLING_DIVISOR13
#define VT8500_MAX_PORTS 6
struct vt8500_port {
struct uart_portuart;
charname[16];
struct clk *clk;
+ unsigned intclk_predivisor;
unsigned intier;
unsigned intvt8500_uart_flags;
};
@@ -311,20 +314,25 @@ static void vt8500_break_ctl(struct uart_port *port, int
break_ctl)
static int vt8500_set_baud_rate(struct uart_port *port, unsigned int baud)
{
+ struct vt8500_port *vt8500_port =
+ container_of(port, struct vt8500_port, uart);
unsigned long div;
unsigned int loops = 1000;
- div = vt8500_read(port, VT8500_URDIV) & ~(0x3ff);
+ div = ((vt8500_port->clk_predivisor - 1) & 0xf) << 16;
+ div |= (uart_get_divisor(port, baud) - 1) & 0x3ff;
- if (unlikely((baud < 900) || (baud > 921600)))
- div |= 7;
- else
- div |= (921600 / baud) - 1;
+ /* Effective baud rate */
+ baud = port->uartclk / 16 / ((div & 0x3ff) + 1);
while ((vt8500_read(port, VT8500_URUSR) & (1 << 5)) && --loops)
cpu_relax();
+
vt8500_write(port, div, VT8500_URDIV);
+ /* Break signal timing depends on baud rate, update accordingly */
+ vt8500_write(port, mult_frac(baud, 4096, 100), VT8500_URBKR);
+
return baud;
}
@@ -660,6 +668,10 @@ static int vt8500_serial_probe(struct platform_device
*pdev)
}
vt8500_port->vt8500_uart_flags = *flags;
+ vt8500_port->clk_predivisor = DIV_ROUND_CLOSEST(
+ clk_get_rate(vt8500_port->clk),
+ VT8500_RECOMMENDED_CLK
+ );
vt8500_port->uart.type = PORT_VT8500;
vt8500_port->uart.iotype = UPIO_MEM;
vt8500_port->uart.mapbase = mmres->start;
@@ -670,7 +682,10 @@ static int vt8500_serial_probe(struct platform_device
*pdev)
vt8500_port->uart.dev = >dev;
vt8500_port->uart.flags = UPF_IOREMAP | UPF_BOOT_AUTOCONF;
- vt8500_port->uart.uartclk = clk_get_rate(vt8500_port->clk);
+ /* Serial core uses the magic "16" everywhere - adjust for it */
+ vt8500_port->uart.uartclk = 16 * clk_get_rate(vt8500_port->clk) /
+ vt8500_port->clk_predivisor /
+ VT8500_OVERSAMPLING_DIVISOR;
snprintf(vt8500_port->name, sizeof(vt8500_port->name),
"VT8500 UART%d", pdev->id);
--
2.0.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/4] tty: vt8500_serial: add polled console functions
This adds simple polling functions for single-character transmit
and receive, as used by kgdb.
Signed-off-by: Alexey Charkov
---
drivers/tty/serial/vt8500_serial.c | 31 +++
1 file changed, 31 insertions(+)
diff --git a/drivers/tty/serial/vt8500_serial.c
b/drivers/tty/serial/vt8500_serial.c
index bfcebfd..b2bc9e8 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -566,6 +566,33 @@ static struct console vt8500_console = {
#define VT8500_CONSOLE NULL
#endif
+#ifdef CONFIG_CONSOLE_POLL
+static int vt8500_get_poll_char(struct uart_port *port)
+{
+ unsigned int status = vt8500_read(port, VT8500_URFIDX);
+
+ if (!(status & 0x1f00))
+ return NO_POLL_CHAR;
+
+ return vt8500_read(port, VT8500_RXFIFO) & 0xff;
+}
+
+static void vt8500_put_poll_char(struct uart_port *port, unsigned char c)
+{
+ unsigned int status, tmout = 1;
+
+ do {
+ status = vt8500_read(port, VT8500_URFIDX);
+
+ if (--tmout == 0)
+ break;
+ udelay(1);
+ } while (status & 0x10);
+
+ vt8500_write(port, c, VT8500_TXFIFO);
+}
+#endif
+
static struct uart_ops vt8500_uart_pops = {
.tx_empty = vt8500_tx_empty,
.set_mctrl = vt8500_set_mctrl,
@@ -583,6 +610,10 @@ static struct uart_ops vt8500_uart_pops = {
.request_port = vt8500_request_port,
.config_port= vt8500_config_port,
.verify_port= vt8500_verify_port,
+#ifdef CONFIG_CONSOLE_POLL
+ .poll_get_char = vt8500_get_poll_char,
+ .poll_put_char = vt8500_put_poll_char,
+#endif
};
static struct uart_driver vt8500_uart_driver = {
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] tty: vt8500_serial: Changes for -next
Hi all, This series introduces a bit of clean-up (reduce magic numbers) and new features for the VT8500 serial driver. Firstly, in a new generation of WonderMedia SoC's the UART module changed slightly, and now requires one more bit to be set in its line control register to function properly. This is handled in the first patch by adding a new DT 'compatible' string for the new chips. Secondly, a couple of ommissions from the initial driver version are now filled, namely RTS setting (second patch) and correct calculation of baud rate predivisors, divisors etc. for any given input clock (third patch). Initial version implicitly assumed input clock to be always 24MHz and predivisor to be /2 (which holds for current chips, but doesn't need to hold in general). Thirdly, polled console functions are now implemented (fourth patch) to support KGDB over VT8500 UART. These changes have been tested on a WonderMedia WM8880 netbook (all), and on a VIA Springboard (WM8950) (all except KGDB). Greg, could you please merge these for -next, if they look fine? Thanks a lot, Alexey Alexey Charkov (4): tty: vt8500_serial: add support for UART in WM8880 chips tty: vt8500_serial: add missing support for RTS setting tty: vt8500_serial: explicitly calculate base baud rate tty: vt8500_serial: add polled console functions .../devicetree/bindings/serial/via,vt8500-uart.txt | 17 --- .../devicetree/bindings/serial/vt8500-uart.txt | 3 +- drivers/tty/serial/vt8500_serial.c | 136 ++--- 3 files changed, 118 insertions(+), 38 deletions(-) delete mode 100644 Documentation/devicetree/bindings/serial/via,vt8500-uart.txt -- 2.0.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: [RFC PATCH 3/9] irq_work: Force raised irq work to run on irq work interrupt
On Sat, Sep 06, 2014 at 05:45:56PM +0200, Peter Zijlstra wrote:
> On Sat, Sep 06, 2014 at 03:35:15PM +0200, Frederic Weisbecker wrote:
> > You have a script that does that arch/*/include/asm/Kbuild edit for you
> > right?
> > Is this something in scripts/ ?
>
> See commit b119fa61d440 ("locking/mcs: Order the header files in Kbuild
> of each architecture in alphabetical order")
>
> That script is a little buggy, but should work in the current case. So
> first do something like:
>
> for i in arch/*/include/asm/Kbuild; do
> echo "generic-y += foo.h" >> $i;
> done
>
> Then run that script.
>
> IIRC the bug was where a single line contained multiple headers and/or a
> continuation. I should have a better version somewhere, but this one was
> easier to find.
I see. Meanwhile I've applied your suggestion as a separate patch in
the series. May I use your SOB?
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] Add support for always enabled watchdog timers
On 08/23/2014 09:33 PM, Guenter Roeck wrote: On 08/23/2014 10:25 AM, Alexander Shiyan wrote: Sat, 23 Aug 2014 10:16:08 -0700 от Guenter Roeck : On 08/16/2014 05:45 PM, Evgeny Boger wrote: From: Evgeny Boger Add option to use with watchdog timers which are always enabled in hardware, i.e. there is no way to enable/disable it via GPIO pin. The driver will start pinging WDT immediately upon loading and will continue to do so even after stopping the watchdog. The headline needs a reference to the affected driver. Also, please copy the dt mailing list and maintainers. Signed-off-by: Evgeny Boger --- .../devicetree/bindings/watchdog/gpio-wdt.txt | 14 ++- drivers/watchdog/gpio_wdt.c| 45 +- 2 files changed, 48 insertions(+), 11 deletions(-) diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt index 37afec1..1f8ca46 100644 --- a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt @@ -12,8 +12,11 @@ Required Properties: the opposite level disables the WDT. Active level is determined by the GPIO flags. - hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds). +- always-enabled: Use with wathdog timer which is always enabled Similar to NOWAYOUT? I think this one is different. NOWAYOUT is a software flag, while the flag here is supposed to mean that the hardware watchdog is always enabled and running, and can not be disabled. Or at least this is my understanding. exactly Guenter -- С уважением, Евгений Богер ООО Бесконтактные устройства http://contactless.ru +7 (919) 965 88 36 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] Add support for always enabled watchdog timers to gpio_wdt driver
From: Evgeny Boger
Add option to use with watchdog timers which are always enabled
in hardware, i.e. there is no way to enable/disable it via GPIO pin.
The driver will start pinging WDT immediately upon loading
and will continue to do so even after stopping the watchdog.
Signed-off-by: Evgeny Boger
---
Changes since v1:
* fixed typos and indentation
* gpio_wdt_start_timer renamed to gpio_wdt_start_hwping.
This function actually starts the timer to ping hardware.
I personally find both proposed gpio_wdt_enable and __gpio_wdt_start
names discouraging in this context.
* fixed broken error handling for register_reboot_notifier
.../devicetree/bindings/watchdog/gpio-wdt.txt | 14 ++-
drivers/watchdog/gpio_wdt.c| 46 +-
2 files changed, 50 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
index 37afec1..047fe3f 100644
--- a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
@@ -12,8 +12,11 @@ Required Properties:
the opposite level disables the WDT. Active level is determined
by the GPIO flags.
- hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds).
+- always-enabled: Use with watchdog timer which is always enabled
+ in hardware, i.e. there is no way to enable/disable it via GPIO pin.
+ Driver will start pinging WDT immediately upon loading.
-Example:
+Examples:
watchdog: watchdog {
/* ADM706 */
compatible = "linux,wdt-gpio";
@@ -21,3 +24,12 @@ Example:
hw_algo = "toggle";
hw_margin_ms = <1600>;
};
+
+ watchdog: watchdog {
+ /* TPS3813 */
+ compatible = "linux,wdt-gpio";
+ gpios = < 9 GPIO_ACTIVE_LOW>;
+ hw_algo = "toggle";
+ hw_margin_ms = <1>;
+ always-enabled;
+ };
diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index 220a9e0..b6ab6e7 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -37,6 +37,8 @@ struct gpio_wdt_priv {
struct notifier_block notifier;
struct timer_list timer;
struct watchdog_device wdd;
+ boolalways_enabled;
+ boolstarted;
};
static void gpio_wdt_disable(struct gpio_wdt_priv *priv)
@@ -48,10 +50,8 @@ static void gpio_wdt_disable(struct gpio_wdt_priv *priv)
gpio_direction_input(priv->gpio);
}
-static int gpio_wdt_start(struct watchdog_device *wdd)
+static int gpio_wdt_start_hwping(struct gpio_wdt_priv *priv)
{
- struct gpio_wdt_priv *priv = watchdog_get_drvdata(wdd);
-
priv->state = priv->active_low;
gpio_direction_output(priv->gpio, priv->state);
priv->last_jiffies = jiffies;
@@ -60,12 +60,30 @@ static int gpio_wdt_start(struct watchdog_device *wdd)
return 0;
}
+static int gpio_wdt_start(struct watchdog_device *wdd)
+{
+ struct gpio_wdt_priv *priv = watchdog_get_drvdata(wdd);
+
+ priv->started = true;
+ if (priv->always_enabled) {
+ /* hardware ping timer is already enabled */
+ priv->last_jiffies = jiffies;
+ } else {
+ gpio_wdt_start_hwping(priv);
+ }
+
+ return 0;
+}
+
static int gpio_wdt_stop(struct watchdog_device *wdd)
{
struct gpio_wdt_priv *priv = watchdog_get_drvdata(wdd);
- mod_timer(>timer, 0);
- gpio_wdt_disable(priv);
+ priv->started = false;
+ if (!priv->always_enabled) {
+ mod_timer(>timer, 0);
+ gpio_wdt_disable(priv);
+ }
return 0;
}
@@ -91,8 +109,9 @@ static void gpio_wdt_hwping(unsigned long data)
struct watchdog_device *wdd = (struct watchdog_device *)data;
struct gpio_wdt_priv *priv = watchdog_get_drvdata(wdd);
- if (time_after(jiffies, priv->last_jiffies +
- msecs_to_jiffies(wdd->timeout * 1000))) {
+ if (priv->started &&
+ time_after(jiffies, priv->last_jiffies +
+ msecs_to_jiffies(wdd->timeout * 1000))) {
dev_crit(wdd->dev, "Timer expired. System will reboot soon!\n");
return;
}
@@ -197,6 +216,9 @@ static int gpio_wdt_probe(struct platform_device *pdev)
/* Use safe value (1/2 of real timeout) */
priv->hw_margin = msecs_to_jiffies(hw_margin / 2);
+ priv->always_enabled = of_property_read_bool(pdev->dev.of_node,
+ "always-enabled");
+
watchdog_set_drvdata(>wdd, priv);
priv->wdd.info = _wdt_ident;
@@ -207,6 +229,7 @@ static int gpio_wdt_probe(struct platform_device *pdev)
if (watchdog_init_timeout(>wdd, 0, >dev) < 0)
priv->wdd.timeout =
Re: linux-next: Tree for Sep 5: build failure due to 'mm: introduce dump_vma'
On 09/06/2014 08:47 AM, Sasha Levin wrote: On 09/06/2014 11:43 AM, Guenter Roeck wrote: I see the following build failure in next-20140905. Guenter Hey Guenter, Apologies for that. There is already a fix in -mm: No worries. http://ozlabs.org/~akpm/mmots/broken-out/introduce-dump_vma-fix-2.patch So -next would be fixed once -mm is pulled in again. Great! 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/
[PATCH 1/4] pinctrl: imx: detect uninitialized pins
The pinctrl driver initialized the register offsets for the pins
with 0. On Vybrid an offset of 0 is a valid offset for the pinctrl
mux register. So far, this was solved using the ZERO_OFFSET_VALID
flag which allowed offsets of 0. However, this does not allow to
verify whether a pins struct imx_pmx_func was initialized or not.
Use signed offset values for register offsets and initialize those
with -1 in order to detect uninitialized offset values reliable.
Signed-off-by: Stefan Agner
---
drivers/pinctrl/pinctrl-imx.c | 9 +
drivers/pinctrl/pinctrl-imx.h | 7 +++
drivers/pinctrl/pinctrl-vf610.c | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
index 946d594..0d4558b 100644
--- a/drivers/pinctrl/pinctrl-imx.c
+++ b/drivers/pinctrl/pinctrl-imx.c
@@ -204,7 +204,7 @@ static int imx_pmx_enable(struct pinctrl_dev *pctldev,
unsigned selector,
pin_id = pin->pin;
pin_reg = >pin_regs[pin_id];
- if (!(info->flags & ZERO_OFFSET_VALID) && !pin_reg->mux_reg) {
+ if (pin_reg->mux_reg == -1) {
dev_err(ipctl->dev, "Pin(%s) does not support mux
function\n",
info->pins[pin_id].name);
return -EINVAL;
@@ -308,7 +308,7 @@ static int imx_pinconf_get(struct pinctrl_dev *pctldev,
const struct imx_pinctrl_soc_info *info = ipctl->info;
const struct imx_pin_reg *pin_reg = >pin_regs[pin_id];
- if (!(info->flags & ZERO_OFFSET_VALID) && !pin_reg->conf_reg) {
+ if (pin_reg->conf_reg == -1) {
dev_err(info->dev, "Pin(%s) does not support config function\n",
info->pins[pin_id].name);
return -EINVAL;
@@ -331,7 +331,7 @@ static int imx_pinconf_set(struct pinctrl_dev *pctldev,
const struct imx_pin_reg *pin_reg = >pin_regs[pin_id];
int i;
- if (!(info->flags & ZERO_OFFSET_VALID) && !pin_reg->conf_reg) {
+ if (pin_reg->conf_reg == -1) {
dev_err(info->dev, "Pin(%s) does not support config function\n",
info->pins[pin_id].name);
return -EINVAL;
@@ -586,10 +586,11 @@ int imx_pinctrl_probe(struct platform_device *pdev,
if (!ipctl)
return -ENOMEM;
- info->pin_regs = devm_kzalloc(>dev, sizeof(*info->pin_regs) *
+ info->pin_regs = devm_kmalloc(>dev, sizeof(*info->pin_regs) *
info->npins, GFP_KERNEL);
if (!info->pin_regs)
return -ENOMEM;
+ memset(info->pin_regs, 0xff, sizeof(*info->pin_regs) * info->npins);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
ipctl->base = devm_ioremap_resource(>dev, res);
diff --git a/drivers/pinctrl/pinctrl-imx.h b/drivers/pinctrl/pinctrl-imx.h
index db408b0..49e55d3 100644
--- a/drivers/pinctrl/pinctrl-imx.h
+++ b/drivers/pinctrl/pinctrl-imx.h
@@ -67,8 +67,8 @@ struct imx_pmx_func {
* @conf_reg: config register offset
*/
struct imx_pin_reg {
- u16 mux_reg;
- u16 conf_reg;
+ s16 mux_reg;
+ s16 conf_reg;
};
struct imx_pinctrl_soc_info {
@@ -83,8 +83,7 @@ struct imx_pinctrl_soc_info {
unsigned int flags;
};
-#define ZERO_OFFSET_VALID 0x1
-#define SHARE_MUX_CONF_REG 0x2
+#define SHARE_MUX_CONF_REG 0x1
#define NO_MUX 0x0
#define NO_PAD 0x0
diff --git a/drivers/pinctrl/pinctrl-vf610.c b/drivers/pinctrl/pinctrl-vf610.c
index bddd913..b788e15 100644
--- a/drivers/pinctrl/pinctrl-vf610.c
+++ b/drivers/pinctrl/pinctrl-vf610.c
@@ -299,7 +299,7 @@ static const struct pinctrl_pin_desc vf610_pinctrl_pads[] =
{
static struct imx_pinctrl_soc_info vf610_pinctrl_info = {
.pins = vf610_pinctrl_pads,
.npins = ARRAY_SIZE(vf610_pinctrl_pads),
- .flags = ZERO_OFFSET_VALID | SHARE_MUX_CONF_REG,
+ .flags = SHARE_MUX_CONF_REG,
};
static struct of_device_id vf610_pinctrl_of_match[] = {
--
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/4] pinctrl: imx: add gpio pinmux support for vf610
Add pinmux support for GPIO for Vybrid (vf610) IOMUX controller.
This is needed since direction configuration is not part of the
GPIO module in Vybrid.
Signed-off-by: Stefan Agner
---
drivers/pinctrl/pinctrl-imx.c | 54 +
drivers/pinctrl/pinctrl-imx.h | 1 +
drivers/pinctrl/pinctrl-vf610.c | 4 +--
3 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/pinctrl/pinctrl-imx.c b/drivers/pinctrl/pinctrl-imx.c
index 0d4558b..64d1b59 100644
--- a/drivers/pinctrl/pinctrl-imx.c
+++ b/drivers/pinctrl/pinctrl-imx.c
@@ -294,10 +294,59 @@ static int imx_pmx_get_groups(struct pinctrl_dev
*pctldev, unsigned selector,
return 0;
}
+static int imx_pmx_gpio_request_enable(struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range, unsigned offset)
+{
+ struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+ const struct imx_pinctrl_soc_info *info = ipctl->info;
+ const struct imx_pin_reg *pin_reg;
+ u32 reg;
+
+ if (!(info->flags & GPIO_CONTROL))
+ return -EINVAL;
+
+ pin_reg = >pin_regs[offset];
+ if (pin_reg->mux_reg == -1)
+ return -EINVAL;
+
+ reg = readl(ipctl->base + pin_reg->mux_reg);
+ reg &= ~(0x7 << 20);
+ writel(reg, ipctl->base + pin_reg->mux_reg);
+
+ return 0;
+}
+
+static int imx_pmx_gpio_set_direction(struct pinctrl_dev *pctldev,
+ struct pinctrl_gpio_range *range, unsigned offset, bool input)
+{
+ struct imx_pinctrl *ipctl = pinctrl_dev_get_drvdata(pctldev);
+ const struct imx_pinctrl_soc_info *info = ipctl->info;
+ const struct imx_pin_reg *pin_reg;
+ u32 reg;
+
+ if (!(info->flags & GPIO_CONTROL))
+ return -EINVAL;
+
+ pin_reg = >pin_regs[offset];
+ if (pin_reg->mux_reg == -1)
+ return -EINVAL;
+
+ reg = readl(ipctl->base + pin_reg->mux_reg);
+ if (input)
+ reg &= ~0x2;
+ else
+ reg |= 0x2;
+ writel(reg, ipctl->base + pin_reg->mux_reg);
+
+ return 0;
+}
+
static const struct pinmux_ops imx_pmx_ops = {
.get_functions_count = imx_pmx_get_funcs_count,
.get_function_name = imx_pmx_get_func_name,
.get_function_groups = imx_pmx_get_groups,
+ .gpio_request_enable = imx_pmx_gpio_request_enable,
+ .gpio_set_direction = imx_pmx_gpio_set_direction,
.enable = imx_pmx_enable,
};
@@ -579,6 +628,11 @@ int imx_pinctrl_probe(struct platform_device *pdev,
dev_err(>dev, "wrong pinctrl info\n");
return -EINVAL;
}
+
+ /* GPIO control functions only intended for shared mux/conf register */
+ if (info->flags & GPIO_CONTROL)
+ BUG_ON(!(info->flags & SHARE_MUX_CONF_REG));
+
info->dev = >dev;
/* Create state holders etc for this driver */
diff --git a/drivers/pinctrl/pinctrl-imx.h b/drivers/pinctrl/pinctrl-imx.h
index 49e55d3..8f37ca4 100644
--- a/drivers/pinctrl/pinctrl-imx.h
+++ b/drivers/pinctrl/pinctrl-imx.h
@@ -84,6 +84,7 @@ struct imx_pinctrl_soc_info {
};
#define SHARE_MUX_CONF_REG 0x1
+#define GPIO_CONTROL 0x2
#define NO_MUX 0x0
#define NO_PAD 0x0
diff --git a/drivers/pinctrl/pinctrl-vf610.c b/drivers/pinctrl/pinctrl-vf610.c
index b788e15..d34a3ac 100644
--- a/drivers/pinctrl/pinctrl-vf610.c
+++ b/drivers/pinctrl/pinctrl-vf610.c
@@ -299,7 +299,7 @@ static const struct pinctrl_pin_desc vf610_pinctrl_pads[] =
{
static struct imx_pinctrl_soc_info vf610_pinctrl_info = {
.pins = vf610_pinctrl_pads,
.npins = ARRAY_SIZE(vf610_pinctrl_pads),
- .flags = SHARE_MUX_CONF_REG,
+ .flags = SHARE_MUX_CONF_REG | GPIO_CONTROL,
};
static struct of_device_id vf610_pinctrl_of_match[] = {
@@ -326,7 +326,7 @@ static int __init vf610_pinctrl_init(void)
{
return platform_driver_register(_pinctrl_driver);
}
-arch_initcall(vf610_pinctrl_init);
+postcore_initcall(vf610_pinctrl_init);
static void __exit vf610_pinctrl_exit(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/
[PATCH 3/4] gpio: vf610: add gpiolib/IRQ chip driver for Vybird
Add a gpiolib and IRQ chip driver for Vybrid ARM SoC using the
Vybrid's GPIO and PORT module. The driver is instanced once per
each GPIO/PORT module pair and handles 32 GPIO's.
Signed-off-by: Stefan Agner
---
drivers/gpio/Kconfig | 7 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-vf610.c | 285 ++
3 files changed, 293 insertions(+)
create mode 100644 drivers/gpio/gpio-vf610.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 9de1515..82b38f5 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -334,6 +334,13 @@ config GPIO_TZ1090_PDC
help
Say yes here to support Toumaz Xenif TZ1090 PDC GPIOs.
+config GPIO_VF610
+ def_bool y
+ depends on ARCH_MXC && SOC_VF610
+ select GPIOLIB_IRQCHIP
+ help
+ Say yes here to support Vybrid vf610 GPIOs.
+
config GPIO_XILINX
bool "Xilinx GPIO support"
depends on PPC_OF || MICROBLAZE || ARCH_ZYNQ
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 5d024e3..9893d4c 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -95,6 +95,7 @@ obj-$(CONFIG_GPIO_TWL6040)+= gpio-twl6040.o
obj-$(CONFIG_GPIO_TZ1090) += gpio-tz1090.o
obj-$(CONFIG_GPIO_TZ1090_PDC) += gpio-tz1090-pdc.o
obj-$(CONFIG_GPIO_UCB1400) += gpio-ucb1400.o
+obj-$(CONFIG_GPIO_VF610) += gpio-vf610.o
obj-$(CONFIG_GPIO_VIPERBOARD) += gpio-viperboard.o
obj-$(CONFIG_GPIO_VR41XX) += gpio-vr41xx.o
obj-$(CONFIG_GPIO_VX855) += gpio-vx855.o
diff --git a/drivers/gpio/gpio-vf610.c b/drivers/gpio/gpio-vf610.c
new file mode 100644
index 000..5f59424
--- /dev/null
+++ b/drivers/gpio/gpio-vf610.c
@@ -0,0 +1,285 @@
+/*
+ * vf610 GPIO support through PORT and GPIO module
+ *
+ * Copyright (c) 2014 Toradex AG.
+ *
+ * Author: Stefan Agner .
+ *
+ * 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.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+
+#define GPIO_PER_PORT 32
+
+struct vf610_gpio_port {
+ struct gpio_chip gc;
+ void __iomem *base;
+ void __iomem *gpio_base;
+ u8 irqc[GPIO_PER_PORT];
+ int irq;
+};
+
+#define GPIO_PDOR 0x00
+#define GPIO_PSOR 0x04
+#define GPIO_PCOR 0x08
+#define GPIO_PTOR 0x0c
+#define GPIO_PDIR 0x10
+
+#define PORT_PCR(n)(n * 0x4)
+#define PORT_PCR_IRQC_OFFSET 16
+
+#define PORT_ISFR 0xa0
+#define PORT_DFER 0xc0
+#define PORT_DFCR 0xc4
+#define PORT_DFWR 0xc8
+
+#define PORT_INT_OFF 0x0
+#define PORT_INT_LOGIC_ZERO0x8
+#define PORT_INT_RISING_EDGE 0x9
+#define PORT_INT_FALLING_EDGE 0xa
+#define PORT_INT_EITHER_EDGE 0xb
+#define PORT_INT_LOGIC_ONE 0xc
+
+
+static const struct of_device_id vf610_gpio_dt_ids[] = {
+ { .compatible = "fsl,vf610-gpio" },
+ { /* sentinel */ }
+};
+
+static inline void vf610_gpio_writel(u32 val, void __iomem *reg)
+{
+ __raw_writel(val, reg);
+}
+
+static inline u32 vf610_gpio_readl(void __iomem *reg)
+{
+ return __raw_readl(reg);
+}
+
+static int vf610_gpio_request(struct gpio_chip *chip, unsigned offset)
+{
+ return pinctrl_request_gpio(chip->base + offset);
+}
+
+static void vf610_gpio_free(struct gpio_chip *chip, unsigned offset)
+{
+ pinctrl_free_gpio(chip->base + offset);
+}
+
+static int vf610_gpio_get(struct gpio_chip *gc, unsigned int gpio)
+{
+ struct vf610_gpio_port *port =
+ container_of(gc, struct vf610_gpio_port, gc);
+
+ return !!(vf610_gpio_readl(port->gpio_base + GPIO_PDIR) & 1 << gpio);
+}
+
+static void vf610_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
+{
+ struct vf610_gpio_port *port =
+ container_of(gc, struct vf610_gpio_port, gc);
+ unsigned long mask = 1 << gpio;
+
+ if (val)
+ vf610_gpio_writel(mask, port->gpio_base + GPIO_PSOR);
+ else
+ vf610_gpio_writel(mask, port->gpio_base + GPIO_PCOR);
+}
+
+static int vf610_gpio_direction_input(struct gpio_chip *chip, unsigned gpio)
+{
+ return pinctrl_gpio_direction_input(chip->base + gpio);
+}
+
+static int vf610_gpio_direction_output(struct gpio_chip *chip, unsigned gpio,
+ int value)
+{
+ vf610_gpio_set(chip, gpio, value);
+
+ return
[PATCH 4/4] ARM: dts: vf610: Use new GPIO support
Use GPIO support by adding SD card detection configuration and
GPIO pinmux for Colibri's standard GPIO pins.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf610-colibri.dtsi | 8
arch/arm/boot/dts/vf610-twr.dts | 1 +
arch/arm/boot/dts/vf610.dtsi | 1 +
3 files changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/vf610-colibri.dtsi
b/arch/arm/boot/dts/vf610-colibri.dtsi
index 0cd8343..afe7cdc 100644
--- a/arch/arm/boot/dts/vf610-colibri.dtsi
+++ b/arch/arm/boot/dts/vf610-colibri.dtsi
@@ -31,6 +31,7 @@
pinctrl-names = "default";
pinctrl-0 = <_esdhc1>;
bus-width = <4>;
+ cd-gpios = < 10 GPIO_ACTIVE_LOW>;
};
{
@@ -71,6 +72,13 @@
{
vf610-colibri {
+ pinctrl_gpio: gpios {
+ fsl,pins = <
+ VF610_PAD_PTD9__GPIO_88 0x219d
+ VF610_PAD_PTD10__GPIO_890x219d
+ >;
+ };
+
pinctrl_esdhc1: esdhc1grp {
fsl,pins = <
VF610_PAD_PTA24__ESDHC1_CLK 0x31ef
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index 189b697..3fe8a8f 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -116,6 +116,7 @@
pinctrl-names = "default";
pinctrl-0 = <_esdhc1>;
bus-width = <4>;
+ cd-gpios = < 6 GPIO_ACTIVE_LOW>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/vf610.dtsi b/arch/arm/boot/dts/vf610.dtsi
index 4d2ec32..467c97e 100644
--- a/arch/arm/boot/dts/vf610.dtsi
+++ b/arch/arm/boot/dts/vf610.dtsi
@@ -11,6 +11,7 @@
#include "vf610-pinfunc.h"
#include
#include
+#include
/ {
aliases {
--
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 0/4] vf610: Add GPIO support
This patchset adds GPIO support for Vybrid. The first patch is a preparation patch which makes sure we can detect whether a pin is initialized by the pinmux subsystem or not. This is required since the gpio_request_enable/gpio_set_direction function need to know if the pins mux register offsets are valid or not. To get valid mux register offset for a pin, we need to have a pinmux group configuration in the device tree. For the SD card detection pin this is within the esdhc pingroup. Since the pingroup is used by the driver, the mux and configuration register gets applied by the pinmux subsystem. However, the group does not need to be used anywhere, just the configuration itself makes sure the mux register offset is known to the pinmux driver. If a GPIO is requested then, the SoC's default pin config is still in place. Is this the expected behaviour of a pinmux driver? How can I make sure that a GPIO only pin (used by user-space for instance) get a valid pin configuration applied? To get the mux register offset, I also thought about calculating the value in those two functions instead, however this seems not to be consistent with the rest of the driver. Other then that, the GPIO/IRQ chip driver is quite straight forward and makes use of CONFIG_GPIOLIB_IRQCHIP. The only thing which is a bit weird: There is no actual mask register for the GPIO interrupts. There is only a configuration register, which, if configured, enables the interrupt. Since the mask/unmask functions are requierd, the driver writes/clears the configuration register in the mask/umask functions. Stefan Agner (4): pinctrl: imx: detect uninitialized pins pinctrl: imx: add gpio pinmux support for vf610 gpio: vf610: add gpiolib/IRQ chip driver for Vybird ARM: dts: vf610: Use new GPIO support arch/arm/boot/dts/vf610-colibri.dtsi | 8 + arch/arm/boot/dts/vf610-twr.dts | 1 + arch/arm/boot/dts/vf610.dtsi | 1 + drivers/gpio/Kconfig | 7 + drivers/gpio/Makefile| 1 + drivers/gpio/gpio-vf610.c| 285 +++ drivers/pinctrl/pinctrl-imx.c| 63 +++- drivers/pinctrl/pinctrl-imx.h| 8 +- drivers/pinctrl/pinctrl-vf610.c | 4 +- 9 files changed, 368 insertions(+), 10 deletions(-) create mode 100644 drivers/gpio/gpio-vf610.c -- 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 v10 net-next 2/2] net: filter: split filter.h and expose eBPF to user space
On Sat, Sep 6, 2014 at 7:10 AM, Pablo Neira Ayuso wrote: > On Thu, Sep 04, 2014 at 10:17:18PM -0700, Alexei Starovoitov wrote: >> allow user space to generate eBPF programs >> >> uapi/linux/bpf.h: eBPF instruction set definition >> >> linux/filter.h: the rest >> >> This patch only moves macro definitions, but practically it freezes existing >> eBPF instruction set, though new instructions can still be added in the >> future. >> >> These eBPF definitions cannot go into uapi/linux/filter.h, since the names >> may conflict with existing applications. >> >> Full eBPF ISA description is in Documentation/networking/filter.txt > > I think you need to have at least one single interface using this > before you can expose it to userspace. So this should come in the > small batch that introduces the first interface of your ebpf code in > userspace. AFAIK, this has been the policy so far. That's what I've been doing over the last year. My first eBPF patch was in Sep of 2013! since then I've been only tweaking and massaging it. Nothing fundamentally changed. Last few month I've been posting these series with not only first user, but with multiple. Many examples, test cases and so on. The series became big and Dave asked to split them. Please see the cover letter. These two patches is stage I. More examples and use cases in stage II, stage III, stage IV, etc All these patches are ready. I'm only submitting them one at a time to make review easier. Please see them in my tree if you interested. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Sep 5: build failure due to 'mm: introduce dump_vma'
On 09/06/2014 11:43 AM, Guenter Roeck wrote: > I see the following build failure in next-20140905. > > Guenter Hey Guenter, Apologies for that. There is already a fix in -mm: http://ozlabs.org/~akpm/mmots/broken-out/introduce-dump_vma-fix-2.patch So -next would be fixed once -mm is pulled in again. 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: linux-next: Tree for Sep 5: build failure due to 'mm: introduce dump_vma'
On Sat, Sep 06, 2014 at 08:43:09AM -0700, Guenter Roeck wrote: > I see the following build failure in next-20140905. > > Guenter > > --- > > Building tile:tilegx_defconfig ... failed Also: Building powerpc:allmodconfig ... failed Building powerpc:ppc6xx_defconfig ... failed with the same error. > -- > Error log: > mm/page_alloc.c: In function 'dump_vma': > mm/page_alloc.c:6742:46: error: 'pgprot_t' has no member named 'pgprot' > make[1]: *** [mm/page_alloc.o] Error 1 > make[1]: *** Waiting for unfinished jobs > make: *** [mm] Error 2 > make: *** Waiting for unfinished jobs > -- > > bisect results: > > d1305f0fa17f1d3e659a8aa2134610a1a6884f77 is the first bad commit > commit d1305f0fa17f1d3e659a8aa2134610a1a6884f77 > Author: Sasha Levin > Date: Fri Sep 5 16:58:49 2014 +0100 > > mm: introduce dump_vma > > Introduce a helper to dump information about a VMA, this also makes > dump_page_flags more generic and re-uses that so the output looks very > similar to dump_page: > > [ 61.903437] vma 88070f88be00 start 7fff2597 end > 7fff25992000 > [ 61.903437] next 88070facd600 prev 88070face400 mm > 88070fade000 > [ 61.903437] prot 8025 anon_vma 88070fa1e200 vm_ops > (null) > [ 61.903437] pgoff 7ffdd file (null) private_data > (null) > [ 61.909129] flags: > 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account) > > Signed-off-by: Sasha Levin > Reviewed-by: Naoya Horiguchi > Cc: Kirill A. Shutemov > Cc: Konstantin Khlebnikov > Cc: Rik van Riel > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Hugh Dickins > Cc: Vlastimil Babka > Cc: Michel Lespinasse > Cc: Minchan Kim > Signed-off-by: Andrew Morton > > > --- > bisect log: > > # bad: [92d88cb068a5dc66d53ef017999b2419b125f764] Add linux-next specific > files for 20140905 > # good: [69e273c0b0a3c337a521d083374c918dc52c666f] Linux 3.17-rc3 > git bisect start 'HEAD' 'v3.17-rc3' > # good: [9ecc6d43871f92e01c8aafa9563538ed92825778] Merge remote-tracking > branch 'drm/drm-next' > git bisect good 9ecc6d43871f92e01c8aafa9563538ed92825778 > # good: [578445255f94602a32d2a05f38c983319e2e2c0c] Merge remote-tracking > branch 'usb-gadget/next' > git bisect good 578445255f94602a32d2a05f38c983319e2e2c0c > # good: [db1afd18e9cddffd957abea6287a6eae9edbeccc] staging: vt6655: replace > typedef struct tagSCTS_FB with struct vnt_cts_fb > git bisect good db1afd18e9cddffd957abea6287a6eae9edbeccc > # good: [4b3423832f2d1cbb988b18c96d39474029a6156b] Merge remote-tracking > branch 'llvmlinux/for-next' > git bisect good 4b3423832f2d1cbb988b18c96d39474029a6156b > # bad: [d1305f0fa17f1d3e659a8aa2134610a1a6884f77] mm: introduce dump_vma > git bisect bad d1305f0fa17f1d3e659a8aa2134610a1a6884f77 > # good: [1eb2bc2558fecb3eb78114dbcc433d0e2e390372] mm/slab: move > cache_flusharray() out of unlikely.text section > git bisect good 1eb2bc2558fecb3eb78114dbcc433d0e2e390372 > # good: [1d414c4d9f077af5dd20135f135a498176b564a5] mm, compaction: skip buddy > pages by their order in the migrate scanner > git bisect good 1d414c4d9f077af5dd20135f135a498176b564a5 > # good: [05e2a5f419c0c5888bce1aeda4ffe89f7657e0a6] mempolicy: fix > show_numa_map() vs exec() + do_set_mempolicy() race > git bisect good 05e2a5f419c0c5888bce1aeda4ffe89f7657e0a6 > # good: [41da4bf4788f47cb1f0801562e378e549c7b350a] > selftests/vm/transhuge-stress: stress test for memory compaction > git bisect good 41da4bf4788f47cb1f0801562e378e549c7b350a > # good: [6dd0fc5ec52ec2a0ae3a1c4e6816434c18052420] mm/balloon_compaction: > general cleanup > git bisect good 6dd0fc5ec52ec2a0ae3a1c4e6816434c18052420 > # good: [ada687f364aa0ffaebe5a66bd0b89af97e53a587] > mm-balloon_compaction-general-cleanup-checkpatch-fixes > git bisect good ada687f364aa0ffaebe5a66bd0b89af97e53a587 > # good: [834259904e3b9a9fd6409b9a38aa608158467822] mm/slab.c: use > __seq_open_private() instead of seq_open() > git bisect good 834259904e3b9a9fd6409b9a38aa608158467822 > # first bad commit: [d1305f0fa17f1d3e659a8aa2134610a1a6884f77] mm: introduce > dump_vma -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 3/9] irq_work: Force raised irq work to run on irq work interrupt
On Sat, Sep 06, 2014 at 03:35:15PM +0200, Frederic Weisbecker wrote:
> You have a script that does that arch/*/include/asm/Kbuild edit for you right?
> Is this something in scripts/ ?
See commit b119fa61d440 ("locking/mcs: Order the header files in Kbuild
of each architecture in alphabetical order")
That script is a little buggy, but should work in the current case. So
first do something like:
for i in arch/*/include/asm/Kbuild; do
echo "generic-y += foo.h" >> $i;
done
Then run that script.
IIRC the bug was where a single line contained multiple headers and/or a
continuation. I should have a better version somewhere, but this one was
easier to find.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Sep 5: build failure due to 'mm: introduce dump_vma'
I see the following build failure in next-20140905. Guenter --- Building tile:tilegx_defconfig ... failed -- Error log: mm/page_alloc.c: In function 'dump_vma': mm/page_alloc.c:6742:46: error: 'pgprot_t' has no member named 'pgprot' make[1]: *** [mm/page_alloc.o] Error 1 make[1]: *** Waiting for unfinished jobs make: *** [mm] Error 2 make: *** Waiting for unfinished jobs -- bisect results: d1305f0fa17f1d3e659a8aa2134610a1a6884f77 is the first bad commit commit d1305f0fa17f1d3e659a8aa2134610a1a6884f77 Author: Sasha Levin Date: Fri Sep 5 16:58:49 2014 +0100 mm: introduce dump_vma Introduce a helper to dump information about a VMA, this also makes dump_page_flags more generic and re-uses that so the output looks very similar to dump_page: [ 61.903437] vma 88070f88be00 start 7fff2597 end 7fff25992000 [ 61.903437] next 88070facd600 prev 88070face400 mm 88070fade000 [ 61.903437] prot 8025 anon_vma 88070fa1e200 vm_ops (null) [ 61.903437] pgoff 7ffdd file (null) private_data (null) [ 61.909129] flags: 0x100173(read|write|mayread|maywrite|mayexec|growsdown|account) Signed-off-by: Sasha Levin Reviewed-by: Naoya Horiguchi Cc: Kirill A. Shutemov Cc: Konstantin Khlebnikov Cc: Rik van Riel Cc: Mel Gorman Cc: Michal Hocko Cc: Hugh Dickins Cc: Vlastimil Babka Cc: Michel Lespinasse Cc: Minchan Kim Signed-off-by: Andrew Morton --- bisect log: # bad: [92d88cb068a5dc66d53ef017999b2419b125f764] Add linux-next specific files for 20140905 # good: [69e273c0b0a3c337a521d083374c918dc52c666f] Linux 3.17-rc3 git bisect start 'HEAD' 'v3.17-rc3' # good: [9ecc6d43871f92e01c8aafa9563538ed92825778] Merge remote-tracking branch 'drm/drm-next' git bisect good 9ecc6d43871f92e01c8aafa9563538ed92825778 # good: [578445255f94602a32d2a05f38c983319e2e2c0c] Merge remote-tracking branch 'usb-gadget/next' git bisect good 578445255f94602a32d2a05f38c983319e2e2c0c # good: [db1afd18e9cddffd957abea6287a6eae9edbeccc] staging: vt6655: replace typedef struct tagSCTS_FB with struct vnt_cts_fb git bisect good db1afd18e9cddffd957abea6287a6eae9edbeccc # good: [4b3423832f2d1cbb988b18c96d39474029a6156b] Merge remote-tracking branch 'llvmlinux/for-next' git bisect good 4b3423832f2d1cbb988b18c96d39474029a6156b # bad: [d1305f0fa17f1d3e659a8aa2134610a1a6884f77] mm: introduce dump_vma git bisect bad d1305f0fa17f1d3e659a8aa2134610a1a6884f77 # good: [1eb2bc2558fecb3eb78114dbcc433d0e2e390372] mm/slab: move cache_flusharray() out of unlikely.text section git bisect good 1eb2bc2558fecb3eb78114dbcc433d0e2e390372 # good: [1d414c4d9f077af5dd20135f135a498176b564a5] mm, compaction: skip buddy pages by their order in the migrate scanner git bisect good 1d414c4d9f077af5dd20135f135a498176b564a5 # good: [05e2a5f419c0c5888bce1aeda4ffe89f7657e0a6] mempolicy: fix show_numa_map() vs exec() + do_set_mempolicy() race git bisect good 05e2a5f419c0c5888bce1aeda4ffe89f7657e0a6 # good: [41da4bf4788f47cb1f0801562e378e549c7b350a] selftests/vm/transhuge-stress: stress test for memory compaction git bisect good 41da4bf4788f47cb1f0801562e378e549c7b350a # good: [6dd0fc5ec52ec2a0ae3a1c4e6816434c18052420] mm/balloon_compaction: general cleanup git bisect good 6dd0fc5ec52ec2a0ae3a1c4e6816434c18052420 # good: [ada687f364aa0ffaebe5a66bd0b89af97e53a587] mm-balloon_compaction-general-cleanup-checkpatch-fixes git bisect good ada687f364aa0ffaebe5a66bd0b89af97e53a587 # good: [834259904e3b9a9fd6409b9a38aa608158467822] mm/slab.c: use __seq_open_private() instead of seq_open() git bisect good 834259904e3b9a9fd6409b9a38aa608158467822 # first bad commit: [d1305f0fa17f1d3e659a8aa2134610a1a6884f77] mm: introduce dump_vma -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] x86/xen: Fix 64bit kernel pagetable setup of PV guests
On 02.09.2014 13:01, David Vrabel wrote: > On 01/09/14 18:34, David Vrabel wrote: >> On 29/08/14 16:17, Stefan Bader wrote: >>> >>> This change might not be the fully correct approach as it basically >>> removes the pre-set page table entry for the fixmap that is compile >>> time set (level2_fixmap_pgt[506]->level1_fixmap_pgt). For one the >>> level1 page table is not yet declared in C headers (that might be >>> fixed). But also with the current bug, it was removed, too. Since >>> the Xen mappings for level2_kernel_pgt only covered kernel + initrd >>> and some Xen data this did never reach that far. And still, something >>> does create entries at level2_fixmap_pgt[506..507]. So it should be >>> ok. At least I was able to successfully boot a kernel with 1G kernel >>> image size without any vmalloc whinings. >> [...] >>> --- a/arch/x86/xen/mmu.c >>> +++ b/arch/x86/xen/mmu.c >>> @@ -1902,8 +1902,22 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd, >>> unsigned long max_pfn) >>> /* L3_i[0] -> level2_ident_pgt */ >>> convert_pfn_mfn(level3_ident_pgt); >>> /* L3_k[510] -> level2_kernel_pgt >>> -* L3_i[511] -> level2_fixmap_pgt */ >>> +* L3_k[511] -> level2_fixmap_pgt */ >>> convert_pfn_mfn(level3_kernel_pgt); >>> + >>> + /* level2_fixmap_pgt contains a single entry for the >>> +* fixmap area at offset 506. The correct way would >>> +* be to convert level2_fixmap_pgt to mfn and set the >>> +* level1_fixmap_pgt (which is completely empty) to RO, >>> +* too. But currently this page table is not declared, >>> +* so it would be a bit of voodoo to get its address. >>> +* And also the fixmap entry was never set due to using >>> +* the wrong l2 when getting Xen's tables. So let's just >>> +* just nuke it. >>> +* This orphans level1_fixmap_pgt, but that was basically >>> +* done before the change as well. >>> +*/ >>> + memset(level2_fixmap_pgt, 0, 512*sizeof(long)); >> >> level2_fixmap_pgt etc. are defined for the benefit of Xen only so I >> think you should add an extern for level1_fixmap_pgt and fix this up >> properly. >> >> It might not matter now, but it might in the future... > > I found some time to look into this and test it. Including without > enabling KSLAR, but reproing the vmalloc failure with a large (800 MiB > module). > > I've clarified the change description, can you review my edits? > > Thanks for investigating and fixing this! Sorry for not having replied earlier (I am on vacation). Without testing it looks about what I had after a few iterations (minus the export of l1). So if you had a kernel booting with that I am happy, too. :) -Stefan > > David > > 8<-- > x86/xen: don't copy junk into kernel page tables > > When RANDOMIZE_BASE (KASLR) is enabled; or the sum of all loaded > modules exceeds 512 MiB, then loading modules fails with a warning > (and hence a vmalloc allocation failure) because the PTEs for the > newly-allocated vmalloc address space are not zero. > > WARNING: CPU: 0 PID: 494 at linux/mm/vmalloc.c:128 >vmap_page_range_noflush+0x2a1/0x360() > > This is caused by xen_setup_kernel_pagetables() copying junk into the > page tables (to level2_fixmap_pgt), overwriting many non-present > entries. > > Without KASLR, the normal kernel image size only covers the first half > of level2_kernel_pgt and module space starts after that. > > L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[ 0..255]->kernel > [256..511]->module > [511]->level2_fixmap_pgt[ 0..505]->module > > This allows 512 MiB of of module vmalloc space to be used before > having to use the corrupted level2_fixmap_pgt entries. > > With KASLR enabled, the kernel image uses the full PUD range of 1G and > module space starts in the level2_fixmap_pgt. So basically: > > L4[511]->level3_kernel_pgt[510]->level2_kernel_pgt[0..511]->kernel > [511]->level2_fixmap_pgt[0..505]->module > > And now no module vmalloc space can be used without using the corrupt > level2_fixmap_pgt entries. > > Fix this by properly converting the level2_fixmap_pgt entries to MFNs, > and setting level1_fixmap_pgt as read-only. > > Signed-off-by: Stefan Bader > Cc: sta...@vger.kernel.org > Signed-off-by: David Vrabel > --- > arch/x86/include/asm/pgtable_64.h |1 + > arch/x86/xen/mmu.c| 27 --- > 2 files changed, 13 insertions(+), 15 deletions(-) > > diff --git a/arch/x86/include/asm/pgtable_64.h > b/arch/x86/include/asm/pgtable_64.h > index 5be9063..3874693 100644 > --- a/arch/x86/include/asm/pgtable_64.h > +++ b/arch/x86/include/asm/pgtable_64.h > @@ -19,6 +19,7 @@ extern pud_t level3_ident_pgt[512]; > extern pmd_t
Re: [PATCH v4 1/4] thermal: rockchip: add driver for thermal
Hello Ceasar,
On Wed, Sep 03, 2014 at 10:10:36AM +0800, Caesar Wang wrote:
> Thermal is TS-ADC Controller module supports
> user-defined mode and automatic mode.
>
> User-defined mode refers,TSADC all the control signals entirely by
> software writing to register for direct control.
>
> Automaic mode refers to the module automatically poll TSADC output,
> and the results were checked.If you find that the temperature High
> in a period of time,an interrupt is generated to the processor
> down-measures taken;if the temperature over a period of time High,
> the resulting TSHUT gave CRU module,let it reset the entire chip,
> or via GPIO give PMIC.
>
> Signed-off-by: zhaoyifeng
> Signed-off-by: Caesar Wang
> ---
> drivers/thermal/Kconfig| 9 +
> drivers/thermal/Makefile | 1 +
> drivers/thermal/rockchip_thermal.c | 669
> +
> 3 files changed, 679 insertions(+)
> create mode 100644 drivers/thermal/rockchip_thermal.c
>
> diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
> index f9a1386..a00aa1e 100644
> --- a/drivers/thermal/Kconfig
> +++ b/drivers/thermal/Kconfig
> @@ -133,6 +133,15 @@ config SPEAR_THERMAL
> Enable this to plug the SPEAr thermal sensor driver into the Linux
> thermal framework.
>
> +config ROCKCHIP_THERMAL
> + tristate "Rockchip thermal driver"
> + depends on ARCH_ROCKCHIP
> + help
> + Support for Temperature Sensor ADC (TS-ADC) found on Rockchip SoCs.
> + It supports one critical trip point and one passive trip point. The
> + cpufreq is used as the cooling device to throttle CPUs when the
> + passive trip is crossed.
> +
> config RCAR_THERMAL
> tristate "Renesas R-Car thermal driver"
> depends on ARCH_SHMOBILE || COMPILE_TEST
> diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
> index de0636a..b48b817 100644
> --- a/drivers/thermal/Makefile
> +++ b/drivers/thermal/Makefile
> @@ -19,6 +19,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
>
> # platform thermal drivers
> obj-$(CONFIG_SPEAR_THERMAL) += spear_thermal.o
> +obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
> obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
> obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
> obj-y+= samsung/
> diff --git a/drivers/thermal/rockchip_thermal.c
> b/drivers/thermal/rockchip_thermal.c
> new file mode 100644
> index 000..011f387
> --- /dev/null
> +++ b/drivers/thermal/rockchip_thermal.c
> @@ -0,0 +1,669 @@
> +/*
> + * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * 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.
> + *
> +*/
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include "thermal_core.h"
Why do you need thermal_core.h here? Wouldn't linux/thermal.h be
sufficient?
> +
> +enum rockchip_thermal_trip {
> + ROCKCHIP_TRIP_PASSIVE,
> + ROCKCHIP_TRIP_CRITICAL,
> + ROCKCHIP_TRIP_NUM,
> +};
> +
Why do you need your own trip types?
> +struct rockchip_thermal_data {
> + const struct rockchip_tsadc_platform_data *pdata;
> + struct thermal_zone_device *tz;
> + struct thermal_cooling_device *cdev;
> + enum thermal_device_mode mode;
> + void __iomem *regs;
> +
> + signed long temp_passive;
> + signed long temp_critical;
> + signed long temp_force_shut;
> + signed long alarm_temp;
> + signed long last_temp;
> + bool irq_enabled;
> + int irq;
> + struct clk *clk;
> + struct clk *pclk;
> +};
> +
> +struct rockchip_tsadc_platform_data {
> + u8 irq_en;
> + signed long temp_passive;
> + signed long temp_critical;
> + signed long temp_force_shut;
> + int passive_delay;
> + int polling_delay;
> +
> + int (*irq_handle)(void __iomem *reg);
> + int (*initialize)(void __iomem *reg, signed long temp_force_shut);
> + int (*control)(void __iomem *reg, bool on);
> + u32 (*code_to_temp)(int temp);
> + u32 (*temp_to_code)(int temp);
> + void (*set_alarm_temp)(void __iomem *regs, signed long temp);
> +};
> +
> +/*TSADC V2 Sensor info define:*/
> +#define TSADCV2_AUTO_CON 0x04
> +#define TSADCV2_INT_EN 0x08
> +#define TSADCV2_INT_PD 0x0c
> +#define TSADCV2_DATA10x24
> +#define TSADCV2_COMP1_INT0x34
> +#define TSADCV2_COMP1_SHUT
Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
Am 05.09.2014 15:52, schrieb Pali Rohár: > On Friday 05 September 2014 15:45:42 Mark Rutland wrote: >> On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote: >>> On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote: Machine name from board description is some generic name on DT kernel. DT provides machine name property which is specific for board, so use it instead generic one when possible. Signed-off-by: Pali Rohár --- arch/arm/kernel/setup.c |7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644 --- a/arch/arm/kernel/setup.c +++ b/arch/arm/kernel/setup.c @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p) setup_processor(); mdesc = setup_machine_fdt(__atags_pointer); - if (!mdesc) + if (mdesc) + machine_name = of_flat_dt_get_machine_name(); + else mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type); machine_desc = mdesc; - machine_name = mdesc->name; + if (!machine_name) + machine_name = mdesc->name; if (mdesc->reboot_mode != REBOOT_HARD) reboot_mode = mdesc->reboot_mode; >>> >>> So, do you really want to break userspace which reading file >>> /proc/cpuinfo (after migration from boardcode --> DT)? >> >> You have no guarantee model name in the DT == the name in a >> board file anyhow, and trying to force that is wrong. So >> further to Russell's reply, I must NAK this from a DT >> perspective. >> >> Realistically your userspace is already broken if relying on >> such things. You built something that only ever worked for a >> particular arbitrary string. So it was already broken for >> every other board, and there was never any guarantee that new >> boards where your userspace could have worked would share the >> same name. >> >> You're trying to fix the wrong side of the equation. > > So what is your suggestion for identifing board (name/type) which > will work with any kernel (and will not be broken again by kernel > later)? /proc/device-tree/compatible should give you a nul-separated list of compatible strings for the machine. Ideally they're even documented under Documentation/devicetree/bindings/arm/. But as Mark said, depending on what you are actually trying to distinguish in userspace, there may be better ways. Regards, Andreas -- SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg signature.asc Description: OpenPGP digital signature
linux-next: Tree for Sep 5: build error due to 'ath5k: added debugfs file for dumping eeprom'
I see the following build error on linux-next-20140905. Guenter --- Building alpha:allmodconfig ... failed Building sparc64:allmodconfig ... failed drivers/net/wireless/ath/ath5k/debug.c: In function 'open_file_eeprom': drivers/net/wireless/ath/ath5k/debug.c:933:2: error: implicit declaration of function 'vmalloc' [-Werror=implicit-function-declaration] drivers/net/wireless/ath/ath5k/debug.c:933:6: warning: assignment makes pointer from integer without a cast [enabled by default] drivers/net/wireless/ath/ath5k/debug.c:960:2: error: implicit declaration of function 'vfree' [-Werror=implicit-function-declaration] cc1: some warnings being treated as errors make[5]: *** [drivers/net/wireless/ath/ath5k/debug.o] Error 1 make[4]: *** [drivers/net/wireless/ath/ath5k] Error 2 make[3]: *** [drivers/net/wireless/ath] Error 2 Bisect results: db906eb2101b0564b0c65edf4a8647395196342e is the first bad commit commit db906eb2101b0564b0c65edf4a8647395196342e Author: Jade Bilkey Date: Sat Aug 30 15:14:14 2014 -0400 ath5k: added debugfs file for dumping eeprom Signed-off-by: Jade Bilkey Signed-off-by: John W. Linville Bisect log: # bad: [92d88cb068a5dc66d53ef017999b2419b125f764] Add linux-next specific files for 20140905 # good: [69e273c0b0a3c337a521d083374c918dc52c666f] Linux 3.17-rc3 git bisect start 'HEAD' 'v3.17-rc3' # bad: [9ecc6d43871f92e01c8aafa9563538ed92825778] Merge remote-tracking branch 'drm/drm-next' git bisect bad 9ecc6d43871f92e01c8aafa9563538ed92825778 # good: [43b1c66453f3f04c5faa271c9918aa9764e04f98] Merge remote-tracking branch 'hwmon-staging/hwmon-next' git bisect good 43b1c66453f3f04c5faa271c9918aa9764e04f98 # good: [92bfbb73a8714144c5d74bf886b3b8b6b93a29dc] Merge remote-tracking branch 'ipsec-next/master' git bisect good 92bfbb73a8714144c5d74bf886b3b8b6b93a29dc # bad: [15f51956b321a1ddf683c2b151aa85e84fbc3c4d] Merge remote-tracking branch 'l2-mtd/master' git bisect bad 15f51956b321a1ddf683c2b151aa85e84fbc3c4d # good: [705d0bf83dbef34d49927d3bf05c6d497f42e8b0] ath9k: Add a routine for initializing channel contexts git bisect good 705d0bf83dbef34d49927d3bf05c6d497f42e8b0 # good: [d17ec4d55223d9487df195012762da6f85862d4c] Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next git bisect good d17ec4d55223d9487df195012762da6f85862d4c # bad: [d377921ed031588e1a39e4be730033d962b2c456] Merge remote-tracking branch 'mtd/master' git bisect bad d377921ed031588e1a39e4be730033d962b2c456 # good: [15c9ec43b0948940926ce4c063b5d78a28511771] Bluetooth: Remove hci_conn_hold/drop from hci_chan git bisect good 15c9ec43b0948940926ce4c063b5d78a28511771 # good: [cf0ba860a91ed2f912f5598a331e3fbd40688f8d] Bluetooth: Move clock offset reading into hci_disconnect() git bisect good cf0ba860a91ed2f912f5598a331e3fbd40688f8d # bad: [c728ab656f738adfd5da968b5039789edad1ebc3] Merge remote-tracking branch 'wireless-next/master' git bisect bad c728ab656f738adfd5da968b5039789edad1ebc3 # bad: [db906eb2101b0564b0c65edf4a8647395196342e] ath5k: added debugfs file for dumping eeprom git bisect bad db906eb2101b0564b0c65edf4a8647395196342e # good: [87fed556d08d21dd7dd3e0222c94c187e4c2d5e2] bcma: get info about flash type SoC booted from git bisect good 87fed556d08d21dd7dd3e0222c94c187e4c2d5e2 # first bad commit: [db906eb2101b0564b0c65edf4a8647395196342e] ath5k: added debugfs file for dumping eeprom -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] media: davinci: vpif_capture: drop setting of vb2 buffer state to ACTIVE
this patch drops setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE, as any buffer queued to the driver is marked ACTIVE by the vb2 core. Signed-off-by: Lad, Prabhakar --- drivers/media/platform/davinci/vpif_capture.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index cf15bb1..881efcd 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -213,8 +213,6 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count) /* Remove buffer from the buffer queue */ list_del(>cur_frm->list); spin_unlock_irqrestore(>irqlock, flags); - /* Mark state of the current frame to active */ - common->cur_frm->vb.state = VB2_BUF_STATE_ACTIVE; addr = vb2_dma_contig_plane_dma_addr(>cur_frm->vb, 0); @@ -350,7 +348,6 @@ static void vpif_schedule_next_buffer(struct common_obj *common) /* Remove that buffer from the buffer queue */ list_del(>next_frm->list); spin_unlock(>irqlock); - common->next_frm->vb.state = VB2_BUF_STATE_ACTIVE; addr = vb2_dma_contig_plane_dma_addr(>next_frm->vb, 0); /* Set top and bottom field addresses in VPIF registers */ -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] media: davinci: vpif_capture: fix the check on suspend/resume callbacks
It is possible to call STREAMON without having any buffers queued. So vb2_is_streaming() can return true without start_streaming() having been called. Only after at least one buffer has been queued will start_streaming be called. The check vb2_is_streaming() is incorrect as this would start the DMA without having proper DMA pointers set up. this patch uses vb2_start_streaming_called() instead to check is streaming was called. Signed-off-by: Lad, Prabhakar --- drivers/media/platform/davinci/vpif_capture.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_capture.c b/drivers/media/platform/davinci/vpif_capture.c index 881efcd..3ccb26f 100644 --- a/drivers/media/platform/davinci/vpif_capture.c +++ b/drivers/media/platform/davinci/vpif_capture.c @@ -1596,7 +1596,7 @@ static int vpif_suspend(struct device *dev) ch = vpif_obj.dev[i]; common = >common[VPIF_VIDEO_INDEX]; - if (!vb2_is_streaming(>buffer_queue)) + if (!vb2_start_streaming_called(>buffer_queue)) continue; mutex_lock(>lock); @@ -1630,7 +1630,7 @@ static int vpif_resume(struct device *dev) ch = vpif_obj.dev[i]; common = >common[VPIF_VIDEO_INDEX]; - if (!vb2_is_streaming(>buffer_queue)) + if (!vb2_start_streaming_called(>buffer_queue)) continue; mutex_lock(>lock); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] media: davinci: vpif_display: drop setting of vb2 buffer state to ACTIVE
this patch drops setting of vb2 buffer state to VB2_BUF_STATE_ACTIVE, as any buffer queued to the driver is marked ACTIVE by the vb2 core. Signed-off-by: Lad, Prabhakar --- drivers/media/platform/davinci/vpif_display.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c index 2ce3ddf..76f829d 100644 --- a/drivers/media/platform/davinci/vpif_display.c +++ b/drivers/media/platform/davinci/vpif_display.c @@ -196,8 +196,6 @@ static int vpif_start_streaming(struct vb2_queue *vq, unsigned int count) list_del(>cur_frm->list); spin_unlock_irqrestore(>irqlock, flags); - /* Mark state of the current frame to active */ - common->cur_frm->vb.state = VB2_BUF_STATE_ACTIVE; addr = vb2_dma_contig_plane_dma_addr(>cur_frm->vb, 0); common->set_addr((addr + common->ytop_off), @@ -306,8 +304,6 @@ static void process_progressive_mode(struct common_obj *common) /* Remove that buffer from the buffer queue */ list_del(>next_frm->list); spin_unlock(>irqlock); - /* Mark status of the buffer as active */ - common->next_frm->vb.state = VB2_BUF_STATE_ACTIVE; /* Set top and bottom field addrs in VPIF registers */ addr = vb2_dma_contig_plane_dma_addr(>next_frm->vb, 0); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] media: davinci: vpif_display: fix the check on suspend/resume callbacks
It is possible to call STREAMON without having any buffers queued. So vb2_is_streaming() can return true without start_streaming() having been called. Only after at least one buffer has been queued will start_streaming be called. The check vb2_is_streaming() is incorrect as this would start the DMA without having proper DMA pointers set up. this patch uses vb2_start_streaming_called() instead to check is streaming was called. Signed-off-by: Lad, Prabhakar --- drivers/media/platform/davinci/vpif_display.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/davinci/vpif_display.c b/drivers/media/platform/davinci/vpif_display.c index 76f829d..8d6ced5 100644 --- a/drivers/media/platform/davinci/vpif_display.c +++ b/drivers/media/platform/davinci/vpif_display.c @@ -1400,7 +1400,7 @@ static int vpif_suspend(struct device *dev) ch = vpif_obj.dev[i]; common = >common[VPIF_VIDEO_INDEX]; - if (!vb2_is_streaming(>buffer_queue)) + if (!vb2_start_streaming_called(>buffer_queue)) continue; mutex_lock(>lock); @@ -1432,7 +1432,7 @@ static int vpif_resume(struct device *dev) ch = vpif_obj.dev[i]; common = >common[VPIF_VIDEO_INDEX]; - if (!vb2_is_streaming(>buffer_queue)) + if (!vb2_start_streaming_called(>buffer_queue)) continue; mutex_lock(>lock); -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] media: davinci: vpif fixes
this patch series fixes several small issues in VPIF driver. Lad, Prabhakar (5): media: davinci: vpif_display: drop setting of vb2 buffer state to ACTIVE media: davinci: vpif_capture: drop setting of vb2 buffer state to ACTIVE media: videobuf2-core.h: add a helper to get status of start_streaming() media: davinci: vpif_display: fix the check on suspend/resume callbacks media: davinci: vpif_capture: fix the check on suspend/resume callbacks drivers/media/platform/davinci/vpif_capture.c | 7 ++- drivers/media/platform/davinci/vpif_display.c | 8 ++-- include/media/videobuf2-core.h| 9 + 3 files changed, 13 insertions(+), 11 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] media: videobuf2-core.h: add a helper to get status of start_streaming()
this patch adds a helper to get the status if start_streaming()
was called successfully.
Signed-off-by: Lad, Prabhakar
Cc: Pawel Osciak
Cc: Marek Szyprowski
Cc: Kyungmin Park
Cc: Hans Verkuil
---
include/media/videobuf2-core.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/media/videobuf2-core.h b/include/media/videobuf2-core.h
index 5a10d8d..b3c9973 100644
--- a/include/media/videobuf2-core.h
+++ b/include/media/videobuf2-core.h
@@ -590,6 +590,15 @@ vb2_plane_size(struct vb2_buffer *vb, unsigned int
plane_no)
return 0;
}
+/**
+ * vb2_start_streaming_called() - return streaming status of driver
+ * @q: videobuf queue
+ */
+static inline bool vb2_start_streaming_called(struct vb2_queue *q)
+{
+ return q->start_streaming_called;
+}
+
/*
* The following functions are not part of the vb2 core API, but are simple
* helper functions that you can use in your struct v4l2_file_operations,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tools : adds support for native scripting
On Thursday 22 May 2014 04:24:11 Andi Kleen wrote: > Adrien BAK writes: > > As it is perf-script allows one to use perl or python scripts to parse > > perf events. > > The following proposal aimed to introduce support of .so files as scripts. > > This support allows for better performance when parsing perf's data > > files and a complete access to the raw data. > > You'll at least need some documentation how to use it. Ping, any news on this feature? I'd welcome the ability to create native scripts to write efficient tools based on perf. Bye -- Milian Wolff m...@milianw.de http://milianw.de -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/4] thermal: add more description for thermal-zones
Hello Wei, On Fri, Sep 05, 2014 at 05:41:12PM +0800, Wei Ni wrote: > Hi, Eduardo > > On 09/01/2014 06:26 PM, Wei Ni wrote: > > On 08/29/2014 07:32 PM, edubez...@gmail.com wrote: > >> Hello Wei, > >> > >> On Thu, Aug 28, 2014 at 11:03 PM, Wei Ni wrote: > >>> On 08/28/2014 09:21 PM, Eduardo Valentin wrote: > Hello Wei, > > On Thu, Aug 28, 2014 at 09:50:01AM +0800, Wei Ni wrote: > > On 08/27/2014 09:32 PM, Eduardo Valentin wrote: > >> Hello Wei, > >> > >> On Wed, Aug 27, 2014 at 10:54:07AM +0800, Wei Ni wrote: > >>> On 08/26/2014 08:12 PM, Eduardo Valentin wrote: > On Tue, Aug 26, 2014 at 10:17:29AM +0800, Wei Ni wrote: > > On 08/25/2014 07:07 PM, Eduardo Valentin wrote: > >> Hello Wei Ni, > >> > >> On Mon, Aug 25, 2014 at 02:29:47PM +0800, Wei Ni wrote: > >>> Add more description for the "polling-delay" property. > >>> Set "trips" and "cooling maps" as optional property, because > >>> if missing these two sub-nodes, the thermal zone device still > >>> work properly. > >>> > >>> Signed-off-by: Wei Ni > >>> --- > >>> Documentation/devicetree/bindings/thermal/thermal.txt | 10 > >>> ++ > >>> 1 file changed, 6 insertions(+), 4 deletions(-) > >>> > >>> diff --git > >>> a/Documentation/devicetree/bindings/thermal/thermal.txt > >>> b/Documentation/devicetree/bindings/thermal/thermal.txt > >>> index f5db6b7..e3d3ed9 100644 > >>> --- a/Documentation/devicetree/bindings/thermal/thermal.txt > >>> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt > >>> @@ -136,8 +136,8 @@ containing trip nodes and one sub-node > >>> containing all the zone cooling maps. > >>> > >>> Required properties: > >>> - polling-delay: The maximum number of milliseconds to wait > >>> between polls > >>> - Type: unsigned when checking this thermal zone. > >>> - Size: one cell > >>> + Type: unsigned when checking this thermal zone. If this > >>> value is 0, the > >>> + Size: one cell driver will not run polling queue, but > >>> just cancel it. > >>> > >> > >> The description above is specific to Linux kernel implementation > >> nomenclature. DT description needs to be OS agnostic. > >> > >>> - polling-delay-passive: The maximum number of milliseconds to > >>> wait > >>>Type: unsigned between polls when performing passive > >>> cooling. > >>> @@ -148,14 +148,16 @@ Required properties: > >>>phandles + sensor > >>>specifier > >>> > >>> +Optional property: > >>> - trips: A sub-node which is a container of only > >>> trip point nodes > >>>Type: sub-node required to describe the thermal zone. > >>> > >>> - cooling-maps: A sub-node which is a container of > >>> only cooling device > >>>Type: sub-node map nodes, used to describe the relation > >>> between trips > >>> - and cooling devices. > >>> + and cooling devices. If missing the > >>> "trips" property, > >>> + This sub-node will not be parsed, because > >>> no trips can > >>> + be bound to cooling devices. > >> > >> Do you mean if the thermal zone misses the "trips" property? > >> Actually, > >> the binding describes both, cooling-maps and trips, as required > >> properties. Thus, both needs to be in place to consider the > >> thermal zone > >> as a proper described zone. > > > > I moved the "trips" and "cooling-maps" to optional property, > > because if > > missing these two properties, the thermal zone devices still can be > > registered, and the driver can work properly, it has the basic > > function, > > can read temperature from thermal sysfs, although it doesn't have > > trips > > and bind with cooling devices. > > > If a thermal zone is used only for monitoring, then I believe it lost > its purpose. As Maybe a different framework shall be used, such as > hwmon, > for instance? > >>> > >>> Yes, if we only use it for monitoring, we can use hwmon. But we have > >>> more functions base on these two thermal zone devices. We have a > >>> skin-temperature driver, which used nct1008's remote and local > >>> temperatures to estimator the skin temperature. As you know the > >>> thermal > >>> framework is more powerful, the remote/local sensors can be register
Re: [PATCH] scsi_debug: deadlock between completions and surprise module removal
On Sat, Sep 06, 2014 at 10:40:06AM -0400, Douglas Gilbert wrote:
> And they do call scsi_remove_host(). But they do that toward
> the end of their clean-up. The problem that I observed has
> already happened before that.
>
> IOW I think the QUEUE_FLAG_DYING state needs to be set and
> acknowledged as the first order of business by the code
> that implements 'rmmod LLD'.
That's how driver should implement their ->remove driver callback:
foo_remove()
{
scsi_remove_host()
< actual cleanup here>
scsi_host_put();
}
if a driver doesn't do that, thats a bug in the driver which needs
fixing.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Let's Partner In Trust.
I need your help to transfer funds to buy properties:Email:ongenghuat...@gmail.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] scsi_debug: deadlock between completions and surprise module removal
On 14-09-05 11:25 AM, Bart Van Assche wrote: On 09/05/14 15:56, Douglas Gilbert wrote: With scsi-mq I think many LLDs probably have a new race possibility between a surprise rmmod of the LLD and another thread presenting a new command at about the same time (or another thread's command completing around that time). Does anything above the LLD stop this happening? Looking at mpt3sas and hpsa module exit calls, they don't seem to guard against this possibility. The test is pretty easy: build the LLD as a module, load it and fire up a multi-thread, libaio fio test on one or more devices (SSDs would probably be good) on that LLD. While the test is running, do 'rmmod LLD'. An LLD must call scsi_remove_host() directly or indirectly from the module cleanup path. scsi_remove_host() triggers a call to blk_cleanup_queue(). That last function sets the flag QUEUE_FLAG_DYING which prevents that new I/O is queued and waits until previously queued requests have finished before returning. And they do call scsi_remove_host(). But they do that toward the end of their clean-up. The problem that I observed has already happened before that. IOW I think the QUEUE_FLAG_DYING state needs to be set and acknowledged as the first order of business by the code that implements 'rmmod LLD'. Doug Gilbert -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2.2 2/2] dt-bindings: Adding compatible attribute for SKY81452 regulator
On Fri, Sep 05, 2014 at 10:55:07AM +0900, Gyungoh Yoo wrote: > On Mon, Sep 01, 2014 at 11:31:58AM +0100, Mark Brown wrote: > > Why is this a good idea - can this driver be used for anything other > > than a sky81452? > Yes. There is a possibility that this driver will be used by similar > device with SKY81452. OK, so tha was slightly the wrong question. What added information is forcing the user to create a subnode and specify a compatible string providing? This driver is specifying a block of multiple regulators with absolute register addresses hard coded into it, there's no real ability to use the driver in a different configuration here. As soon as we see the parent device we already know everything there is to know about the IP block, having a separate compatible string just forces the user to do more typing for no gain. signature.asc Description: Digital signature
Re: [PATCH] staging: bcm: sort.c: fix coding style
Reviewed-by: Matthias Beyer On 06-09-2014 01:59:37, Omar Sandoval wrote: > Fix checkpatch.pl "Alignment should match open parenthesis". > > Signed-off-by: Omar Sandoval > --- > drivers/staging/bcm/sort.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/staging/bcm/sort.c b/drivers/staging/bcm/sort.c > index d518c42..ca0b179 100644 > --- a/drivers/staging/bcm/sort.c > +++ b/drivers/staging/bcm/sort.c > @@ -28,7 +28,7 @@ VOID SortPackInfo(struct bcm_mini_adapter *Adapter) > DBG_LVL_ALL, "<==="); > > sort(Adapter->PackInfo, NO_OF_QUEUES, sizeof(struct bcm_packet_info), > - compare_packet_info, NULL); > + compare_packet_info, NULL); > } > > static int compare_classifiers(void const *a, void const *b) > @@ -48,5 +48,5 @@ VOID SortClassifiers(struct bcm_mini_adapter *Adapter) > DBG_LVL_ALL, "<==="); > > sort(Adapter->astClassifierTable, MAX_CLASSIFIERS, > - sizeof(struct bcm_classifier_rule), compare_classifiers, NULL); > + sizeof(struct bcm_classifier_rule), compare_classifiers, NULL); > } > -- > 2.1.0 > > ___ > devel mailing list > de...@linuxdriverproject.org > http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel -- Mit freundlichen Grüßen, Kind regards, Matthias Beyer Proudly sent with mutt. Happily signed with gnupg. pgpEyT5kHnWOu.pgp Description: PGP signature
Re: [PATCH v6 0/4] APM X-Gene PCIe host controller
On Fri, Sep 5, 2014 at 6:25 PM, Tanmay Inamdar wrote: > This patch adds support for AppliedMicro X-Gene PCIe host controller. The > driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint > cards. > > X-Gene PCIe controller driver has depedency on the pcie arm64 arch support. > Liviu Dudau from ARM has sent a patch set for pcie arm64 arch support and > support for creating generic pcie bridge from device tree. Liviu's patches > are available here > 1. https://lkml.org/lkml/2014/8/12/361 I'm hoping to merge Liviu's patches and this X-Gene support for v3.18. I'm currently waiting for Liviu's v10 series (hopefully based on v3.17-rc2), and since your series depends on that, I'm going to wait for a v7 of your series that is rebased on top of Liviu's v10. Does that make sense? > If someone wishes to test PCIe on X-Gene with this patch set, above mentioned > patches from Liviu must be applied before the patches in this patch set. Also > please use latest xgene u-boot firmware. > > changes since V5: > 1. Port driver to changed interface of 'of_create_pci_host_bridge' > 2. Fix the prefetch bit setting > 3. Removed bunch of register programming which is already done by firmware > > changes since V4: > 1. fix section mismatch warnings > 2. fix the patch description > 3. fix indentation > 4. update read/write cfg functions by passing both addr and offset. > 5. use 'time_before' for timeout. > 6. remove unnecessary 'IS_ERR_OR_NULL'. Keep 'IS_ERR' for 'clk_get' > 7. remove BUG_ON for pci_ioremap_io. > > changes since V3: > 1. remove 'struct hw_pci' and supporting ops in hw_pci > 2. add code to create the host bridge from dts > 3. add code to scan the the host bridge > 4. modify outbound windows setup function to get resource information from >'bridge->windows' > 5. add compatible string in pcie dts node with current X-Gene SOC name. > > changes since V2: > 1. redefined each PCI port in different PCI domain correctly. > 2. removed setup_lane and setup_link functions from driver. > 3. removed scan_bus wrapper and set_primary_bus hack. > 4. added pci_ioremap_io for io resources. > > changes since V1: > 1. added PCI domain support > 2. reading cpu and pci addresses from device tree to configure regions. > 3. got rid of unnecessary wrappers for readl and writel. > 4. got rid of endpoint configuration code. > 5. added 'dma-ranges' property support to read inbound region configuration. > 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c' > 7. dropped 'clock-names' property from bindings > 8. added comments whereever requested. > > Tanmay Inamdar (4): > pci:host: APM X-Gene PCIe controller driver > arm64: dts: APM X-Gene PCIe device tree nodes > dt-bindings: pci: xgene pcie device tree bindings > MAINTAINERS: entry for APM X-Gene PCIe host driver > > .../devicetree/bindings/pci/xgene-pci.txt | 55 ++ > MAINTAINERS| 8 + > arch/arm64/boot/dts/apm-mustang.dts| 8 + > arch/arm64/boot/dts/apm-storm.dtsi | 160 ++ > drivers/pci/host/Kconfig | 10 + > drivers/pci/host/Makefile | 1 + > drivers/pci/host/pci-xgene.c | 638 > + > 7 files changed, 880 insertions(+) > create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt > create mode 100644 drivers/pci/host/pci-xgene.c > > -- > 1.9.1 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] ASOC: dapm: add code to configure dai link parameters
On Mon, Sep 01, 2014 at 09:56:53AM +0100, Nikesh Oswal wrote:
> dai-link params for codec-codec links were fixed. The fixed
> link between codec and another chip which may be another codec,
> baseband, bluetooth codec etc may require run time configuaration
> changes. This change provides an optional alsa control to select
> one of the params from a list of params.
As I'm fairly sure I've told you several times now please use subject
lines matching the style for the subsystem - if your commit logs look
different to all the other commit logs that's probably not a good sign.
In this specific case "ASOC" and "ASoC" are not the same thing.
> + for (count = 0 ; count < num_params; count++) {
> + w_param_text[count] = kmemdup((void *)(config->stream_name),
> + strlen(config->stream_name) + 1, GFP_KERNEL);
> + if (!w_param_text[count]) {
> + ret = -ENOMEM;
> + goto outfree_w_param;
> + }
> + config++;
> + }
This will happily create values with a completely empty name if the user
didn't specify one. This doesn't seem great - it's going to be an easy
mistake to make and fail to notice. I'd at least expect a warning here.
> + w_param_enum[0].items = num_params;
> + w_param_enum[0].texts = (const char * const *) w_param_text;
Why the casts? This tends to be a sign that something is wrong.
signature.asc
Description: Digital signature
Re: [PATCH] arm64: LLVMLinux: Provide __aeabi_* symbols which are needed for clang
On Friday 05 September 2014 16:23:14 beh...@converseincode.com wrote: > --- /dev/null > +++ b/arch/arm64/lib/eabi.c > @@ -0,0 +1,32 @@ > +/* > + * linux/lib/eabi.c Please don't put the file names in the files themselves, it's redundant and in this case actually wrong. > + * Copyright (C) 2012 Mark Charlebois > + */ > + > +/* > + * EABI routines Does EABI specify these function names? I would think that they are just random libgcc (whatever that is called in clang) functions. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: LLVMLinux: Add missing abort() for AARCH64
On Friday 05 September 2014 16:21:42 beh...@converseincode.com wrote:
> From: Mark Charlebois
>
> Add missing abort for arch aarch64.
>
> This patch makes the aarch64 kernel able to compile with gcc or clang.
>
> Signed-off-by: Mark Charlebois
> Signed-off-by: Behan Webster
You don't describe why this is needed. When does clang emit an abort()
call? Is that the expected behavior when not linking against a full
C library?
> arch/arm64/kernel/traps.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
> index 02cd3f0..123cd6e 100644
> --- a/arch/arm64/kernel/traps.c
> +++ b/arch/arm64/kernel/traps.c
> @@ -349,6 +349,15 @@ void __pgd_error(const char *file, int line, unsigned
> long val)
> pr_crit("%s:%d: bad pgd %016lx.\n", file, line, val);
> }
>
> +void abort(void)
> +{
> + BUG();
> +
> + /* if that doesn't kill us, halt */
> + panic("Oops failed to kill thread");
> +}
> +EXPORT_SYMBOL(abort);
I don't see the point in doing both BUG() and panic(). Doesn't panic()
already print all the information you want in this case?
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 net-next 2/2] net: filter: split filter.h and expose eBPF to user space
On Thu, Sep 04, 2014 at 10:17:18PM -0700, Alexei Starovoitov wrote: > allow user space to generate eBPF programs > > uapi/linux/bpf.h: eBPF instruction set definition > > linux/filter.h: the rest > > This patch only moves macro definitions, but practically it freezes existing > eBPF instruction set, though new instructions can still be added in the > future. > > These eBPF definitions cannot go into uapi/linux/filter.h, since the names > may conflict with existing applications. > > Full eBPF ISA description is in Documentation/networking/filter.txt I think you need to have at least one single interface using this before you can expose it to userspace. So this should come in the small batch that introduces the first interface of your ebpf code in userspace. AFAIK, this has been the policy so far. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] gpio: Add driver for AXM55xx SSP chip selects
On Fri, Sep 05, 2014 at 11:05:37AM +0200, Anders Berg wrote: > Well, the problem with adding this to the spi-pl022 driver (as a > vendor specific extension) is that this IP block unfortunately isn't > distinguishable from the standard ARM PL022 implementation (same > values in the PrimeCell identification registers). That's why I went > down the GPIO path... Would it not be more straightforward to just register it as a platform device in this case, or use a separate OF ID in the DT? We appear to specify a compatible string when registering AMBA devices even if we are capable of identifying using the ID registers. signature.asc Description: Digital signature
Re: [PATCH v2] regulator: hi6421: Fix misleading comment
On Sat, Sep 06, 2014 at 08:59:36PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin Applied, thanks. Please always send incremental patches. signature.asc Description: Digital signature
