Re: [PATCH v6] ext4: Add support FALLOC_FL_COLLAPSE_RANGE for fallocate

[Namjae Jeon]

2014-02-27 1:48 GMT+09:00, Theodore Ts'o :
> On Mon, Feb 24, 2014 at 10:22:10AM +0900, Namjae Jeon wrote:
>> >> + ret = ext4_es_remove_extent(inode, punch_start,
>> >> + EXT_MAX_BLOCKS - punch_start - 1);
>> >> + if (ret) {
>> >> + up_write(_I(inode)->i_data_sem);
>> >> + goto out_stop;
>> >> + }
>> >
>> > Doing this at first is probably a bad idea; you should do this at the
>> > end, and then completely invalidate the es cache for that inode.  That
>> > way, the right thing happens if you get an error in the middle
>> > releasing the boxes and shifting the extents:
>> Okay, I see.
>
> Actually, thinking about this some more, we do want to do this first,
> since if we error out, we do need to make sure the extent cache is
> flushed.
Okay.

>
>> If there is error in the middle of extent shifting, the hole will
>> present between the last shifted extent and the extent at which error
>> happen so this will be consistent state.
>> IMHO even if there is error in between the shift, filesystem will be
>> in consistent state.
>> Am I missing something?
>
> No, I was wrong about that; you're right.  The file will be in an
> inconsistent statement, which will probably be highly confusing for
> the application, but the file system will be fine.
>
> So I withdraw my complaints.  I'll do a bit more testing, but so far
> the patch looks fine to me.  Thanks for your reply and your work!
Thanks for your review! I will fix these include Hugh's review points.
>
>   - Ted
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regmap: don't use spinlocks with REGCACHE_{RBTREE,COMPRESSED}

[Andrew Bresticker]

Both REGCACHE_RBTREE and REGCACHE_COMPRESSED make GFP_KERNEL allocations
with the regmap lock held.  If we're initializing a regmap which would
normally use a spinlock (e.g. MMIO), fall back to using a mutex if one
of these caching types is to be used.

Signed-off-by: Andrew Bresticker 
---
 drivers/base/regmap/regmap.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 2b4e72f..fb618d2 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -438,8 +438,9 @@ struct regmap *regmap_init(struct device *dev,
map->unlock = config->unlock;
map->lock_arg = config->lock_arg;
} else {
-   if ((bus && bus->fast_io) ||
-   config->fast_io) {
+   if (((bus && bus->fast_io) || config->fast_io) &&
+   config->cache_type != REGCACHE_RBTREE &&
+   config->cache_type != REGCACHE_COMPRESSED) {
spin_lock_init(>spinlock);
map->lock = regmap_lock_spinlock;
map->unlock = regmap_unlock_spinlock;
-- 
1.9.0.rc1.175.g0b1dcb5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / EC: Clear stale EC events on Samsung systems

[Kieran Clancy]

On Thu, Feb 27, 2014 at 12:29 PM, Li Guang  wrote:
>> +#define ACPI_EC_CLEAR_MAX  20  /* Maximum number of events to
>> query
>> +* when trying to clear the EC */
>>
>
>
> 20 is enough?
> the query index is length of a byte.

On my machine, 8 seems to be enough, so 20 seems to be a conservative
maximum. Just reading your other email, maybe we should set this to
32? or 40? 100?

If it's not enough, hopefully anyone seeing bugs will notice the
warning "maximum of X stale EC events cleared".

Here's what happens if I plug/replug the AC lots of times (more than
8) during suspend:

[ 8807.019800] ACPI : EC: ---> status = 0x29
[ 8807.019804] ACPI : EC: ---> data = 0x66
[ 8807.020790] ACPI : EC: ---> status = 0x29
[ 8807.020793] ACPI : EC: ---> data = 0x66
[ 8807.021793] ACPI : EC: ---> status = 0x29
[ 8807.021798] ACPI : EC: ---> data = 0x66
[ 8807.022831] ACPI : EC: ---> status = 0x29
[ 8807.022834] ACPI : EC: ---> data = 0x66
[ 8807.023788] ACPI : EC: ---> status = 0x29
[ 8807.023792] ACPI : EC: ---> data = 0x66
[ 8807.024787] ACPI : EC: ---> status = 0x29
[ 8807.024791] ACPI : EC: ---> data = 0x66
[ 8807.025787] ACPI : EC: ---> status = 0x29
[ 8807.025790] ACPI : EC: ---> data = 0x66
[ 8807.026787] ACPI : EC: ---> status = 0x29
[ 8807.026790] ACPI : EC: ---> data = 0x66
[ 8807.027786] ACPI : EC: ---> status = 0x09
[ 8807.027790] ACPI : EC: ---> data = 0x00
[ 8807.027792] ACPI : EC: 8 stale EC events cleared

Note that most of these have SCI_EVT set, but the OS is not notified
according to ACPI specs (seemingly because these events happened
during sleep).

The _Q66 method in my DSDT, is:

P8XH (Zero, 0x66)
If (LEqual (B1EX, One))
{
Notify (BAT1, 0x80)
}

So, basically, this is supposed to notify that the battery (BAT1 =
PNP0C0A) has changed state, but they are stale events so we don't run
the handlers.

>> +static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on
>> boot/resume */
>
> seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
> seems too long :-)

In my mind this is referring to the function name (acpi_ec_)clear.
Perhaps we could just make the connection more explicit in the
comment:

/* needs acpi_ec_clear() on boot/resume */

Not sure if this is better?

>> +   /* Some hardware may need the EC to be cleared before use */
>
> description is implicit, should specify what we clear is Q event, not EC.

Are Q events the only thing we can get from the EC data port? I've
read the relevant parts of the ACPI spec and I can't say I am 100%
sure.

Thank you for your advice,
Kieran.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / EC: Clear stale EC events on Samsung systems

[Li Guang]

Juan Manuel Cabo wrote:

On 02/27/2014 12:14 AM, Li Guang wrote:
   

oh, sorry, I'm referring internal EC firmware code
for Q event queuing, not ACPI SPEC, ;-)
for machine you tested, 8 is the queue size,
but for some unknown also nasty EC firmwares(let's suppose it exists),
it may queue more Q events.
and I saw several firmwares queued 32 events by default,
then, let's say, they be used for some samsung products,
and also they also forgot to deal with sleep/resume state,
then, we'll also leave stale Q event there.

Thanks!

 

We tested each on our different samsung models (intel, amd), and it
was 8 across. But you're right, there might be more in the future.

  I even saw a bug report in ubuntu's launchpad of an HP with a similar
sounding problem, ( 
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89860 )
which I have no idea if it was caused by the same issue, but if in the future,
the flag ec_clear_on_resume is used to match other DMI's, it might
be a good idea to make the max iteration count bigger.

   The only reason that there is a max iteration count, was to prevent
an unexpected case in which an unknown EC never returns 0 after
queue emptied. So far it hasn't been the case. Can we count on it?.
The loop currently does finish early when there are no more events.

I guess changing it 255 or 1000 would be enough, right?

   


can't imagine 1K bytes be dissipated on Q event,
EC's ram is usually expensive,
I think 255 is really enough. :-)

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: 3.13.5 : rm -rf running forever, one cpu at approx 100%

[Ken Moffat]

On Thu, Feb 27, 2014 at 04:26:35AM +0100, Mike Galbraith wrote:
> 
> I would start with strace to see if a task is looping in userspace, then
> move on to perf top -g -p  (or perf record/report) to peek at what
> it's up to in the kernel.  Once you have the where, trace_printk() is
> the best thing since sliced bread (which ranks just below printk()).
> 
> -Mike
 Thanks.  I'll need to build perf.

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sparse: Allow override of sizeof(bool) warning

[H. Peter Anvin]

sizeof(_Bool), like for many other types, is ABI-dependent, but that doesn't 
mean it is illegitimate.

I don't think C99 says that it is invalid (which means C99 doesn't permit is to 
be a packed bitmap.)

On February 26, 2014 7:38:46 PM PST, Joe Perches  wrote:
>(adding Ben Pfaff and Christopher Li)
>
>On Wed, 2014-02-26 at 19:29 -0800, H. Peter Anvin wrote:
>> On 02/26/2014 06:58 PM, Josh Triplett wrote:
>> > On Wed, Feb 26, 2014 at 06:53:14PM -0800, Joe Perches wrote:
>> >> Allow an override to emit or not the sizeof(bool) warning
>> >> Add a description to the manpage.
>> >>
>> >> Signed-off-by: Joe Perches 
>> > 
>> > Reviewed-by: Josh Triplett 
>> > 
>> 
>> I have to admit that this particular warning is a bit odd to me.  I'm
>> wondering what kind of bugs it was intended to catch.
>> 
>> In particular, things that incorrectly assumes the size of bool to be
>> anything in particular would seem unlikely to actually use sizeof().
>
>Dunno, the commit log for the commit that added it doesn't quite
>match the code and is seemingly unaware that the c99 spec doesn't
>specify sizeof(bool).
>
>Ben Pfaff 
>Date:   Wed May 4 16:39:54 2011 -0700
>
>evaluate: Allow sizeof(_Bool) to succeed.
>
> Without this commit, sizeof(_Bool) provokes an error with "cannot size
>expression" because _Bool is a 1-bit type and thus not a multiple of a
>full
>byte in size.  But sizeof(_Bool) is valid C that should evaluate to 1,
>so
>this commit fixes the problem and adds a regression test.
>
>Signed-off-by: Ben Pfaff 
>Signed-off-by: Christopher Li 

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

Re: The sheer number of sparse warnings in the kernel

[Dave Jones]

On Wed, Feb 26, 2014 at 05:34:24PM -0800, Greg KH wrote:

 > Yes, for some areas of the kernel it will take some work, but for
 > others, sparse works really well.  As an example, building all of
 > drivers/usb/* with sparse only brings up 2 issues, both of which should
 > probably be fixed (or annotated properly in the case of the locking
 > warning.)

Hm. I see 102 in drivers/usb. Mostly in gadget. 
http://paste.fedoraproject.org/80787/39347077/raw/

(Note that some of those are duplicates, which would be nice if sparse
would be quieter about)

Dave

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86: Mark __vdso entries as asmlinkage

[Andi Kleen]

On Wed, Feb 26, 2014 at 05:02:13PM -0800, Andy Lutomirski wrote:
> This makes no difference for 64-bit, bit it's critical for 32-bit code:
> these functions are called from outside the kernel, so they need to comply
> with the ABI.

That's an odd patch. If that was wrong things couldn't have worked at all.
Probably hidden by inlining? If yes just make it static

Also you would rather need notrace more often.

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

Re: [PATCH V2] sparse: Allow override of sizeof(bool) warning

[Joe Perches]

(adding Ben Pfaff and Christopher Li)

On Wed, 2014-02-26 at 19:29 -0800, H. Peter Anvin wrote:
> On 02/26/2014 06:58 PM, Josh Triplett wrote:
> > On Wed, Feb 26, 2014 at 06:53:14PM -0800, Joe Perches wrote:
> >> Allow an override to emit or not the sizeof(bool) warning
> >> Add a description to the manpage.
> >>
> >> Signed-off-by: Joe Perches 
> > 
> > Reviewed-by: Josh Triplett 
> > 
> 
> I have to admit that this particular warning is a bit odd to me.  I'm
> wondering what kind of bugs it was intended to catch.
> 
> In particular, things that incorrectly assumes the size of bool to be
> anything in particular would seem unlikely to actually use sizeof().

Dunno, the commit log for the commit that added it doesn't quite
match the code and is seemingly unaware that the c99 spec doesn't
specify sizeof(bool).

Ben Pfaff 
Date:   Wed May 4 16:39:54 2011 -0700

evaluate: Allow sizeof(_Bool) to succeed.

Without this commit, sizeof(_Bool) provokes an error with "cannot size
expression" because _Bool is a 1-bit type and thus not a multiple of a full
byte in size.  But sizeof(_Bool) is valid C that should evaluate to 1, so
this commit fixes the problem and adds a regression test.

Signed-off-by: Ben Pfaff 
Signed-off-by: Christopher Li 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: build failure after merge of the char-misc tree

[Greg KH]

On Wed, Feb 26, 2014 at 05:47:21PM +1100, Stephen Rothwell wrote:
> Hi Greg,
> 
> On Fri, 21 Feb 2014 16:47:11 +1100 Stephen Rothwell  
> wrote:
> >
> > After merging the char-misc tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> > 
> > In file included from drivers/misc/mei/hw-txe.c:25:0:
> > drivers/misc/mei/hw-txe.h:63:1: error: unknown type name 'irqreturn_t'
> >  irqreturn_t mei_txe_irq_quick_handler(int irq, void *dev_id);
> >  ^
> > 
> > Caused by commit 266f6178d1f1 ("mei: txe: add hw-txe.h header file") but
> > probably exposed by commit 46cb7b1bd86f ("PCI: Remove unused SR-IOV VF
> > Migration support") from the pci tree which removed the include of
> > irqreturn.h from pci.h ...
> > 
> > See Rule 1 from Documentation/SubmitChecklist ...
> > 
> > I added the following merge fix patch (this should be applied to the
> > char-misc tree):
> 
> Ping?

I've merged everything together, and it all builds properly for me in
the char-misc branches, so I don't see what is missing.  What did I do
wrong?

confused,

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

Re: [PATCH v3 3/3] iio: adc: Add MEN 16z188 ADC driver

[Greg Kroah-Hartman]

On Wed, Feb 26, 2014 at 05:20:03PM +, Jonathan Cameron wrote:
> 
> 
> On February 26, 2014 4:29:07 PM GMT+00:00, Johannes Thumshirn 
>  wrote:
> >Add support for MEN 16z188 ADC IP Core on MCB FPGAs.
> >
> >Signed-off-by: Johannes Thumshirn 
> Acked-by: Jonathan Cameron 
> 
> The other two patches look sane to me as well.
> 
> Anyhow, assuming everyone is happy with those (not yet clear)... Greg do you 
> want to
>  take this directly or would you prefer if I pick the series up and send on 
> to you via the IIO
>  tree? I'm happy either way.

I can take it directly, no need for you to queue it up.

thanks,

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

Re: [RFC][PATCH] staging: Fix build issues with new binder API

[Greg KH]

On Wed, Feb 26, 2014 at 02:29:07PM -0800, John Stultz wrote:
> The new 64bit binder API causes build issues on 32bit ARM
> due to the lack of 64bit __get_user_asm_* implementation.

So no one ever tested this out on ARM?  Really, that seems odd...

Anyway, if you want this to always be on, that's fine with me, your
choice :)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / EC: Clear stale EC events on Samsung systems

[Juan Manuel Cabo]

On 02/27/2014 12:14 AM, Li Guang wrote:
> oh, sorry, I'm referring internal EC firmware code
> for Q event queuing, not ACPI SPEC, ;-)
> for machine you tested, 8 is the queue size,
> but for some unknown also nasty EC firmwares(let's suppose it exists),
> it may queue more Q events.
> and I saw several firmwares queued 32 events by default,
> then, let's say, they be used for some samsung products,
> and also they also forgot to deal with sleep/resume state,
> then, we'll also leave stale Q event there.
>
> Thanks!
>

We tested each on our different samsung models (intel, amd), and it
was 8 across. But you're right, there might be more in the future.

 I even saw a bug report in ubuntu's launchpad of an HP with a similar
sounding problem, ( 
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/89860 )
which I have no idea if it was caused by the same issue, but if in the future,
the flag ec_clear_on_resume is used to match other DMI's, it might
be a good idea to make the max iteration count bigger.

  The only reason that there is a max iteration count, was to prevent
an unexpected case in which an unknown EC never returns 0 after
queue emptied. So far it hasn't been the case. Can we count on it?.
The loop currently does finish early when there are no more events.

I guess changing it 255 or 1000 would be enough, right?

Cheers!
-- 
Juan Manuel Cabo



>>  For us, a query is just: send 0x84 through EC CMD port, and read status
>> from CMD port and event type from EC DATA port. This is done with
>> the usual ec.c functions that would handle a query after a GPE interrupt,
>> but using them instead to poll (not GPE initiated) at awake. The EC would
>> then return status without 0x20 mask and 'event type'==0 when no more left.
>>
>> -- 
>> Juan Manuel Cabo
>>
>>
>>
>>   
enum {
EC_FLAGS_QUERY_PENDING,/* Query is pending */
 @@ -116,6 +118,7 @@ EXPORT_SYMBOL(first_ec);
static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be 
 validated */
static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT 
 scan */
 +static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on 
 boot/resume */


>>> seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
>>> seems too long :-)
>>>
>>> 
/* 
 --
 Transaction Management
 @@ -440,6 +443,26 @@ acpi_handle ec_get_handle(void)

EXPORT_SYMBOL(ec_get_handle);

 +static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data);
 +
 +/* run with locked ec mutex */
 +static void acpi_ec_clear(struct acpi_ec *ec)
 +{
 +int i, status;
 +u8 value = 0;
 +
 +for (i = 0; i<   ACPI_EC_CLEAR_MAX; i++) {
 +status = acpi_ec_query_unlocked(ec,);
 +if (status || !value)
 +break;
 +}
 +
 +if (i == ACPI_EC_CLEAR_MAX)
 +pr_warn("Warning: Maximum of %d stale EC events cleared\n", i);
 +else
 +pr_info("%d stale EC events cleared\n", i);
 +}
 +
void acpi_ec_block_transactions(void)
{
struct acpi_ec *ec = first_ec;
 @@ -463,6 +486,10 @@ void acpi_ec_unblock_transactions(void)
mutex_lock(>mutex);
/* Allow transactions to be carried out again */
clear_bit(EC_FLAGS_BLOCKED,>flags);
 +
 +if (EC_FLAGS_CLEAR_ON_RESUME)
 +acpi_ec_clear(ec);
 +
mutex_unlock(>mutex);
}

 @@ -821,6 +848,13 @@ static int acpi_ec_add(struct acpi_device *device)

/* EC is fully operational, allow queries */
clear_bit(EC_FLAGS_QUERY_PENDING,>flags);
 +
 +/* Some hardware may need the EC to be cleared before use */


>>> description is implicit, should specify what we clear is Q event, not EC.
>>>
>>> Thanks!
>>> Li Guang
>>>
>>> 
 +if (EC_FLAGS_CLEAR_ON_RESUME) {
 +mutex_lock(>mutex);
 +acpi_ec_clear(ec);
 +mutex_unlock(>mutex);
 +}
return ret;
}

 @@ -922,6 +956,30 @@ static int ec_enlarge_storm_threshold(const struct 
 dmi_system_id *id)
return 0;
}

 +/*
 + * On some hardware it is necessary to clear events accumulated by the EC 
 during
 + * sleep. These ECs stop reporting GPEs until they are manually polled, 
 if too
 + * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
 + *
 + * https://bugzilla.kernel.org/show_bug.cgi?id=44161
 + *
 + * Ideally, the EC should also be instructed not to accumulate events 
 during
 + * sleep (which Windows seems to do somehow), but the interface to 
 

RE: [PATCH 2/6] usb: gadget: mv_udc: disable HW zlt for ep0

[Peter Chen]

 
> > > > >
> > > > > Chipidea bug too? Does it follow ch 8.5.3.2 Variable-length Data
> > > > > Stage, USB
> > > > 2.0 spec?
> > > >
> > > > wait, this is a chipidea core ? Why aren't you guys using the
> > > > chipidea driver yet ? You need to switch over to that driver dude,
> > > > we can't have duplicated code in the tree.
> > > >
> > > > I'm sorry, but I won't be taking this series, please use chipidea
> > > > driver, it should be very simple to add a glue layer for your core
> > > > to
> > > the chipidea driver.
> > > >
> > >
> > > Yes, it use chipidea IP.
> > > But the driver is earlier than the chipidea one and we use it for
> > > our products.
> > > So it may be not that easy to switch to chipidea driver due to the
> > > stability.
> > >
> >
> > Freescale i.mx SoC used fsl_udc_core.c before which was the one of the
> 
> btw, when can I remove fsl_udc_core.c from the tree ?
> 

Freescale has other processor group (PowerPC, etc) has used this code now.

Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tty: Fix low_latency BUG

[Feng Tang]

Hi Peter,

2014-02-26 23:40 GMT+08:00 Peter Hurley :
> [ +cc linux-bluetooth ]

>>>
>>> Historically, low_latency was used to force wake-up the reading
>>> process rather than wait for the next scheduler tick. The
>>> effect was to trim multiple milliseconds of latency from
>>> when the process would receive new data.
>>>
>>> Recent tests [1] have shown that the reading process now receives
>>> data with only 10's of microseconds latency without low_latency set.
>>
>>
>> The 10's of miscroseconds is ok for 115200 bps like device, but it may
>> hurt the high speed device like Bluetooth which runs at 3M/4M bps or
>> higher.
>
>
> The tests were run at 400Mbps, so 3Mbps or 4Mbps is not a problem
> (but I think you may be confusing throughput with latency).

I wrote the serial driver for intel mid platforms which are widely used
in current smart phones, so I guess I know what I'm talking :)

Our test and customer test cover both the performance and latency.
say like transferring  2 GB file while using BT A2DP to playing music.

Also I heard there is some app which will do real time void/data
exchange with paired bluetooth, here microseconds really means
something.

>
> FWIW, two things affected the latency times of those particular tests;
> 1) the kernel firewire subsystem handles rx data in a tasklet (so not
>directly from IRQ) which negatively affected the latency reported, and
> 2) the ftrace instrumentation is not free and there are several traces per
> rx.
>
> If you look carefully at the test trace data, you'll see that the timestamps
> from tty_flip_buffer_push() of the rx data to n_tty_write() of the
> response averages _~11us_; this is the measured latency from tty driver
> receiving the rx data to reading of that data *and* the process
> response (which comes back up through several tty locks).
>
> Naturally, in mainline kernel, the scheduler load will affect the
> measured latency *but that's true regardless of low_latency rx steering
> because the user-space process must still be woken to complete the read*.
>
>
>> More and more smartphones are using uart as the Bluetooth data
>> interface due to its low-pin, low-power feature, and many of them
>> are using HZ=100 kernel, I'm afraid this added delay may cause
>> some problem.
>
>
> Some hard data showing a real problem would help further this
> discussion; my belief is that 3.12+ w/o low_latency rx steering
> will outperform 3.11- w/ low_latency rx steering in every test.

As for measurements, I guess it should cover 2 parts:
1. the performance, like the BT file transfer data rate
2. the latency, like the real time BT communication

I'll try to get some test data soon. Also I'm wondering what devices
have you tested? regarding these 2 points.

>
> I'm glad to hear that the Bluetooth uart interface is getting
> some use; that means someone will soon be fixing the hard lockup
> in hci_uart_tx_wakeup() reported here:

I'm not very familiar with the BT devices on our platforms, but most
of them are not using the in-kernel BT driver, some just use the
n_tty ldisc and the raw data, some use their own ldisc driver.

Thanks,
Feng
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sparse: Allow override of sizeof(bool) warning

[H. Peter Anvin]

On 02/26/2014 06:58 PM, Josh Triplett wrote:
> On Wed, Feb 26, 2014 at 06:53:14PM -0800, Joe Perches wrote:
>> Allow an override to emit or not the sizeof(bool) warning
>> Add a description to the manpage.
>>
>> Signed-off-by: Joe Perches 
> 
> Reviewed-by: Josh Triplett 
> 

I have to admit that this particular warning is a bit odd to me.  I'm
wondering what kind of bugs it was intended to catch.

In particular, things that incorrectly assumes the size of bool to be
anything in particular would seem unlikely to actually use sizeof().

-hpa


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

Re: [PATCH V3 2/2] x86: IOSF: Change IOSF_MBI Kconfig to default y

[H. Peter Anvin]

On 02/26/2014 11:40 AM, David E. Box wrote:
> From: "David E. Box" 
> 
> The IOSF Mailbox interface is an access mechanism used by multiple drivers to
> communicate with key configuration registers on new Intel SOC platforms. The
> interface is ubiquitous enough that we need to ensure the availability of the
> driver in non-EXPERT configured x86 kernels.
> 
> Signed-off-by: David E. Box 

Hi David,

Could you please update the patch description to explain to people who
may not be familiar why the IOSF driver can't be a module?

-hpa


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

Re: [PATCH 1/2] x86: Mark __vdso entries as asmlinkage

[H. Peter Anvin]

On 02/26/2014 05:02 PM, Andy Lutomirski wrote:
> This makes no difference for 64-bit, bit it's critical for 32-bit code:
> these functions are called from outside the kernel, so they need to comply
> with the ABI.

Or at least with *an* ABI (the i386 syscall vdso uses the syscall
convention, not the i386 ABI convention, for example.)  However, it
probably does makes most sense to just stick with the standard i386 ABI.

-hpa


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

Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%

[Mike Galbraith]

On Thu, 2014-02-27 at 00:52 +, Ken Moffat wrote: 
> Hi,
> 
>  Short summary : on 3.13.5, rm -rf of an application source
> directory on an ext4 filesystem sometimes takes forever (probably
> isn't going anywhere), with one CPU pegged at all-but 100% utilization.
> 
>  I've nearly finished building a new system from source, to check
> various desktop packages in linuxfromscratch.  On this build, much of
> it is things I don't normally use and I needed to upgrade my
> buildscripts, so most of it was built in chroot using 3.10.32.  But
> late last night I booted the new system using 3.13.5 to finish the
> build.  This morning I discovered that rm -rf for the icedtea source
> directory was still running, and had taken over 5 hours of CPU time
> (one CPU seemd to be running at close to 100%, the others had dropped
> to their slowest frequency).  That script was running as root (yeah,
> but it's a new system) and it looks as if /etc/passwd~ had got
> trashed, because I could no longer su or login.  Not sure if that is
> related, at this stage it might just be a side-effect of my scripts.
> 
>  Booted another system, chrooted, fixed up passwords.  Started
> again after commenting out icedtea - I hadn't intended to build
> what was an old version, I'd just forgotten it was in this script -
> that's why I do things in userspace, not the kernel :-(
> 
>  Continued with remaining packages, but a couple of hours later I
> saw a similar "one CPU at 100%, rm -rf GConf source taking forever"
> problem.  Dumped all the processes with Alt-SysRQ-T [ huge log ] but
> at that point 'rm' was merely 'ready' so I doubt there is anything
> useful to see in the log.
> 
>  Built 3.13.4, booted to that.  So far, everything looks good - but
> I'm now building the _current_ version of icedtea, so if this isn't
> a new 3.13.5 problem I guess I'm fairly likely to see it tomorrow.
> 
>  Meanwhile, any suggestions about how I can debug this if I hit it
> again, please ?

I would start with strace to see if a task is looping in userspace, then
move on to perf top -g -p  (or perf record/report) to peek at what
it's up to in the kernel.  Once you have the where, trace_printk() is
the best thing since sliced bread (which ranks just below printk()).

-Mike

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

[PATCH V3] sparse: Allow override of sizeof(bool) warning

[Joe Perches]

Allow an override to emit or not the sizeof(bool) warning.
Add a "-Wsizeof-bool" description to the manpage.

Signed-off-by: Joe Perches 
Reviewed-by: Josh Triplett 
---
v2: Add manpage
v3: gah.  Joe knows his alphabet (sometimes). (shadow _then_ sizeof)

 evaluate.c | 3 ++-
 lib.c  | 2 ++
 lib.h  | 1 +
 sparse.1   | 9 +
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/evaluate.c b/evaluate.c
index 6655615..a45f59b 100644
--- a/evaluate.c
+++ b/evaluate.c
@@ -2057,7 +2057,8 @@ static struct symbol *evaluate_sizeof(struct expression 
*expr)
}
 
if (size == 1 && is_bool_type(type)) {
-   warning(expr->pos, "expression using sizeof bool");
+   if (Wsizeof_bool)
+   warning(expr->pos, "expression using sizeof bool");
size = bits_in_char;
}
 
diff --git a/lib.c b/lib.c
index bf3e91c..d6ac79d 100644
--- a/lib.c
+++ b/lib.c
@@ -226,6 +226,7 @@ int Wparen_string = 0;
 int Wptr_subtraction_blows = 0;
 int Wreturn_void = 0;
 int Wshadow = 0;
+int Wsizeof_bool = 1;
 int Wtransparent_union = 0;
 int Wtypesign = 0;
 int Wundef = 0;
@@ -438,6 +439,7 @@ static const struct warning {
{ "ptr-subtraction-blows", _subtraction_blows },
{ "return-void", _void },
{ "shadow",  },
+   { "sizeof-bool", _bool },
{ "transparent-union", _union },
{ "typesign",  },
{ "undef",  },
diff --git a/lib.h b/lib.h
index f09b338..f6cd9b4 100644
--- a/lib.h
+++ b/lib.h
@@ -120,6 +120,7 @@ extern int Wparen_string;
 extern int Wptr_subtraction_blows;
 extern int Wreturn_void;
 extern int Wshadow;
+extern int Wsizeof_bool;
 extern int Wtransparent_union;
 extern int Wtypesign;
 extern int Wundef;
diff --git a/sparse.1 b/sparse.1
index cd6be26..b7a5b5c 100644
--- a/sparse.1
+++ b/sparse.1
@@ -297,6 +297,15 @@ Such declarations can lead to error-prone code.
 Sparse does not issue these warnings by default.
 .
 .TP
+.B \-Wsizeof-bool
+Warn when checking the sizeof a _Bool.
+
+C99 does not specify the sizeof a _Bool.  gcc uses 1.
+
+Sparse issues these warnings by default.  To turn them off, use
+\fB\-Wno\-sizeof\-bool\fR.
+.
+.TP
 .B \-Wtransparent\-union
 Warn about any declaration using the GCC extension
 \fB__attribute__((transparent_union))\fR.
-- 
1.8.1.2.459.gbcd45b4.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / EC: Clear stale EC events on Samsung systems

[Li Guang]

Juan Manuel Cabo wrote:


   

that's really nasty EC firmware!
 

Yes!
And this bug has been unsolved for about two years.

   

20 is enough?
the query index is length of a byte.

 

According to our humble tests, 8 is the maximum number of
accumulated events. For instance, if the one plugs or unplugs the PSU
16 times, (or battery % changes 16 times) during S3 sleep, then the
EC returns no more than 8 events when polled by this patch or by
my userspace util.
And having reached 8 events, it won't produce its GPE until queried.
   


that surely indicts their EC firmware only queued 8 events,

   

the query index is length of a byte.
 

There is no query index, unless you refer to something else (I'm sorry if its
something that escapes me).
   


oh, sorry, I'm referring internal EC firmware code
for Q event queuing, not ACPI SPEC, ;-)
for machine you tested, 8 is the queue size,
but for some unknown also nasty EC firmwares(let's suppose it exists),
it may queue more Q events.
and I saw several firmwares queued 32 events by default,
then, let's say, they be used for some samsung products,
and also they also forgot to deal with sleep/resume state,
then, we'll also leave stale Q event there.

Thanks!


 For us, a query is just: send 0x84 through EC CMD port, and read status
from CMD port and event type from EC DATA port. This is done with
the usual ec.c functions that would handle a query after a GPE interrupt,
but using them instead to poll (not GPE initiated) at awake. The EC would
then return status without 0x20 mask and 'event type'==0 when no more left.

--
Juan Manuel Cabo



   

   enum {
   EC_FLAGS_QUERY_PENDING,/* Query is pending */
@@ -116,6 +118,7 @@ EXPORT_SYMBOL(first_ec);
   static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
   static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
   static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT scan 
*/
+static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on boot/resume */

   

seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
seems too long :-)

 

   /* --
Transaction Management
@@ -440,6 +443,26 @@ acpi_handle ec_get_handle(void)

   EXPORT_SYMBOL(ec_get_handle);

+static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data);
+
+/* run with locked ec mutex */
+static void acpi_ec_clear(struct acpi_ec *ec)
+{
+int i, status;
+u8 value = 0;
+
+for (i = 0; i<   ACPI_EC_CLEAR_MAX; i++) {
+status = acpi_ec_query_unlocked(ec,);
+if (status || !value)
+break;
+}
+
+if (i == ACPI_EC_CLEAR_MAX)
+pr_warn("Warning: Maximum of %d stale EC events cleared\n", i);
+else
+pr_info("%d stale EC events cleared\n", i);
+}
+
   void acpi_ec_block_transactions(void)
   {
   struct acpi_ec *ec = first_ec;
@@ -463,6 +486,10 @@ void acpi_ec_unblock_transactions(void)
   mutex_lock(>mutex);
   /* Allow transactions to be carried out again */
   clear_bit(EC_FLAGS_BLOCKED,>flags);
+
+if (EC_FLAGS_CLEAR_ON_RESUME)
+acpi_ec_clear(ec);
+
   mutex_unlock(>mutex);
   }

@@ -821,6 +848,13 @@ static int acpi_ec_add(struct acpi_device *device)

   /* EC is fully operational, allow queries */
   clear_bit(EC_FLAGS_QUERY_PENDING,>flags);
+
+/* Some hardware may need the EC to be cleared before use */

   

description is implicit, should specify what we clear is Q event, not EC.

Thanks!
Li Guang

 

+if (EC_FLAGS_CLEAR_ON_RESUME) {
+mutex_lock(>mutex);
+acpi_ec_clear(ec);
+mutex_unlock(>mutex);
+}
   return ret;
   }

@@ -922,6 +956,30 @@ static int ec_enlarge_storm_threshold(const struct 
dmi_system_id *id)
   return 0;
   }

+/*
+ * On some hardware it is necessary to clear events accumulated by the EC 
during
+ * sleep. These ECs stop reporting GPEs until they are manually polled, if too
+ * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
+ *
+ * https://bugzilla.kernel.org/show_bug.cgi?id=44161
+ *
+ * Ideally, the EC should also be instructed not to accumulate events during
+ * sleep (which Windows seems to do somehow), but the interface to control this
+ * behaviour is not known at this time.
+ *
+ * Models known to be affected are Samsung 530Uxx/535Uxx/540Uxx/550Pxx/900Xxx,
+ * however it is very likely that other Samsung models are affected.
+ *
+ * On systems which don't accumulate EC events during sleep, this extra check
+ * should be harmless.
+ */
+static int ec_clear_on_resume(const struct dmi_system_id *id)
+{
+pr_debug("Detected system needing EC poll on resume.\n");
+EC_FLAGS_CLEAR_ON_RESUME = 1;
+return 0;
+}
+
   static struct dmi_system_id ec_dmi_table[] __initdata = {
   {
   ec_skip_dsdt_scan, "Compal JFL92", {
@@ -965,6 +1023,9 @@ static struct 

[GIT PULL v3] liblockdep fixes for v3.14

[Sasha Levin]

The following changes since commit 38dbfb59d1175ef458d006556061adeaa8751b72:

  Linus 3.14-rc1 (2014-02-02 16:42:13 -0800)

are available in the git repository at:

  https://github.com/sashalevin/liblockdep.git liblockdep-fixes

for you to fetch changes up to 7b8853419d3344b06cff64b4dc926805698eeba5:

  tools/liblockdep: Use realpath for srctree and objtree (2014-02-26 21:22:01 
-0500)


Ira W. Snyder (3):
  tools/liblockdep: Fix initialization code path
  tools/liblockdep: Fix include of asm/hash.h
  tools/liblockdep: Add include directory to allow tests to compile

Sasha Levin (2):
  tools/liblockdep: Mark runtests.sh as executable
  tools/liblockdep: Add a stub for new rcu_is_watching

Wang Nan (1):
  tools/liblockdep: Use realpath for srctree and objtree

 tools/lib/lockdep/Makefile | 6 +++---
 tools/lib/lockdep/preload.c| 2 +-
 tools/lib/lockdep/run_tests.sh | 0
 tools/lib/lockdep/uinclude/asm/hash.h  | 6 ++
 tools/lib/lockdep/uinclude/linux/rcu.h | 5 +
 5 files changed, 15 insertions(+), 4 deletions(-)
 mode change 100644 => 100755 tools/lib/lockdep/run_tests.sh
 create mode 100644 tools/lib/lockdep/uinclude/asm/hash.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFA][PATCH 3/4] tracing/module: Remove include of tracepoint.h from module.h

[Steven Rostedt]

On Wed, 26 Feb 2014 14:01:43 -0500
Steven Rostedt  wrote:

> [ Request for Ack ]
> 
> From: "Steven Rostedt (Red Hat)" 
> 
> There's nothing in the module.h header that requires tracepoint.h to be
> included. Soon, tracepoint.h will require struct module, and will have to
> include module.h. To avoid include hell, we need to remove the include of
> tracepoint.h from module.h.
> 
> A stable patch will require this change, so include stable in the Cc.
> 
> Cc: sta...@vger.kernel.org # 2.6.31+

Hi Rusty,

This patch doesn't need to be stable, and can wait till v3.15. But I
have other patches that will break with this patch (headers that needed
to include tracepoint.h and not depend on a header chain to include it).

Can you give me your Acked-by for this, and I'll just add it to my 3.15
queue?

Thanks,

-- Steve


> Cc: Rusty Russell 
> Signed-off-by: Steven Rostedt 
> ---
>  include/linux/module.h | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/include/linux/module.h b/include/linux/module.h
> index eaf60ff..6cc28d9 100644
> --- a/include/linux/module.h
> +++ b/include/linux/module.h
> @@ -15,7 +15,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Regression with wait_event_timeout in next-20140226

[Stephen Rothwell]

Hi Peter,

On Wed, 26 Feb 2014 17:50:43 +0100 Peter Zijlstra  wrote:
>
> On Wed, Feb 26, 2014 at 05:35:19PM +0100, Gregory CLEMENT wrote:
> > 
> > while testing next-20140226 I got an issue with the function
> > wait_event_timeout. When this function timed out instead of returning
> > 0, it returned the value of the timeout passed in parameter. I found
> > that reverting "sched/wait: Suppress Sparse 'variable shadowing'
> > warning" fixed this regression.
> > 
> > I got this issue in the driver drivers/i2c/busses/i2c-mv64xxx.c.
> 
> Ah indeed. We actually rely on the shadowing for ___wait_cond_timeout().
> 
> We further used the __ret variable in __wait_event_timeout()'s cmd
> argument: __ret = schedule_timeout(__ret). That now explicitly uses the
> wrong __ret.
> 
> Yeah, we need to pull that patch.

I have reverted that commit from linux-next for today pending some other
resolution.

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


pgpnT4SzjFsOC.pgp
Description: PGP signature

Re: [PATCH net] vhost: net: switch to use data copy if pending DMAs exceed the limit

[Jason Wang]

On 02/26/2014 05:23 PM, Michael S. Tsirkin wrote:
> On Wed, Feb 26, 2014 at 03:11:21PM +0800, Jason Wang wrote:
>> > On 02/26/2014 02:32 PM, Qin Chuanyu wrote:
>>> > >On 2014/2/26 13:53, Jason Wang wrote:
 > >>On 02/25/2014 09:57 PM, Michael S. Tsirkin wrote:
> > >>>On Tue, Feb 25, 2014 at 02:53:58PM +0800, Jason Wang wrote:
>> > We used to stop the handling of tx when the number of pending DMAs
>> > exceeds VHOST_MAX_PEND. This is used to reduce the memory 
>> > occupation
>> > of both host and guest. But it was too aggressive in some cases, 
>> > since
>> > any delay or blocking of a single packet may delay or block the 
>> > guest
>> > transmission. Consider the following setup:
>> > 
>> >  +-++-+
>> >  | VM1 || VM2 |
>> >  +--+--++--+--+
>> > |  |
>> >  +--+--++--+--+
>> >  | tap0|| tap1|
>> >  +--+--++--+--+
>> > |  |
>> >  pfifo_fast   htb(10Mbit/s)
>> > |  |
>> >  +--+--+---+
>> >  | bridge  |
>> >  +--+--+
>> > |
>> >  pfifo_fast
>> > |
>> >  +-+
>> >  | eth0|(100Mbit/s)
>> >  +-+
>> > 
>> > - start two VMs and connect them to a bridge
>> > - add an physical card (100Mbit/s) to that bridge
>> > - setup htb on tap1 and limit its throughput to 10Mbit/s
>> > - run two netperfs in the same time, one is from VM1 to VM2.
>> > Another is
>> >    from VM1 to an external host through eth0.
>> > - result shows that not only the VM1 to VM2 traffic were throttled 
>> > but
>> >    also the VM1 to external host through eth0 is also
>> > throttled somehow.
>> > 
>> > This is because the delay added by htb may lead the delay the 
>> > finish
>> > of DMAs and cause the pending DMAs for tap0 exceeds the limit
>> > (VHOST_MAX_PEND). In this case vhost stop handling tx request until
>> > htb send some packets. The problem here is all of the packets
>> > transmission were blocked even if it does not go to VM2.
>> > 
>> > We can solve this issue by relaxing it a little bit: switching to 
>> > use
>> > data copy instead of stopping tx when the number of pending DMAs
>> > exceed the VHOST_MAX_PEND. This is safe because:
>> > 
>> > - The number of pending DMAs were still limited by VHOST_MAX_PEND
>> > - The out of order completion during mode switch can make sure that
>> >    most of the tx buffers were freed in time in guest.
>> > 
>> > So even if about 50% packets were delayed in zero-copy case, vhost
>> > could continue to do the transmission through data copy in this 
>> > case.
>> > 
>> > Test result:
>> > 
>> > Before this patch:
>> > VM1 to VM2 throughput is 9.3Mbit/s
>> > VM1 to External throughput is 40Mbit/s
>> > 
>> > After this patch:
>> > VM1 to VM2 throughput is 9.3Mbit/s
>> > Vm1 to External throughput is 93Mbit/s
> > >>>Would like to see CPU utilization #s as well.
> > >>>
 > >>
 > >>Will measure this.
>> > Simple performance test on 40gbe shows no obvious changes in
>> > throughput after this patch.
>> > 
>> > The patch only solve this issue when unlimited sndbuf. We still 
>> > need a
>> > solution for limited sndbuf.
>> > 
>> > Cc: Michael S. Tsirkin
>> > Cc: Qin Chuanyu
>> > Signed-off-by: Jason Wang
> > >>>I think this needs some thought.
> > >>>
> > >>>In particular I think this works because VHOST_MAX_PEND
> > >>>is much smaller than the ring size.
> > >>>Shouldn't max_pend then be tied to the ring size if it's small?
> > >>>
 > >>
 > >>Yes it should. I just reuse the VHOST_MAX_PEND since it was there for a
 > >>long time.
> > >>>Another question is about stopping vhost:
> > >>>ATM it's waiting for skbs to complete.
> > >>>Should we maybe hunt down skbs queued and destroy them
> > >>>instead?
> > >>>I think this happens when a device is removed.
> > >>>
> > >>>Thoughts?
> > >>>
 > >>
 > >>Agree, vhost net removal should not be blocked by a skb. But since the
 > >>skbs could be queued may places, just destroy them may need extra 
 > >>locks.
 > >>
 > >>Haven't thought this deeply, but another possible sloution is to rcuify
 > >>destructor_arg and assign it to NULL during vhost_net removing.
>>> > >
>>> > >Xen treat it by a timer, 

Re: [ANNOUNCE] 3.12.12-rt19

[Steven Rostedt]

On Mon, 24 Feb 2014 02:55:20 +0400
Pavel Vasilyev  wrote:

> No, because in positional number systems, an increase in the senior level,
> junior reset, but not stays the same. Mainline kernel and patches is senior 
> level.

If you notice, there's no '.' between the mainline version and the rt
version. It's a dash "-rtX". What that number represents is the version
of the patch series for that release. We don't start a new version at
each stable release, but we do start a new one at each major release.

Thus, -rt19 is the 19th version of this rt patch series. When we rebase
on top of another major release, a lot of rewrites need to be done, and
we start a new version series.

Resetting the -rt number at each minor release would not be useful to
us and thus not necessary.

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

Re: [PATCH V2] sparse: Allow override of sizeof(bool) warning

[Josh Triplett]

On Wed, Feb 26, 2014 at 06:53:14PM -0800, Joe Perches wrote:
> Allow an override to emit or not the sizeof(bool) warning
> Add a description to the manpage.
> 
> Signed-off-by: Joe Perches 

Reviewed-by: Josh Triplett 

>  evaluate.c | 3 ++-
>  lib.c  | 2 ++
>  lib.h  | 1 +
>  sparse.1   | 9 +
>  4 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/evaluate.c b/evaluate.c
> index 6655615..a45f59b 100644
> --- a/evaluate.c
> +++ b/evaluate.c
> @@ -2057,7 +2057,8 @@ static struct symbol *evaluate_sizeof(struct expression 
> *expr)
>   }
>  
>   if (size == 1 && is_bool_type(type)) {
> - warning(expr->pos, "expression using sizeof bool");
> + if (Wsizeof_bool)
> + warning(expr->pos, "expression using sizeof bool");
>   size = bits_in_char;
>   }
>  
> diff --git a/lib.c b/lib.c
> index bf3e91c..676b72e 100644
> --- a/lib.c
> +++ b/lib.c
> @@ -225,6 +225,7 @@ int Wone_bit_signed_bitfield = 1;
>  int Wparen_string = 0;
>  int Wptr_subtraction_blows = 0;
>  int Wreturn_void = 0;
> +int Wsizeof_bool = 1;
>  int Wshadow = 0;
>  int Wtransparent_union = 0;
>  int Wtypesign = 0;
> @@ -437,6 +438,7 @@ static const struct warning {
>   { "paren-string", _string },
>   { "ptr-subtraction-blows", _subtraction_blows },
>   { "return-void", _void },
> + { "sizeof-bool", _bool },
>   { "shadow",  },
>   { "transparent-union", _union },
>   { "typesign",  },
> diff --git a/lib.h b/lib.h
> index f09b338..7e3432f 100644
> --- a/lib.h
> +++ b/lib.h
> @@ -119,6 +119,7 @@ extern int Wone_bit_signed_bitfield;
>  extern int Wparen_string;
>  extern int Wptr_subtraction_blows;
>  extern int Wreturn_void;
> +extern int Wsizeof_bool;
>  extern int Wshadow;
>  extern int Wtransparent_union;
>  extern int Wtypesign;
> diff --git a/sparse.1 b/sparse.1
> index cd6be26..b4546be 100644
> --- a/sparse.1
> +++ b/sparse.1
> @@ -288,6 +288,15 @@ programs consider this poor style, and those programs 
> can use
>  Sparse does not issue these warnings by default.
>  .
>  .TP
> +.B \-Wsizeof-bool
> +Warn when checking the sizeof a _Bool.
> +
> +C99 does not specify the sizeof a _Bool.  gcc uses 1.
> +
> +Sparse issues these warnings by default.  To turn them off, use
> +\fB\-Wno\-sizeof\-bool\fR.
> +.
> +.TP
>  .B \-Wshadow
>  Warn when declaring a symbol which shadows a declaration with the same name 
> in
>  an outer scope.
> -- 
> 1.8.1.2.459.gbcd45b4.dirty
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sparse" 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: A Bug Inquiry in linux/tools/perf/builtin-record.c

[xiakaixu]

Hi Namhyung,

于 2014/2/26 16:03, Namhyung Kim 写道:
> Hi xiakaixu,
> 
>> 于 2014/2/19 9:48, xiakaixu 写道:
>>> Hi all,
>>>
>>> There is a bug found in my work when running "perf record". The basic 
>>> information
>>> is here. As we know, perf record is a parent process and the programme 
>>> traced is
>>> a child process when running "perf record". Sometimes the child process 
>>> become
>>> zombie state and disappear until the parent process is killed. The bug 
>>> stays in linux/
>>> tools/perf/builtin-record.c.
>>> *
>>> static int __cmd_record(struct perf_record *rec, int argc, const char 
>>> **argv)
>>> ..
>>> if (hits == rec->samples) {
>>>  if (done)
>>>  break;
>>>  err = poll(evsel_list->pollfd, evsel_list->nr_fds, 
>>> -1);
>>>  waking++;
>>>  }
>>> ..
>>> *
>>> The parent process still call the function
>>> poll(evsel_list->pollfd, evsel_list->nr_fds, -1) when the child process has 
>>> exited
>>> already, which caused a zombie process.
>>>
>>> May I have your opinion ?
>>> Waiting for your reply!
> 
> Do you have a real bug report based on this?
yeah, of course we have it, I'll be glad to provide it if necessary.
> 
> AFAIK perf record installed a signal handler for SIGCHLD so it'll set
> the 'done' variable when child exits and then break the loop.
yes, you are right. Though the 'done' varible will be set when child exits,
there is time gap between "if(done)" statement and "poll(...)" function.
The 'done' variable won't be judge when child exits in this time gap.
You know this time gap is instruction level, so this bug is small probability.
My solution is adding a while(...) statement outside poll(...) function.
>
> Thanks,
> Namhyung
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sparse: Allow override of sizeof(bool) warning

[Joe Perches]

Allow an override to emit or not the sizeof(bool) warning
Add a description to the manpage.

Signed-off-by: Joe Perches 
---
 evaluate.c | 3 ++-
 lib.c  | 2 ++
 lib.h  | 1 +
 sparse.1   | 9 +
 4 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/evaluate.c b/evaluate.c
index 6655615..a45f59b 100644
--- a/evaluate.c
+++ b/evaluate.c
@@ -2057,7 +2057,8 @@ static struct symbol *evaluate_sizeof(struct expression 
*expr)
}
 
if (size == 1 && is_bool_type(type)) {
-   warning(expr->pos, "expression using sizeof bool");
+   if (Wsizeof_bool)
+   warning(expr->pos, "expression using sizeof bool");
size = bits_in_char;
}
 
diff --git a/lib.c b/lib.c
index bf3e91c..676b72e 100644
--- a/lib.c
+++ b/lib.c
@@ -225,6 +225,7 @@ int Wone_bit_signed_bitfield = 1;
 int Wparen_string = 0;
 int Wptr_subtraction_blows = 0;
 int Wreturn_void = 0;
+int Wsizeof_bool = 1;
 int Wshadow = 0;
 int Wtransparent_union = 0;
 int Wtypesign = 0;
@@ -437,6 +438,7 @@ static const struct warning {
{ "paren-string", _string },
{ "ptr-subtraction-blows", _subtraction_blows },
{ "return-void", _void },
+   { "sizeof-bool", _bool },
{ "shadow",  },
{ "transparent-union", _union },
{ "typesign",  },
diff --git a/lib.h b/lib.h
index f09b338..7e3432f 100644
--- a/lib.h
+++ b/lib.h
@@ -119,6 +119,7 @@ extern int Wone_bit_signed_bitfield;
 extern int Wparen_string;
 extern int Wptr_subtraction_blows;
 extern int Wreturn_void;
+extern int Wsizeof_bool;
 extern int Wshadow;
 extern int Wtransparent_union;
 extern int Wtypesign;
diff --git a/sparse.1 b/sparse.1
index cd6be26..b4546be 100644
--- a/sparse.1
+++ b/sparse.1
@@ -288,6 +288,15 @@ programs consider this poor style, and those programs can 
use
 Sparse does not issue these warnings by default.
 .
 .TP
+.B \-Wsizeof-bool
+Warn when checking the sizeof a _Bool.
+
+C99 does not specify the sizeof a _Bool.  gcc uses 1.
+
+Sparse issues these warnings by default.  To turn them off, use
+\fB\-Wno\-sizeof\-bool\fR.
+.
+.TP
 .B \-Wshadow
 Warn when declaring a symbol which shadows a declaration with the same name in
 an outer scope.
-- 
1.8.1.2.459.gbcd45b4.dirty



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv9 Resend 4/4] Documentation: Add device tree bindings for Freescale FTM PWM.

[li.xi...@freescale.com]

> >  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> >
> > diff --git a/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> b/Documentation/devicetree/bindings/pwm/pwm-fsl-ftm.txt
> [...]
> > +- clocks : Must contain a clock specifier for each entry in clock-names,
> 
> Nit: A slightly more correct way to say this would be: "Must contain a
> phandle and clock specifier...".
> 

Yes, I will fix this.

Thanks very much,

--
Best Regards,
Xiubo

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -mm] memcg: reparent only LRUs during mem_cgroup_css_offline

[Hugh Dickins]

On Wed, 19 Feb 2014, Michal Hocko wrote:

> css_offline callback exported by the cgroup core is not intended to get
> rid of all the charges but rather to get rid of cached charges for the
> soon destruction. For the memory controller we have 2 different types of
> "cached" charges which prevent from the memcg destruction (because they
> pin memcg by css reference). Swapped out pages (when swap accounting is
> enabled) and kmem charges. None of them are dealt with in the current
> code.
> 
> What we do instead is that we are reducing res counter charges (reduced
> by kmem charges) to 0. And this hard down-to-0 requirement has led to
> several issues in the past when the css_offline loops without any way
> out e.g. memcg: reparent charges of children before processing parent.
> 
> The important thing is that we actually do not have to drop all the
> charges. Instead we want to reduce LRU pages (which do not pin memcg) as
> much as possible because they are not reachable by memcg iterators after
> css_offline code returns, thus they are not reclaimable anymore.

That worries me.

> 
> This patch simply extracts LRU reparenting into mem_cgroup_reparent_lrus
> which doesn't care about charges and it is called from css_offline
> callback and the original mem_cgroup_reparent_charges stays in
> css_offline callback. The original workaround for the endless loop is no
> longer necessary because child vs. parent ordering is no longer and
> issue. The only requirement is that the parent has be still online at
> the time of css_offline.

But isn't that precisely what we just found is not guaranteed?
And in fact your patch has the necessary loop up to find the
first ancestor it can successfully css_tryget.  Maybe you meant
to say "still there" rather than "still online".

(Tangential, I don't think you rely on this any more than we do
at present, and I may be wrong to suggest any problem: but I would
feel more comfortable if kernel/cgroup.c's css_free_work_fn() did
parent = css->parent; css->ss->css_free(css); css_put(parent);
instead of putting the parent before freeing the child.)

> mem_cgroup_reparent_charges also doesn't have to exclude kmem charges
> because there shouldn't be any at the css_free stage. Let's add BUG_ON
> to make sure we haven't screwed anything.
> 
> mem_cgroup_reparent_lrus is racy but this is tolerable as the inflight
> pages which will eventually get back to the memcg's LRU shouldn't
> constitute a lot of memory.
> 
> Signed-off-by: Michal Hocko 
> ---
> This is on top of 
> memcg-reparent-charges-of-children-before-processing-parent.patch
> and I am not suggesting to replace it (I think Filipe's patch is more
> appropriate for the stable tree).
> Nevertheless I find this approach slightly better because it makes
> semantical difference between offline and free more obvious and we can
> build on top of it later (when offlining is no longer synchronized by
> cgroup_mutex). But if you think that it is not worth touching this area
> until we find a good way to reparent swapped out and kmem pages then I
> am OK with it and stay with Filipe's patch.

I'm ambivalent about it.  I like it, and I like very much that the loop
waiting for RES_USAGE to go down to 0 is without cgroup_mutex held; but
I dislike that any pages temporarily off LRU at the time of css_offline's
list_empty check, will then go AWOL (unreachable by reclaim), until
css_free later gets around to reparenting them.

It's conceivable that some code could be added to mem_cgroup_page_lruvec()
(near my "Surreptitiously" comment), to reparent when they're put back on
LRU; but more probably not, that's already tricky, and probably bad to
make it any trickier, even if it turned out to be possible.

So I'm inclined to wait until the swap and kmem situation is sorted out
(when the delay between offline and free should become much briefer);
but would be happy if you found a good way to make the missing pages
reclaimable in the meantime.

A couple of un-comments below.

Hugh

> 
>  mm/memcontrol.c | 102 
> ++--
>  1 file changed, 55 insertions(+), 47 deletions(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 45c2a50954ac..9f8e54333b60 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3870,6 +3870,7 @@ out:
>   * @page: the page to move
>   * @pc: page_cgroup of the page
>   * @child: page's cgroup
> + * @parent: parent where to reparent
>   *
>   * move charges to its parent or the root cgroup if the group has no
>   * parent (aka use_hierarchy==0).
> @@ -3888,9 +3889,9 @@ out:
>   */
>  static int mem_cgroup_move_parent(struct page *page,
> struct page_cgroup *pc,
> -   struct mem_cgroup *child)
> +   struct mem_cgroup *child,
> +   struct mem_cgroup *parent)
>  {
> - struct mem_cgroup *parent;
>   unsigned int nr_pages;
>   unsigned long 

[ANNOUNCE] 3.2.55-rt78

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.2.55-rt78 stable release.


This release is just an update to the new stable 3.2.55 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.2-rt
  Head SHA1: bb9d84236c5dd8755164743d91722b54d8f0f77e


Or to build 3.2.55-rt78 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.2.55.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.2/patch-3.2.55-rt78.patch.xz




Enjoy,

-- Steve

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

[ANNOUNCE] 3.4.82-rt100

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.4.82-rt100 stable release.


This release is just an update to the new stable 3.4.82 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.4-rt
  Head SHA1: da3bf49cb8e7000e26cb1df0ea208ed707e8cd7a


Or to build 3.4.82-rt100 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.4.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.4.82.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.4/patch-3.4.82-rt100.patch.xz




Enjoy,

-- Steve

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

[ANNOUNCE] 3.10.32-rt30

[Steven Rostedt]

Dear RT Folks,

I'm pleased to announce the 3.10.32-rt30 stable release.


This release is just an update to the new stable 3.10.32 version
and no RT specific changes have been made.


You can get this release via the git tree at:

  git://git.kernel.org/pub/scm/linux/kernel/git/rt/linux-stable-rt.git

  branch: v3.10-rt
  Head SHA1: 28685212b4e434475532a76d9c82a4ecb8786356


Or to build 3.10.32-rt30 directly, the following patches should be applied:

  http://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.tar.xz

  http://www.kernel.org/pub/linux/kernel/v3.x/patch-3.10.32.xz

  
http://www.kernel.org/pub/linux/kernel/projects/rt/3.10/patch-3.10.32-rt30.patch.xz




Enjoy,

-- Steve

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

[PATCH] ASoC: io: Clean up snd_soc_codec_set_cache_io()

[Xiubo Li]

Now that all users have been converted to regmap and the config.reg_bits
and config.val_bits can be setted by each user through regmap core API.
So these two params are redundant here.

Signed-off-by: Xiubo Li 
---

@Mark and All

I'm also thinking could we just discard snd_soc_codec_set_cache_io()
calling from each individual driver to simply the code? And just bind
it to devm_regmap_init_i2c() and devm_regmap_init_spi()...

Is there any other limitations for snd_soc_codec_set_cache_io() usage?





 include/sound/soc.h  | 1 -
 sound/soc/codecs/ad193x.c| 2 +-
 sound/soc/codecs/adau1373.c  | 2 +-
 sound/soc/codecs/adav80x.c   | 2 +-
 sound/soc/codecs/ak4535.c| 2 +-
 sound/soc/codecs/ak4641.c| 2 +-
 sound/soc/codecs/ak4642.c| 2 +-
 sound/soc/codecs/ak4671.c| 2 +-
 sound/soc/codecs/alc5623.c   | 2 +-
 sound/soc/codecs/alc5632.c   | 2 +-
 sound/soc/codecs/cq93vc.c| 2 +-
 sound/soc/codecs/cs4270.c| 2 +-
 sound/soc/codecs/cs42l51.c   | 2 +-
 sound/soc/codecs/cs42l52.c   | 2 +-
 sound/soc/codecs/cs42l73.c   | 2 +-
 sound/soc/codecs/da7210.c| 2 +-
 sound/soc/codecs/da7213.c| 2 +-
 sound/soc/codecs/da732x.c| 2 +-
 sound/soc/codecs/da9055.c| 2 +-
 sound/soc/codecs/isabelle.c  | 2 +-
 sound/soc/codecs/lm49453.c   | 2 +-
 sound/soc/codecs/max9768.c   | 2 +-
 sound/soc/codecs/max98088.c  | 2 +-
 sound/soc/codecs/max98090.c  | 2 +-
 sound/soc/codecs/max98095.c  | 2 +-
 sound/soc/codecs/max9850.c   | 2 +-
 sound/soc/codecs/mc13783.c   | 2 +-
 sound/soc/codecs/ml26124.c   | 2 +-
 sound/soc/codecs/rt5631.c| 2 +-
 sound/soc/codecs/rt5640.c| 2 +-
 sound/soc/codecs/sgtl5000.c  | 2 +-
 sound/soc/codecs/sn95031.c   | 2 +-
 sound/soc/codecs/ssm2518.c   | 2 +-
 sound/soc/codecs/ssm2602.c   | 2 +-
 sound/soc/codecs/sta32x.c| 2 +-
 sound/soc/codecs/sta529.c| 2 +-
 sound/soc/codecs/tlv320aic23.c   | 2 +-
 sound/soc/codecs/tlv320aic26.c   | 2 +-
 sound/soc/codecs/tlv320aic32x4.c | 2 +-
 sound/soc/codecs/tlv320aic3x.c   | 2 +-
 sound/soc/codecs/wm2000.c| 2 +-
 sound/soc/codecs/wm2200.c| 2 +-
 sound/soc/codecs/wm5100.c| 2 +-
 sound/soc/codecs/wm5102.c| 2 +-
 sound/soc/codecs/wm5110.c| 2 +-
 sound/soc/codecs/wm8350.c| 2 +-
 sound/soc/codecs/wm8400.c| 2 +-
 sound/soc/codecs/wm8510.c| 2 +-
 sound/soc/codecs/wm8523.c| 2 +-
 sound/soc/codecs/wm8580.c| 2 +-
 sound/soc/codecs/wm8711.c| 2 +-
 sound/soc/codecs/wm8728.c| 2 +-
 sound/soc/codecs/wm8731.c| 2 +-
 sound/soc/codecs/wm8737.c| 2 +-
 sound/soc/codecs/wm8741.c| 2 +-
 sound/soc/codecs/wm8750.c| 2 +-
 sound/soc/codecs/wm8753.c| 2 +-
 sound/soc/codecs/wm8770.c| 2 +-
 sound/soc/codecs/wm8776.c| 2 +-
 sound/soc/codecs/wm8804.c| 2 +-
 sound/soc/codecs/wm8900.c| 2 +-
 sound/soc/codecs/wm8903.c| 2 +-
 sound/soc/codecs/wm8904.c| 2 +-
 sound/soc/codecs/wm8940.c| 2 +-
 sound/soc/codecs/wm8955.c| 2 +-
 sound/soc/codecs/wm8960.c| 2 +-
 sound/soc/codecs/wm8961.c| 2 +-
 sound/soc/codecs/wm8962.c| 2 +-
 sound/soc/codecs/wm8971.c| 2 +-
 sound/soc/codecs/wm8974.c| 2 +-
 sound/soc/codecs/wm8978.c| 2 +-
 sound/soc/codecs/wm8983.c| 2 +-
 sound/soc/codecs/wm8985.c| 2 +-
 sound/soc/codecs/wm8988.c| 2 +-
 sound/soc/codecs/wm8990.c| 2 +-
 sound/soc/codecs/wm8991.c| 2 +-
 sound/soc/codecs/wm8993.c| 2 +-
 sound/soc/codecs/wm8994.c| 2 +-
 sound/soc/codecs/wm8995.c| 2 +-
 sound/soc/codecs/wm8996.c| 2 +-
 sound/soc/codecs/wm8997.c| 2 +-
 sound/soc/codecs/wm9081.c| 2 +-
 sound/soc/codecs/wm9090.c| 2 +-
 sound/soc/soc-core.c | 2 +-
 sound/soc/soc-io.c   | 9 -
 85 files changed, 83 insertions(+), 93 deletions(-)

diff --git a/include/sound/soc.h b/include/sound/soc.h
index ecfb334..0a1d732 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -404,7 +404,6 @@ int snd_soc_codec_readable_register(struct snd_soc_codec 
*codec,
 int snd_soc_codec_writable_register(struct snd_soc_codec *codec,
unsigned int reg);
 int snd_soc_codec_set_cache_io(struct snd_soc_codec *codec,
-  int addr_bits, int data_bits,
   enum snd_soc_control_type control);
 int snd_soc_cache_sync(struct snd_soc_codec *codec);
 int snd_soc_cache_init(struct snd_soc_codec *codec);
diff --git a/sound/soc/codecs/ad193x.c b/sound/soc/codecs/ad193x.c
index 9381a76..052495f 100644
--- a/sound/soc/codecs/ad193x.c
+++ b/sound/soc/codecs/ad193x.c
@@ -325,7 +325,7 @@ static int ad193x_codec_probe(struct snd_soc_codec *codec)
int ret;
 
codec->control_data = ad193x->regmap;
- 

Re: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint code

[Steven Rostedt]

On Thu, 27 Feb 2014 02:21:16 + (UTC)
Mathieu Desnoyers  wrote:


> That is not the question. We don't care about how many times module.h is
> included in the kernel, but rather what module.h itself includes and could
> include in the future, throughout generic and arch-specific headers. If
> someone want to add a tracepoint in a static inline function located within
> a header file, they will need to include tracepoint.h. If tracepoint.h
> happens to have a circular dependency on this header, there comes include
> hell.

Actually, we've been telling people not to do that. That is, we don't
allow for tracepoints to be in headers anymore. We've removed all of
the offenders.

> 
> Arguing that it's OK to include headers within core instrumentation code
> because they are themselves included pretty much everywhere is a paved way
> to said include hell IMHO.

I find tracepoint.h far from a core instrumentation code. It's for
static tracepoints only. It's not like rcu or spinlock. It's about as
core as module.h is. I would argue that module.h is an even more core
header than tracepoint.h.


> > 
> > But as a compromise, I can move it to ftrace_event.h instead.
> 
> Since it will be used in tracepoint.c as well, which is a foundation of
> ftrace_event, it would be bad coupling to make tracepoint.c include
> ftrace_event.h (abstraction inversion). So I still think tracepoint.h
> is the right place to put this, only not with the module.h dependency.
> 
> But perhaps I'm missing something. Why is it so important to you to make
> this a static inline rather than a regular function call ?

As it is a one liner check, it just seemed to fit as a static inline.
As this isn't in any fast path, I guess I could make it a normal
function call.

Fine, I'll do that instead. Then the module header change can go into
linux-next instead of mainline/stable.

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

Re: [PATCH] s390: select CONFIG_TTY for use of tty in unconditional keyboard driver

[Stephen Rothwell]

Hi Josh,

On Wed, 26 Feb 2014 18:13:06 -0800 Josh Triplett  wrote:
>
> The unconditionally built keyboard driver, drivers/s390/char/keyboard.c,
> requires CONFIG_TTY, so select it from CONFIG_S390 to prevent a build
> error.
> 
> Signed-off-by: Josh Triplett 

Will be added to linux-next today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpAdczAV07o6.pgp
Description: PGP signature

Re: linux-next: build failure after merge of the final tree (akpm-current tree related)

[Stephen Rothwell]

Hi Josh,

On Wed, 26 Feb 2014 18:21:29 -0800 Josh Triplett  wrote:
>
> On Thu, Feb 27, 2014 at 10:00:26AM +1100, Stephen Rothwell wrote:
> > Please check the build results overnight tonight (for next-20140227 at
> > http://kisskb.ellerman.id.au/linux-next) and submit any more fixes for
> > the allnoconfig build errors.
> 
> Checking that site, I don't see any other instances of failures caused
> by allnoconfig.  If I'm missing some, could you please point me to the
> page on that site I'm missing?

That is because your patch was reverted in yesterday's (next-20140226)
linux-next.  You will need to look tomorrow (next-20140227) sometime.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp9XrqaUaXyo.pgp
Description: PGP signature

[PATCH v3 net-next 1/1] bpf32->bpf64 mapper and bpf64 interpreter

[Alexei Starovoitov]

Extended BPF (or 64-bit BPF) is an instruction set to
create safe dynamically loadable filters that can call fixed set
of kernel functions and take generic bpf_context as an input.
BPF filter is a glue between kernel functions and bpf_context.
Different kernel subsystems can define their own set of available functions
and alter BPF machinery for specific use case.
BPF64 instruction set is designed for efficient mapping to native
instructions on 64-bit CPUs

Old BPF instructions are remapped on the fly to BPF64
when sysctl net.core.bpf64_enable=1

Signed-off-by: Alexei Starovoitov 
---
 include/linux/filter.h  |9 +-
 include/linux/netdevice.h   |1 +
 include/uapi/linux/filter.h |   37 ++-
 net/core/Makefile   |2 +-
 net/core/bpf_run.c  |  766 +++
 net/core/filter.c   |  114 ++-
 net/core/sysctl_net_core.c  |7 +
 7 files changed, 913 insertions(+), 23 deletions(-)
 create mode 100644 net/core/bpf_run.c

diff --git a/include/linux/filter.h b/include/linux/filter.h
index e568c8ef896b..bf3085258f4c 100644
--- a/include/linux/filter.h
+++ b/include/linux/filter.h
@@ -53,6 +53,13 @@ extern int sk_chk_filter(struct sock_filter *filter, 
unsigned int flen);
 extern int sk_get_filter(struct sock *sk, struct sock_filter __user *filter, 
unsigned len);
 extern void sk_decode_filter(struct sock_filter *filt, struct sock_filter *to);
 
+/* function remaps 'sock_filter' style insns to 'bpf_insn' style insns */
+int bpf_convert(struct sock_filter *fp, int len, struct bpf_insn *new_prog,
+   int *p_new_len);
+/* execute bpf64 program */
+u32 bpf_run(struct bpf_context *ctx, const struct bpf_insn *insn);
+
+#define SK_RUN_FILTER(FILTER, SKB) (*FILTER->bpf_func)(SKB, FILTER->insns)
 #ifdef CONFIG_BPF_JIT
 #include 
 #include 
@@ -70,7 +77,6 @@ static inline void bpf_jit_dump(unsigned int flen, unsigned 
int proglen,
print_hex_dump(KERN_ERR, "JIT code: ", DUMP_PREFIX_OFFSET,
   16, 1, image, proglen, false);
 }
-#define SK_RUN_FILTER(FILTER, SKB) (*FILTER->bpf_func)(SKB, FILTER->insns)
 #else
 #include 
 static inline void bpf_jit_compile(struct sk_filter *fp)
@@ -80,7 +86,6 @@ static inline void bpf_jit_free(struct sk_filter *fp)
 {
kfree(fp);
 }
-#define SK_RUN_FILTER(FILTER, SKB) sk_run_filter(SKB, FILTER->insns)
 #endif
 
 static inline int bpf_tell_extensions(void)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5e84483c0650..7b1acefc244e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -2971,6 +2971,7 @@ extern intnetdev_max_backlog;
 extern int netdev_tstamp_prequeue;
 extern int weight_p;
 extern int bpf_jit_enable;
+extern int bpf64_enable;
 
 bool netdev_has_upper_dev(struct net_device *dev, struct net_device 
*upper_dev);
 struct net_device *netdev_all_upper_get_next_dev_rcu(struct net_device *dev,
diff --git a/include/uapi/linux/filter.h b/include/uapi/linux/filter.h
index 8eb9ccaa5b48..70ff29ee6825 100644
--- a/include/uapi/linux/filter.h
+++ b/include/uapi/linux/filter.h
@@ -1,3 +1,4 @@
+/* extended BPF is Copyright (c) 2011-2014, PLUMgrid, http://plumgrid.com */
 /*
  * Linux Socket Filter Data Structures
  */
@@ -19,7 +20,7 @@
  * Try and keep these values and structures similar to BSD, especially
  * the BPF code definitions which need to match so you can share filters
  */
- 
+
 struct sock_filter {   /* Filter block */
__u16   code;   /* Actual filter code */
__u8jt; /* Jump true */
@@ -45,12 +46,26 @@ struct sock_fprog { /* Required for SO_ATTACH_FILTER. */
 #define BPF_JMP 0x05
 #define BPF_RET 0x06
 #define BPF_MISC0x07
+#define BPF_ALU64   0x07
+
+struct bpf_insn {
+   __u8code;/* opcode */
+   __u8a_reg:4; /* dest register*/
+   __u8x_reg:4; /* source register */
+   __s16   off; /* signed offset */
+   __s32   imm; /* signed immediate constant */
+};
+
+/* pointer to bpf_context is the first and only argument to BPF program
+ * its definition is use-case specific */
+struct bpf_context;
 
 /* ld/ldx fields */
 #define BPF_SIZE(code)  ((code) & 0x18)
 #define BPF_W   0x00
 #define BPF_H   0x08
 #define BPF_B   0x10
+#define BPF_DW  0x18
 #define BPF_MODE(code)  ((code) & 0xe0)
 #define BPF_IMM 0x00
 #define BPF_ABS 0x20
@@ -58,6 +73,7 @@ struct sock_fprog {   /* Required for SO_ATTACH_FILTER. */
 #define BPF_MEM 0x60
 #define BPF_LEN 0x80
 #define BPF_MSH 0xa0
+#define BPF_XADD0xc0 /* exclusive add */
 
 /* alu/jmp fields */
 #define BPF_OP(code)((code) & 0xf0)
@@ -68,16 +84,24 @@ struct sock_fprog { /* Required for SO_ATTACH_FILTER. */
 #define  

[PATCH v3 net-next 0/1] bpf32->bpf64 mapper and bpf64 interpreter

[Alexei Starovoitov]

Hi All,

V1 patches:
http://thread.gmane.org/gmane.linux.kernel/1605783
V2 patches:
http://thread.gmane.org/gmane.linux.kernel/1642325

V3 summary:
- as suggested by Daniel added on the fly converter from
  old BPF (aka BPF32) into extended BPF (aka BPF64)
- as suggested by Peter Anvin added 32-bit subregisters
  they don't add much to interpreter speed, but simplify bpf32->bpf64 mapping
- added sysctl net.core.bpf64_enable flag
  if enabled, old BPF filters will be converted to BPF64
  and will be used by tcpdump/cls/xtables.
  safety of the filters is verified by old BPF sk_chk_filter()
  BPF64's bpf_check() is dropped from this patch to simplify review

Addition of 32-bit subregs require some work on BPF64 x86_64 JIT, so
it's not included in this patch set. LLVM BPF64 backend also needs to be
taught to take advantage of 32-bit subregs.

Initially BPF64 instruction set was designed for max performance after JIT,
Now it was tweaked for good interpreter speeds as well.
Eventually BPF64 can completely replace existing BPF on all architectures.

Two key reasons why BPF64 interpreter is noticeably faster
than existing BPF32 interpreter:

1.fall-through jumps
  In BPF32 jump instructions are forced to go either 'true' or 'false'
  branch which causes branch-miss penalty.
  BPF64 jump instructions have one branch and fall-through, which fit
  CPU branch predictor logic better.
  'perf stat' shows drastic difference for branch-misses.

2.jump-threaded implementation of interpreter vs switch statement
  Instead of single tablejump at the top of 'switch' statement, GCC will
  generate multiple tablejump instructions, which helps CPU branch predictor

Performance of two BPF filters generated by libpcap was measured
on x86_64, i386 and arm32.

fprog #1 is taken from Documentation/networking/filter.txt:
tcpdump -i eth0 port 22 -dd

fprog #2 is taken from 'man tcpdump':
tcpdump -i eth0 'tcp port 22 and (((ip[2:2] - ((ip[0]&0xf)<<2)) - 
   ((tcp[12]&0xf0)>>2)) != 0)' -dd

Other libpcap programs have similar performance differences.

Raw performance data from BPF micro-benchmark:
SK_RUN_FILTER on same SKB (cache-hit) or 10k SKBs (cache-miss)
time in nsec per call, smaller is better
--x86_64--
fprog #1  fprog #1   fprog #2  fprog #2
cache-hit cache-miss cache-hit cache-miss
BPF32  9098   207   220
BPF64  2885   60108
BPF32_JIT  1233   17 44
BPF64_JIT  TBD

--i386--
fprog #1  fprog #1   fprog #2  fprog #2
cache-hit cache-miss cache-hit cache-miss
BPF32 107136  227   252
BPF64  40119   69   172

--arm32--
fprog #1  fprog #1   fprog #2  fprog #2
cache-hit cache-miss cache-hit cache-miss
BPF32 202300  475   540
BPF64 139270  296   470
BPF32_JIT  26182   37   202
BPF64_JIT TBD

on Intel cpus BPF64 interpreter is significantly faster than
old BPF interpreter. Existing BPF32_JIT is obviously even faster.
BPF64_JIT has similar performance.

Tested with Daniel's 'trinify BPF fuzzer'

TODO:
- bpf32->bpf64 converter doesn't recognize seccomp and negative
  offsets yet, fix that

- add 32-bit subregs to BPF64 x86_64 JIT and LLVM backend

- add bpf64 verifier, so that tcpdump/cls/xt and others can
  insert both bpf32 and bpf64 programs through the same interface

- add bpf tables, complete 'dropmonitor' and get back to
  systemtap-like probes with bpf64

Please review.
Thanks!

Alexei Starovoitov (1):
  bpf32->bpf64 mapper and bpf64 interpreter

 include/linux/filter.h  |9 +-
 include/linux/netdevice.h   |1 +
 include/uapi/linux/filter.h |   37 ++-
 net/core/Makefile   |2 +-
 net/core/bpf_run.c  |  766 +++
 net/core/filter.c   |  114 ++-
 net/core/sysctl_net_core.c  |7 +
 7 files changed, 913 insertions(+), 23 deletions(-)
 create mode 100644 net/core/bpf_run.c

-- 
1.7.9.5

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

Re: [RFC PATCH 1/6] PM / Voltagedomain: Add generic clk notifier handler for regulator based dynamic voltage scaling

[Nishanth Menon]

On 14:56-20140225, Nishanth Menon wrote:
> On 02/24/2014 11:51 PM, Mike Turquette wrote:
> > Quoting Nishanth Menon (2014-02-18 12:32:18)
[...]
> > I'm not sure about trying to capture the "voltdm" as a core concept. It
> > feels a bit unwieldy to me.
> 
> Considering it is a simple collation of regulators and SoC specific
> "magic" which have to be operated in tandem to clock operation, Why
> does it seem unwieldy? Usage of multiple voltage planes in a single
> voltage domain concept does not seem unique to TI processors either:
> For example, imx6q-cpufreq.c uses 3 regulators (arm, pu, soc),
> s5pv210-cpufreq.c uses two regulators (vddarm, vddint), ideally OMAP
> implementation would use two (vdd_mpu, vbb_mpu).
> 
> > I have wondered about making an abstract
> > "performance domain" which is the dvfs analogue to generic power
> > domains. This a reasonable split since gpd are good for idle power
> > savings (e.g. clock gate, power gate, sleep state, etc) and "perf
> > domains" would be good for active power savings (dvfs).
> > 
> > Having a generic container for performance domains might make a good
> > place to stuff all of this glue logic that we keep running into (e.g.
> > CPU and GPU max frequencies that are related), and it might make another
> > nice knob for the thermal folks to use.
> 
> This sounds like one level higher abstraction that we are speaking of
> here? I was'nt intending to solve the bigger picture problem here -
> just an abstraction level that might allow reusablity for multiple
> SoCs. In fact, having an abstraction away for voltage domain(which may
> consist of multiple regulators and any SoC specific magic) purely
> allows us to move towards a direction you mention here.
> 
> > 
> > For the case of the OMAP voltage domains, it would be a place to stuff
> > all of the VC/VP -> ABB -> Smart Reflex AVS stuff.
> > 
> 
> Unfortunately, I dont completely comprehend objection we have to this
> approach (other than an higher level abstraction is needed) and if we
> do have an objection, what is the alternate approach should be for
> representing hardware which this series attempts to present.

I think the following is around the lines of your thought direction -
if Rafael or others have comments on the following approach, it'd be a
good starting point for me to progress.

-->8--
>From 62e50b9f920495db88e5594aa6bceb52e83a443d Mon Sep 17 00:00:00 2001
From: Nishanth Menon 
Date: Wed, 26 Feb 2014 10:59:59 -0600
Subject: [PATCH] PM / Runtime: introduce active power management callbacks
 for pm_domain

dev_pm_domain currently handles just device idle power management
using the generic pm_runtime_get|put and related family of functions.

Logically with appropriate pm_domain hooks this can translate to
hardware specific clock and related operations. Given that pm_domains
may contain this information, this provides an opportunity to extend
current pm_runtime do dynamic power operations as well.

What this means for drivers is as follows:

Today, drivers(with some level of complexity) do:
pm_runtime_get_sync(dev);
clk = clk_get(dev, "name");
old_rate = clk_get_rate(clk);
...
clk_set_rate(clk, new_rate);
...
clk_put(clk);
pm_runtime_get_sync(dev);

Instead, on pm_domains that can handle this as part of
pm_domain->active_ops functions, They can now do the following:
pm_runtime_get_sync(dev);
old_rate = pm_runtime_get_rate(dev);
...
pm_runtime_set_rate(dev, new_rate);
...
pm_runtime_put_sync(dev);

Obviously, this'd work for devices that handle a single main
functional clock, but this could reduce complexity of drivers having
to deal with power management details to have pm_runtime as the main
point of interface.

CAVEAT: For power domains that are capable of handling multiple
clocks (example on OMAP, where there are the concepts of interface,
functional and optional clocks per block), appropriate handling will
be necessary from pm_domain callbacks. So, the question about which
clock rate is being controlled or returned to is entirely upto the
pm_domain implementation.

On the otherhand, we can debate about defining and querying ACPI style
"Performance state" instead of frequencies and wrap P-states inside
or the other way around.. but given that majority of drivers using
pm_runtime would rather be interested in frequencies and my naieve
belief that we can index P-states with frequencies, kind of influenced
my choice here of proposing frequencies as base query parameter..
ofcourse, debate is still open here.

Yes, we can still debate if providing yet another wrapper on top of
clock APIs makes sense at all as well.

Nyet-signed-off-by: Nishanth Menon 
---
 drivers/base/power/runtime.c |  101 ++
 include/linux/pm.h   |   25 +--
 include/linux/pm_runtime.h   |   21 +
 3 files changed, 143 insertions(+), 4 deletions(-)

diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 72e00e6..ef230b4 100644
--- 

Re: [PATCH v3 1/9] Input: pmic8xxx-pwrkey - Migrate to regmap APIs

[Josh Cartwright]

On Wed, Feb 26, 2014 at 04:43:03PM -0800, Stephen Boyd wrote:
> On 02/26/14 16:30, Josh Cartwright wrote:
> > On Wed, Feb 26, 2014 at 04:20:03PM -0800, Stephen Boyd wrote:
> >> On 02/26/14 16:13, Josh Cartwright wrote:
> >>> On Wed, Feb 26, 2014 at 04:05:40PM -0800, Stephen Boyd wrote:
>  On 02/26/14 15:59, Josh Cartwright wrote:
> >>> However, I think it needs to be made clear that your if "Modernize pm8921
> >>> with irqdomains, regmap, DT" lands before this patchset, this will start
> >>> breaking randconfig builds.  It isn't clear to me how this dependency
> >>> should be handled.
> >>>
> >> Hmm? If pm8921 lands before this what build breakage is there? The
> >> pm8xxx_read/write APIs are still exposed.
> > Well, with the pm8921 patchset in place, the keypad driver becomes
> > selectable, which, when built leads to the error below.  But AFAICT,
> > this isn't even addressed in this patchset?!
> >
> > drivers/input/keyboard/pmic8xxx-keypad.c:24:35: fatal error: 
> > linux/mfd/pm8xxx/gpio.h: No such file or directory
> >  #include 
> >^
> >
> > So, I'm confused...maybe the pm8921 cleanup patchset should be marking
> > the keypad driver BROKEN?
> >
> 
> Ah, yes probably. I have a patch locally that rips out the gpio stuff
> because this driver has been uncompilable since it was introduced. I may
> as well send that along with this series so that people can actually
> compile this driver. Or like you say, send it along with the removal of
> the BROKEN in pm8921 Kconfig.

Yeah, I think it should probably land before MFD_PM8XXX's BROKEN
removal, just to eliminate randconfig breakage noise.  I double-checked,
and it looks like at least the other drivers that depend on MFD_PM8XXX
still build (with a couple sparse warnings).

Also.it's driving me nuts that some of the pm8xxx drivers use
"pm8xxx-foo", and others use "pmic8xxx-foo"...

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Juan Manuel Cabo]

 
> that's really nasty EC firmware!

Yes!
And this bug has been unsolved for about two years.

> 20 is enough?
> the query index is length of a byte.
>
According to our humble tests, 8 is the maximum number of
accumulated events. For instance, if the one plugs or unplugs the PSU
16 times, (or battery % changes 16 times) during S3 sleep, then the
EC returns no more than 8 events when polled by this patch or by
my userspace util.
And having reached 8 events, it won't produce its GPE until queried.

> the query index is length of a byte.

There is no query index, unless you refer to something else (I'm sorry if its
something that escapes me).
For us, a query is just: send 0x84 through EC CMD port, and read status
from CMD port and event type from EC DATA port. This is done with
the usual ec.c functions that would handle a query after a GPE interrupt,
but using them instead to poll (not GPE initiated) at awake. The EC would
then return status without 0x20 mask and 'event type'==0 when no more left.

--
Juan Manuel Cabo 



>>
>>   enum {
>>   EC_FLAGS_QUERY_PENDING,/* Query is pending */
>> @@ -116,6 +118,7 @@ EXPORT_SYMBOL(first_ec);
>>   static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
>>   static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
>>   static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT 
>> scan */
>> +static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on boot/resume 
>> */
>>
>
> seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
> seems too long :-)
>
>>
>>   /* 
>> --
>>Transaction Management
>> @@ -440,6 +443,26 @@ acpi_handle ec_get_handle(void)
>>
>>   EXPORT_SYMBOL(ec_get_handle);
>>
>> +static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data);
>> +
>> +/* run with locked ec mutex */
>> +static void acpi_ec_clear(struct acpi_ec *ec)
>> +{
>> +int i, status;
>> +u8 value = 0;
>> +
>> +for (i = 0; i<  ACPI_EC_CLEAR_MAX; i++) {
>> +status = acpi_ec_query_unlocked(ec,);
>> +if (status || !value)
>> +break;
>> +}
>> +
>> +if (i == ACPI_EC_CLEAR_MAX)
>> +pr_warn("Warning: Maximum of %d stale EC events cleared\n", i);
>> +else
>> +pr_info("%d stale EC events cleared\n", i);
>> +}
>> +
>>   void acpi_ec_block_transactions(void)
>>   {
>>   struct acpi_ec *ec = first_ec;
>> @@ -463,6 +486,10 @@ void acpi_ec_unblock_transactions(void)
>>   mutex_lock(>mutex);
>>   /* Allow transactions to be carried out again */
>>   clear_bit(EC_FLAGS_BLOCKED,>flags);
>> +
>> +if (EC_FLAGS_CLEAR_ON_RESUME)
>> +acpi_ec_clear(ec);
>> +
>>   mutex_unlock(>mutex);
>>   }
>>
>> @@ -821,6 +848,13 @@ static int acpi_ec_add(struct acpi_device *device)
>>
>>   /* EC is fully operational, allow queries */
>>   clear_bit(EC_FLAGS_QUERY_PENDING,>flags);
>> +
>> +/* Some hardware may need the EC to be cleared before use */
>>
>
> description is implicit, should specify what we clear is Q event, not EC.
>
> Thanks!
> Li Guang
>
>> +if (EC_FLAGS_CLEAR_ON_RESUME) {
>> +mutex_lock(>mutex);
>> +acpi_ec_clear(ec);
>> +mutex_unlock(>mutex);
>> +}
>>   return ret;
>>   }
>>
>> @@ -922,6 +956,30 @@ static int ec_enlarge_storm_threshold(const struct 
>> dmi_system_id *id)
>>   return 0;
>>   }
>>
>> +/*
>> + * On some hardware it is necessary to clear events accumulated by the EC 
>> during
>> + * sleep. These ECs stop reporting GPEs until they are manually polled, if 
>> too
>> + * many events are accumulated. (e.g. Samsung Series 5/9 notebooks)
>> + *
>> + * https://bugzilla.kernel.org/show_bug.cgi?id=44161
>> + *
>> + * Ideally, the EC should also be instructed not to accumulate events during
>> + * sleep (which Windows seems to do somehow), but the interface to control 
>> this
>> + * behaviour is not known at this time.
>> + *
>> + * Models known to be affected are Samsung 
>> 530Uxx/535Uxx/540Uxx/550Pxx/900Xxx,
>> + * however it is very likely that other Samsung models are affected.
>> + *
>> + * On systems which don't accumulate EC events during sleep, this extra 
>> check
>> + * should be harmless.
>> + */
>> +static int ec_clear_on_resume(const struct dmi_system_id *id)
>> +{
>> +pr_debug("Detected system needing EC poll on resume.\n");
>> +EC_FLAGS_CLEAR_ON_RESUME = 1;
>> +return 0;
>> +}
>> +
>>   static struct dmi_system_id ec_dmi_table[] __initdata = {
>>   {
>>   ec_skip_dsdt_scan, "Compal JFL92", {
>> @@ -965,6 +1023,9 @@ static struct dmi_system_id ec_dmi_table[] __initdata = 
>> {
>>   ec_validate_ecdt, "ASUS hardware", {
>>   DMI_MATCH(DMI_SYS_VENDOR, "ASUSTek Computer Inc."),
>>   DMI_MATCH(DMI_PRODUCT_NAME, "L4R"),}, NULL},
>> +{
>> +ec_clear_on_resume, "Samsung hardware", {
>> +DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG 

Re: [PATCH] sparse: Allow override of sizeof(bool) warning

[Josh Triplett]

On Wed, Feb 26, 2014 at 06:03:39PM -0800, Joe Perches wrote:
> Allow an override to emit or not the sizeof(bool) warning
> 
> Signed-off-by: Joe Perches 

Seems reasonable.  However, please document the new flag in the manpage.

>  evaluate.c | 3 ++-
>  lib.c  | 2 ++
>  lib.h  | 1 +
>  3 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/evaluate.c b/evaluate.c
> index 6655615..a45f59b 100644
> --- a/evaluate.c
> +++ b/evaluate.c
> @@ -2057,7 +2057,8 @@ static struct symbol *evaluate_sizeof(struct expression 
> *expr)
>   }
>  
>   if (size == 1 && is_bool_type(type)) {
> - warning(expr->pos, "expression using sizeof bool");
> + if (Wsizeof_bool)
> + warning(expr->pos, "expression using sizeof bool");
>   size = bits_in_char;
>   }
>  
> diff --git a/lib.c b/lib.c
> index bf3e91c..676b72e 100644
> --- a/lib.c
> +++ b/lib.c
> @@ -225,6 +225,7 @@ int Wone_bit_signed_bitfield = 1;
>  int Wparen_string = 0;
>  int Wptr_subtraction_blows = 0;
>  int Wreturn_void = 0;
> +int Wsizeof_bool = 1;
>  int Wshadow = 0;
>  int Wtransparent_union = 0;
>  int Wtypesign = 0;
> @@ -437,6 +438,7 @@ static const struct warning {
>   { "paren-string", _string },
>   { "ptr-subtraction-blows", _subtraction_blows },
>   { "return-void", _void },
> + { "sizeof-bool", _bool },
>   { "shadow",  },
>   { "transparent-union", _union },
>   { "typesign",  },
> diff --git a/lib.h b/lib.h
> index f09b338..7e3432f 100644
> --- a/lib.h
> +++ b/lib.h
> @@ -119,6 +119,7 @@ extern int Wone_bit_signed_bitfield;
>  extern int Wparen_string;
>  extern int Wptr_subtraction_blows;
>  extern int Wreturn_void;
> +extern int Wsizeof_bool;
>  extern int Wshadow;
>  extern int Wtransparent_union;
>  extern int Wtypesign;
> -- 
> 1.8.1.2.459.gbcd45b4.dirty
> 
> 
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sparse" 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: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint code

[Mathieu Desnoyers]

- Original Message -
> From: "Steven Rostedt" 
> To: "Mathieu Desnoyers" 
> Cc: linux-kernel@vger.kernel.org, "Ingo Molnar" , "Andrew 
> Morton" ,
> "Peter Zijlstra" , "Frederic Weisbecker" 
> 
> Sent: Wednesday, February 26, 2014 8:38:53 PM
> Subject: Re: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint 
> code
> 
> On Wed, 26 Feb 2014 21:36:18 + (UTC)
> Mathieu Desnoyers  wrote:
> 
> > - Original Message -
> > > From: "Steven Rostedt" 
> > > To: linux-kernel@vger.kernel.org
> > > Cc: "Ingo Molnar" , "Andrew Morton"
> > > , "Peter Zijlstra"
> > > , "Frederic Weisbecker" ,
> > > "Mathieu Desnoyers"
> > > 
> > > Sent: Wednesday, February 26, 2014 2:01:40 PM
> > > Subject: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint
> > > code
> > > 
> > > [ Request for Acks ]
> > > 
> > > Due to module tainting, we have tracepoints that silently do not work.
> > > That will be solved another way. But the trace event infrastructure
> > > should
> > > not be created for tainted modules. That is, the debugfs files should
> > > not exist for them.
> > > 
> > > By moving the tracepoint module taint test into tracepoint.h, we can
> > > reuse that same test when creating the module tracepoint events.
> > > 
> > > Note, I had to remove the tracepoint.h include from module.h as there
> > > was nothing in module.h that required tracepoint.h, but this broke
> > > a couple of event files (migrate.h and writeback.h) because they did
> > > not include tracepoint.h, and were just lucky that it was included
> > > by module.h.
> > 
> > When designing tracepoint.h, a lot of care went into making sure it did
> > not have needless dependency on other headers, since this header is
> > expected to be included into many other files and headers, thus posing
> > a clear risk of becoming yet another root of an include dependency hell.
> 
> Well, module.h is included in many more.

That is not the question. We don't care about how many times module.h is
included in the kernel, but rather what module.h itself includes and could
include in the future, throughout generic and arch-specific headers. If
someone want to add a tracepoint in a static inline function located within
a header file, they will need to include tracepoint.h. If tracepoint.h
happens to have a circular dependency on this header, there comes include
hell.

Arguing that it's OK to include headers within core instrumentation code
because they are themselves included pretty much everywhere is a paved way
to said include hell IMHO.

> 
> > 
> > While I agree on adding the API you propose, why made it a static inline ?
> > This adds this dependency from tracepoint.h on module.h. Instead, we could
> > just declare a symbol, and implement a tracepoint_module_has_bad_taint()
> > within kernel/tracepoint.c. It should not be a fast path anyway, so I don't
> > see the point it making it a static inline.
> > 
> > I also recommend sticking to the tracepoint_*() API (rather than trace_*).
> 
> Well, as this is now not just for tracepoints, but also used by the
> trace_events, and because the name is already too big (but
> descriptive), I rather not change it.

I just recalled we already have things like "DECLARE_TRACE" and such in
tracepoint.h. I'm OK with trace_module_has_bad_taint() then.

> 
> But as a compromise, I can move it to ftrace_event.h instead.

Since it will be used in tracepoint.c as well, which is a foundation of
ftrace_event, it would be bad coupling to make tracepoint.c include
ftrace_event.h (abstraction inversion). So I still think tracepoint.h
is the right place to put this, only not with the module.h dependency.

But perhaps I'm missing something. Why is it so important to you to make
this a static inline rather than a regular function call ?

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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: linux-next: build failure after merge of the final tree (akpm-current tree related)

[Josh Triplett]

On Thu, Feb 27, 2014 at 10:00:26AM +1100, Stephen Rothwell wrote:
> Please check the build results overnight tonight (for next-20140227 at
> http://kisskb.ellerman.id.au/linux-next) and submit any more fixes for
> the allnoconfig build errors.

Checking that site, I don't see any other instances of failures caused
by allnoconfig.  If I'm missing some, could you please point me to the
page on that site I'm missing?

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

Re: [patch 09/26] arm: mmp: Remove pointless fiddling with irq internals

[Haojian Zhuang]

On Thu, Feb 27, 2014 at 9:37 AM, Chao Xie  wrote:
> On Mon, Feb 24, 2014 at 7:31 PM, Thomas Gleixner  wrote:
>> On Mon, 24 Feb 2014, Haojian Zhuang wrote:
>>
>>> On Mon, Feb 24, 2014 at 2:07 PM, Chao Xie  wrote:
>>> > On Mon, Feb 24, 2014 at 7:17 AM, Uwe Kleine-König
>>> >  wrote:
>>> >> Hi Thomas,
>>> >>
>>> >> On Sun, Feb 23, 2014 at 09:40:13PM -, Thomas Gleixner wrote:
>>> >>> The pm-mmp2 and pm-pxa910 power management related irq_set_wake
>>> >>> callbacks fiddle pointlessly with the irq actions for no reason except
>>> >>> for lack of understanding how the wakeup mechanism works.
>>> >>>
>>> >>> On supsend the core disables all interrupts lazily, i.e. it does not
>>> >>> mask them at the irq controller level. So any interrupt which is
>>> >>> firing during supsend will mark the corresponding interrupt line as
>>> >> s/supsend/suspend/ twice
>>> >>> pending. Just before the core powers down it checks whether there are
>>> >>> interrupts pending from interrupt lines which are marked as wakeup
>>> >>> sources and if so it aborts the resume and resends the interrupts.
>>> >> It's the suspend that is aborted, not the resume.
>>> >>
>>> >> Other than that your change looks fine.
>>> >>
>>> > For pxa910 and MMP2, wake up source only wake up the AP subsystem.
>>> > The AP subsystem includes the APMU(AP Power Mangament Unit) and cores.
>>> > Now the core is still powered down. APMU will check the interrupt
>>> > lines, and find
>>> > that there are interrupt pending, it will power on the cores.
>>> > So if the irq is disabled, even wake up source can wake up AP subsystem, 
>>> > but the
>>> > core is still powered down. It will not be powered up by APMU.
>>> >
>>>
>>> Yes, suspend/resume can't work if the above code is removed.
>>>
>>> Interrupt source (logic AND with interrupt mask register) is connected
>>> to MPMU as
>>> wakeup source. If the interrupt is disabled, there's no wakeup source event.
>>>
>>> And APMU is waken up by MPMU.
>>>
>>> So please don't remove the above code. We must keep these interrupt lines 
>>> active
>>> to wake up the whole system.
>>
>> They are kept active at the interrupt controller level. You just
>> refuse to understand how the internals of the interrupt subsystem
>> work.
>>
> If no irq_disable callback is hooked, when do irq_disable, it will not
> actually disable
> the interrupt, it will depend on next time when the irq happens, the
> handler will first mask
> the interrupt as this interrupt never happens.
> So after system suspended, the interrupt happens, but the device
> driver will not recieve this interrupt
> because it is masked.
> It results in that the device driver miss a important interrupt which
> related to something need to be
> handled. If user application for example android has power managment
> daemon. It will find that nothing
> to handle, it will make the system enter suspend again.
>
Let me list the logic to make it easier to understand.

suspend_enter()
  --> dpm_suspend_end()
   --> dpm_suspend_noirq()
--> suspend_device_irqs()
 --> __disable_irq()
 --> set IRQS_SUSPENDED && call
irq_disable() if necessary
  --> syscore_suspend()
  --> check_wakeup_irqs()
   If there's no pending irq in suspend process &&
IRQS_SUSPENDED is set,
   then mask the irq.

Yes, we didn't implement disable_irq(). But we must implement mask_irq().

So system suspends. Then system will never be waken up by this irq any
more since
it's masked.


>> And even if you would need this flag, then fiddling with the irq desc
>> internals is a big NONO. There is a proper way to hand that in.
>>
>
> So can you suggest the proper way to handle it? Thanks.
>
>> Thanks,
>>
>> tglx
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/3] ARM: config: Update msm_defconfig

[Stephen Boyd]

Now that DT based platforms are split out of mach-msm into
mach-qcom, put back a non-DT based SoC into the msm_defconfig and
stop selecting unsupported drivers.

Signed-off-by: Stephen Boyd 
---
 arch/arm/configs/msm_defconfig | 25 +++--
 1 file changed, 3 insertions(+), 22 deletions(-)

diff --git a/arch/arm/configs/msm_defconfig b/arch/arm/configs/msm_defconfig
index c5858b9eb516..7f52dad97f51 100644
--- a/arch/arm/configs/msm_defconfig
+++ b/arch/arm/configs/msm_defconfig
@@ -17,21 +17,14 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_MODULE_FORCE_UNLOAD=y
 CONFIG_MODVERSIONS=y
 CONFIG_PARTITION_ADVANCED=y
-CONFIG_ARCH_MSM_DT=y
-CONFIG_ARCH_MSM8X60=y
-CONFIG_ARCH_MSM8960=y
-CONFIG_ARCH_MSM8974=y
-CONFIG_SMP=y
+CONFIG_ARCH_MSM=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
 CONFIG_HIGHPTE=y
 CONFIG_CLEANCACHE=y
-CONFIG_CC_STACKPROTECTOR=y
-CONFIG_ARM_APPENDED_DTB=y
-CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_AUTO_ZRELADDR=y
 CONFIG_VFP=y
-CONFIG_NEON=y
 # CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
 CONFIG_NET=y
 CONFIG_PACKET=y
@@ -79,16 +72,12 @@ CONFIG_SERIO_LIBPS2=y
 # CONFIG_LEGACY_PTYS is not set
 CONFIG_SERIAL_MSM=y
 CONFIG_SERIAL_MSM_CONSOLE=y
-CONFIG_HW_RANDOM=y
-CONFIG_HW_RANDOM_MSM=y
+# CONFIG_HW_RANDOM is not set
 CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_SPI=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
-CONFIG_POWER_SUPPLY=y
-CONFIG_POWER_RESET=y
-CONFIG_POWER_RESET_MSM=y
 CONFIG_THERMAL=y
 CONFIG_REGULATOR=y
 CONFIG_MEDIA_SUPPORT=y
@@ -100,25 +89,17 @@ CONFIG_SND_DYNAMIC_MINORS=y
 # CONFIG_SND_SPI is not set
 # CONFIG_SND_USB is not set
 CONFIG_SND_SOC=y
-CONFIG_HID_BATTERY_STRENGTH=y
 CONFIG_USB=y
 CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
 CONFIG_USB_MON=y
 CONFIG_USB_EHCI_HCD=y
-CONFIG_USB_EHCI_MSM=y
 CONFIG_USB_ACM=y
 CONFIG_USB_SERIAL=y
 CONFIG_USB_GADGET=y
 CONFIG_USB_GADGET_DEBUG_FILES=y
 CONFIG_USB_GADGET_VBUS_DRAW=500
-CONFIG_NEW_LEDS=y
 CONFIG_RTC_CLASS=y
 CONFIG_STAGING=y
-CONFIG_COMMON_CLK_QCOM=y
-CONFIG_MSM_GCC_8660=y
-CONFIG_MSM_MMCC_8960=y
-CONFIG_MSM_MMCC_8974=y
-CONFIG_MSM_IOMMU=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT3_FS=y
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 2/3] ARM: msm: Silence readb/writeb warnings due to missing IOMEM()

[Stephen Boyd]

TROUT_CPLD_BASE needs the IOMEM() treatment to avoid warnings
from the read/writeb functions.

Signed-off-by: Stephen Boyd 
---
 arch/arm/mach-msm/board-trout-gpio.c | 2 +-
 arch/arm/mach-msm/board-trout.c  | 2 +-
 arch/arm/mach-msm/board-trout.h  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-msm/board-trout-gpio.c 
b/arch/arm/mach-msm/board-trout-gpio.c
index 87e1d01edecc..2c25050209ce 100644
--- a/arch/arm/mach-msm/board-trout-gpio.c
+++ b/arch/arm/mach-msm/board-trout-gpio.c
@@ -89,7 +89,7 @@ static int trout_gpio_to_irq(struct gpio_chip *chip, unsigned 
offset)
.base = base_gpio,  \
.ngpio= 8,  \
},  \
-   .reg = (void *) reg_num + TROUT_CPLD_BASE,  \
+   .reg = reg_num + TROUT_CPLD_BASE,   \
.shadow = shadow_val,   \
}
 
diff --git a/arch/arm/mach-msm/board-trout.c b/arch/arm/mach-msm/board-trout.c
index 015d544aa017..5edfbd904d06 100644
--- a/arch/arm/mach-msm/board-trout.c
+++ b/arch/arm/mach-msm/board-trout.c
@@ -78,7 +78,7 @@ static void __init trout_init(void)
 
 static struct map_desc trout_io_desc[] __initdata = {
{
-   .virtual = TROUT_CPLD_BASE,
+   .virtual = (unsigned long)TROUT_CPLD_BASE,
.pfn = __phys_to_pfn(TROUT_CPLD_START),
.length  = TROUT_CPLD_SIZE,
.type= MT_DEVICE_NONSHARED
diff --git a/arch/arm/mach-msm/board-trout.h b/arch/arm/mach-msm/board-trout.h
index b2379ede43bc..adb757abbb92 100644
--- a/arch/arm/mach-msm/board-trout.h
+++ b/arch/arm/mach-msm/board-trout.h
@@ -58,7 +58,7 @@
 #define TROUT_4_TP_LS_EN19
 #define TROUT_5_TP_LS_EN1
 
-#define TROUT_CPLD_BASE   0xE810
+#define TROUT_CPLD_BASE   IOMEM(0xE810)
 #define TROUT_CPLD_START  0x9800
 #define TROUT_CPLD_SIZE   SZ_4K
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH 1/3] ARM: config: Add qcom_defconfig

[Stephen Boyd]

Add a defconfig for mach-qcom platforms. Although these platforms
are part of the multi-platform kernel, it's useful to have a
stripped down version of the defconfig that just selects the
Qualcomm based platforms and drivers.

Signed-off-by: Stephen Boyd 
---
 arch/arm/configs/qcom_defconfig | 139 
 1 file changed, 139 insertions(+)
 create mode 100644 arch/arm/configs/qcom_defconfig

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
new file mode 100644
index ..0e85031bf3c5
--- /dev/null
+++ b/arch/arm/configs/qcom_defconfig
@@ -0,0 +1,139 @@
+CONFIG_SYSVIPC=y
+CONFIG_NO_HZ=y
+CONFIG_HIGH_RES_TIMERS=y
+CONFIG_IKCONFIG=y
+CONFIG_IKCONFIG_PROC=y
+CONFIG_BLK_DEV_INITRD=y
+CONFIG_SYSCTL_SYSCALL=y
+CONFIG_KALLSYMS_ALL=y
+CONFIG_EMBEDDED=y
+# CONFIG_SLUB_DEBUG is not set
+# CONFIG_COMPAT_BRK is not set
+CONFIG_PROFILING=y
+CONFIG_OPROFILE=y
+CONFIG_KPROBES=y
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+CONFIG_MODULE_FORCE_UNLOAD=y
+CONFIG_MODVERSIONS=y
+CONFIG_PARTITION_ADVANCED=y
+CONFIG_ARCH_QCOM=y
+CONFIG_ARCH_MSM8X60=y
+CONFIG_ARCH_MSM8960=y
+CONFIG_ARCH_MSM8974=y
+CONFIG_SMP=y
+CONFIG_PREEMPT=y
+CONFIG_AEABI=y
+CONFIG_HIGHMEM=y
+CONFIG_HIGHPTE=y
+CONFIG_CLEANCACHE=y
+CONFIG_ARM_APPENDED_DTB=y
+CONFIG_ARM_ATAG_DTB_COMPAT=y
+CONFIG_VFP=y
+CONFIG_NEON=y
+# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
+CONFIG_NET=y
+CONFIG_PACKET=y
+CONFIG_UNIX=y
+CONFIG_INET=y
+CONFIG_IP_ADVANCED_ROUTER=y
+CONFIG_IP_MULTIPLE_TABLES=y
+CONFIG_IP_ROUTE_VERBOSE=y
+CONFIG_IP_PNP=y
+CONFIG_IP_PNP_DHCP=y
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
+# CONFIG_INET_LRO is not set
+# CONFIG_IPV6 is not set
+CONFIG_CFG80211=y
+CONFIG_RFKILL=y
+CONFIG_BLK_DEV_LOOP=y
+CONFIG_BLK_DEV_RAM=y
+CONFIG_SCSI=y
+CONFIG_SCSI_TGT=y
+CONFIG_BLK_DEV_SD=y
+CONFIG_CHR_DEV_SG=y
+CONFIG_CHR_DEV_SCH=y
+CONFIG_SCSI_MULTI_LUN=y
+CONFIG_SCSI_CONSTANTS=y
+CONFIG_SCSI_LOGGING=y
+CONFIG_SCSI_SCAN_ASYNC=y
+CONFIG_NETDEVICES=y
+CONFIG_DUMMY=y
+CONFIG_SLIP=y
+CONFIG_SLIP_COMPRESSED=y
+CONFIG_SLIP_MODE_SLIP6=y
+CONFIG_USB_USBNET=y
+# CONFIG_USB_NET_AX8817X is not set
+# CONFIG_USB_NET_ZAURUS is not set
+CONFIG_INPUT_EVDEV=y
+# CONFIG_KEYBOARD_ATKBD is not set
+# CONFIG_MOUSE_PS2 is not set
+CONFIG_INPUT_JOYSTICK=y
+CONFIG_INPUT_TOUCHSCREEN=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_UINPUT=y
+CONFIG_SERIO_LIBPS2=y
+# CONFIG_LEGACY_PTYS is not set
+CONFIG_SERIAL_MSM=y
+CONFIG_SERIAL_MSM_CONSOLE=y
+CONFIG_HW_RANDOM=y
+CONFIG_HW_RANDOM_MSM=y
+CONFIG_I2C=y
+CONFIG_I2C_CHARDEV=y
+CONFIG_SPI=y
+CONFIG_DEBUG_GPIO=y
+CONFIG_GPIO_SYSFS=y
+CONFIG_POWER_SUPPLY=y
+CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_MSM=y
+CONFIG_THERMAL=y
+CONFIG_REGULATOR=y
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_FB=y
+CONFIG_SOUND=y
+CONFIG_SND=y
+CONFIG_SND_DYNAMIC_MINORS=y
+# CONFIG_SND_ARM is not set
+# CONFIG_SND_SPI is not set
+# CONFIG_SND_USB is not set
+CONFIG_SND_SOC=y
+CONFIG_HID_BATTERY_STRENGTH=y
+CONFIG_USB=y
+CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
+CONFIG_USB_MON=y
+CONFIG_USB_EHCI_HCD=y
+CONFIG_USB_EHCI_MSM=y
+CONFIG_USB_ACM=y
+CONFIG_USB_SERIAL=y
+CONFIG_USB_GADGET=y
+CONFIG_USB_GADGET_DEBUG_FILES=y
+CONFIG_USB_GADGET_VBUS_DRAW=500
+CONFIG_RTC_CLASS=y
+CONFIG_STAGING=y
+CONFIG_COMMON_CLK_QCOM=y
+CONFIG_MSM_GCC_8660=y
+CONFIG_MSM_MMCC_8960=y
+CONFIG_MSM_MMCC_8974=y
+CONFIG_MSM_IOMMU=y
+CONFIG_EXT2_FS=y
+CONFIG_EXT2_FS_XATTR=y
+CONFIG_EXT3_FS=y
+# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
+CONFIG_EXT4_FS=y
+CONFIG_FUSE_FS=y
+CONFIG_VFAT_FS=y
+CONFIG_TMPFS=y
+CONFIG_NFS_FS=y
+CONFIG_NFS_V3_ACL=y
+CONFIG_NFS_V4=y
+CONFIG_CIFS=y
+CONFIG_PRINTK_TIME=y
+CONFIG_DYNAMIC_DEBUG=y
+CONFIG_DEBUG_INFO=y
+CONFIG_MAGIC_SYSRQ=y
+CONFIG_LOCKUP_DETECTOR=y
+# CONFIG_DETECT_HUNG_TASK is not set
+# CONFIG_SCHED_DEBUG is not set
+CONFIG_TIMER_STATS=y
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCHv8 0/6] add compressing abstraction and multi stream support

[Minchan Kim]

Hello Sergey,

Code looks good to me and I will queue it into ARM and x86 test tomorrow
and give the result to you with Acked-by.

Thanks for your all works!

On Wed, Feb 26, 2014 at 03:27:53PM +0300, Sergey Senozhatsky wrote:
> This patchset introduces zcomp compression backend abstraction
> adding ability to support compression algorithms other than LZO;
> support for multi compression streams, making parallel compressions
> possible.
> 
> v7->v8 (reviewed by Minchan Kim):
> -- merge patches 'add multi stream functionality' and 'enable multi
>stream compression support in zram'
> -- return status code from set_max_streams knob and print message on
>error
> -- do not use atomic type for ->avail_strm
> -- return back: allocate by default only one stream for multi stream backend
> -- wake sleeping write in zcomp_strm_multi_put() only if we put stream
>to idle list
> -- minor code `nitpicks'
> 
> v6->v7 (reviewed by Minchan Kim):
> -- enable multi and single stream support out of the box (drop
>ZRAM_MULTI_STREAM config option)
> -- add set_max_stream knob, so we can adjust max number of compression
>streams in runtime (for multi stream backend at the moment)
> -- minor code `nitpicks'
> 
> v5->v6 (reviewed by Minchan Kim):
> -- handle single compression stream case separately, using mutex locking,
>to address perfomance regression
> -- handle multi compression stream using spin lock and wait_event()/wake_up()
> -- make multi compression stream support configurable (ZRAM_MULTI_STREAM
>config option)
> 
> v4->v5 (reviewed by Minchan Kim):
> -- renamed zcomp buffer_lock; removed src len and dst len from
>compress() and decompress(); not using term `buffer' and
>`workmem' in code and documentation; define compress() and
>decompress() functions for LZO backend; not using goto's;
>do not put idle zcomp_strm to idle list tail.
> 
> v3->v4 (reviewed by Minchan Kim):
> -- renamed compression backend and working memory structs as requested
>by Minchan Kim; fixed several issues noted by Minchan Kim.
> 
> Sergey Senozhatsky (6):
>   zram: introduce compressing backend abstraction
>   zram: use zcomp compressing backends
>   zram: factor out single stream compression
>   zram: add multi stream functionality
>   zram: add set_max_streams knob
>   zram: document max_comp_streams
> 
>  Documentation/ABI/testing/sysfs-block-zram |   9 +-
>  Documentation/blockdev/zram.txt|  31 ++-
>  drivers/block/zram/Makefile|   2 +-
>  drivers/block/zram/zcomp.c | 318 
> +
>  drivers/block/zram/zcomp.h |  59 ++
>  drivers/block/zram/zcomp_lzo.c |  48 +
>  drivers/block/zram/zram_drv.c  |  98 +
>  drivers/block/zram/zram_drv.h  |  10 +-
>  8 files changed, 528 insertions(+), 47 deletions(-)
>  create mode 100644 drivers/block/zram/zcomp.c
>  create mode 100644 drivers/block/zram/zcomp.h
>  create mode 100644 drivers/block/zram/zcomp_lzo.c
> 
> -- 
> 1.9.0.291.g027825b
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] Add qcom_defconfig and update msm_defconfig

[Stephen Boyd]

Now that we have mach-qcom, introduce a qcom_defconfig to match and
update the msm_defconfig to compile a board in mach-msm.

Stephen Boyd (3):
  ARM: config: Add qcom_defconfig
  ARM: msm: Silence readb/writeb warnings due to missing IOMEM()
  ARM: config: Update msm_defconfig

 arch/arm/configs/msm_defconfig | 25 +++---
 arch/arm/configs/{msm_defconfig => qcom_defconfig} |  4 +---
 arch/arm/mach-msm/board-trout-gpio.c   |  2 +-
 arch/arm/mach-msm/board-trout.c|  2 +-
 arch/arm/mach-msm/board-trout.h|  2 +-
 5 files changed, 7 insertions(+), 28 deletions(-)
 copy arch/arm/configs/{msm_defconfig => qcom_defconfig} (97%)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

[PATCH] s390: select CONFIG_TTY for use of tty in unconditional keyboard driver

[Josh Triplett]

The unconditionally built keyboard driver, drivers/s390/char/keyboard.c,
requires CONFIG_TTY, so select it from CONFIG_S390 to prevent a build
error.

Signed-off-by: Josh Triplett 
---
 arch/s390/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index 65a0775..398efa1 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -140,6 +140,7 @@ config S390
select OLD_SIGACTION
select OLD_SIGSUSPEND3
select SYSCTL_EXCEPTION_TRACE
+   select TTY
select VIRT_CPU_ACCOUNTING
select VIRT_TO_BUS
 
-- 
1.9.0

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

[PATCH RESEND] mmc:sdhci: handle busy-end interrupt during command

[Chanho Min]

It is fully legal for a controller to start handling busy-end interrupt
before it has signaled that the command has completed. So make sure
we do things in the proper order, Or it results that command interrupt
is ignored so it can cause unexpected operations. This is founded at some
toshiba emmc with the bellow warning.

"mmc0: Got command interrupt 0x0001 even though
no command operation was in progress."

Can anyone ACK/NACK of this patch? Any comment will be appreciated.

Signed-off-by: Hankyung Yu 
Signed-off-by: Chanho Min 
---
 drivers/mmc/host/sdhci.c  |   17 +++--
 include/linux/mmc/sdhci.h |1 +
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index bd8a098..21f98e7 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1016,6 +1016,7 @@ void sdhci_send_command(struct sdhci_host *host, struct 
mmc_command *cmd)
mod_timer(>timer, jiffies + 10 * HZ);
 
host->cmd = cmd;
+   host->busy_handle = 0;
 
sdhci_prepare_data(host, cmd);
 
@@ -2271,8 +2272,12 @@ static void sdhci_cmd_irq(struct sdhci_host *host, u32 
intmask)
if (host->cmd->data)
DBG("Cannot wait for busy signal when also "
"doing a data transfer");
-   else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ))
+   else if (!(host->quirks & SDHCI_QUIRK_NO_BUSY_IRQ)
+   && !host->busy_handle) {
+   /* Mark that command complete before busy is ended */
+   host->busy_handle = 1;
return;
+   }
 
/* The controller does not support the end-of-busy IRQ,
 * fall through and take the SDHCI_INT_RESPONSE */
@@ -2335,7 +2340,15 @@ static void sdhci_data_irq(struct sdhci_host *host, u32 
intmask)
 */
if (host->cmd && (host->cmd->flags & MMC_RSP_BUSY)) {
if (intmask & SDHCI_INT_DATA_END) {
-   sdhci_finish_command(host);
+   /*
+* Some cards handle busy-end interrupt
+* before the command completed, so make
+* sure we do things in the proper order.
+*/
+   if (host->busy_handle)
+   sdhci_finish_command(host);
+   else
+   host->busy_handle = 1;
return;
}
}
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 3e781b8..0118020 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -148,6 +148,7 @@ struct sdhci_host {
struct mmc_command *cmd;/* Current command */
struct mmc_data *data;  /* Current data request */
unsigned int data_early:1;  /* Data finished before cmd */
+   unsigned int busy_handle:1; /* Handling the order of Busy-end */
 
struct sg_mapping_iter sg_miter;/* SG state for PIO */
unsigned int blocks;/* remaining PIO blocks */
-- 
1.7.9.5

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

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

[Ren Qiaowei]

On 02/27/2014 05:44 AM, H. Peter Anvin wrote:

On 02/26/2014 11:17 AM, Dave Hansen wrote:

On 02/23/2014 05:27 AM, Qiaowei Ren wrote:

+Bounds Directory (BD) and Bounds Tables (BT) are stored in
+application memory and are allocated by the application (in case
+of kernel use, the structures will be in kernel memory). The
+bound directory and each instance of bound table are in contiguous
+linear memory.


Hi Qiaowei,

Does this mean that if userspace decided to map something in the way of
the bounds tables that it would break MPX?

Also, in the description, could we s/linear/virtual/?  Linear seems to
be the term that Intel likes to use in its documents, but we almost
universally call them virtual addresses in the kernel.



It might be useful to clarify, though, just so noone gets confused with
effective addresses (offsets).

Ok. Some words here come from some MPX public documents. I need to go 
through more carefully.


Thanks,
Qiaowei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: The sheer number of sparse warnings in the kernel

[Joe Perches]

On Wed, 2014-02-26 at 17:34 -0800, Greg KH wrote:
> On Wed, Feb 26, 2014 at 04:11:30PM -0800, H. Peter Anvin wrote:
> > I have seen this phenomenon, too.  I also see a bunch of sparse warnings
> > which are clearly bogus, for example complaining about sizeof(bool) when
> > in bits like:
> > 
> > __this_cpu_write(swallow_nmi, false);
[]
> I guess the first thing would be to do is look to try to fix things like
> the "bool" issue you have here.

I wonder what the "fix" would be as by standard
_Bool doesn't have a defined size.

Probably another sparse -Wno-sizeof-bool flag.
(just added and submitted)

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

[RFC PATCH] Makefile: sparse - don't check sizeof(bool)

[Joe Perches]

Add an override for sizeof(bool)

Requires sparse 0.5.0+ if -Wsizeof-bool is accepted there.

Signed-off-by: Joe Perches 
---
 Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index fce2ba7..d9cea07 100644
--- a/Makefile
+++ b/Makefile
@@ -350,7 +350,7 @@ PERL= perl
 CHECK  = sparse
 
 CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
- -Wbitwise -Wno-return-void $(CF)
+ -Wbitwise -Wno-return-void -Wno-sizeof-bool $(CF)
 CFLAGS_MODULE   =
 AFLAGS_MODULE   =
 LDFLAGS_MODULE  =


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 08/11] vfs: Merge check_submounts_and_drop and d_invalidate

[Eric W. Biederman]

"J. Bruce Fields"  writes:

> On Tue, Feb 25, 2014 at 02:03:36PM -0800, Eric W. Biederman wrote:
>> "J. Bruce Fields"  writes:
>> 
>> > On Mon, Feb 24, 2014 at 04:01:29PM -0800, Eric W. Biederman wrote:
>> >> Miklos Szeredi  writes:
>> >> 
>> >> >
>> >> > You can optimize this by including the negative check within the above 
>> >> > d_locked
>> >> > region and calling __d_drop() instead.
>> >> 
>> >> For this patch just moving the code and not changing it is the corret
>> >> thing to do because it helps with review and understanding the code.
>> >> 
>> >> There are two ways I could see going with optimizing the preamble.
>> >> Simply dropping the d_lock from around the d_unhashed test as a pointer
>> >> dereference should be atomic, and the test is racy against
>> >> d_materialise_unique.
>> >
>> > Could you explain?  What's the race, and what are the consequences?
>
> Actually I was just confused as to whether the above was "is racy" was
> claiming the existance of some bug.
>
> I believe I should have read the above as more like "the test is already
> racy against d_materialise_unique, but it's a harmless race, and
> dropping the d_lock wouldn't make it any worse".
>
>> >> (We don't always hold the parent directories inode mutex when 
>> >> d_invalidate is called).
>> 
>> d_unhashed is not a permanent condition because of d_materialise_unique,
>> and d_splice_alias.
>> 
>> d_invalidate can be called on an unhashed dentry in one of two ways
>> (either d_revalidate dropped the dentry or another routine that drops
>> the dentry beat the current invocation of d_invalidate to the job).
>> 
>> 
>> There are 3 places d_revalidate is called.
>> 
>> Once on the rcu path with with the appropriate flag set.
>> 
>> Once without out the parent i_mutex held, just off of the rcu path,
>> on that path d_invalidate is when d_revalidate fails.
>> 
>> Once during lookup with the parent directory i_mutex held.
>> 
>> 
>> Because the parent direcories i_mutex is not always held accross
>> d_revalidate and the following d_invalidate it happens that d_invalidate
>> is not always an atomic operation.
>> 
>> 
>> At worst the race results in a dentry that is dropped when it could be
>> hashed,
>
> Because somebody not holding the i_mutex calls d_invalidate based on old
> information and unhashes something that
> d_materialise_unique/d_splice_alias just hashed?

More likely today somebody not holding i_mutex and not in rcu context
calls d_revalidate.  d_revalidate drops the dentry and before we
d_invalidate d_materialise_unique/d_splice_alias rehashes it.

After my changes it looks like it takes 3 processes two instances
of d_invalidate and a instance of d_materialise_unique/d_spliace_alias
to trigger this case.

In either case the window is very small and the outcome is effectively
harmless.  So I don't see this as a problem.

>> that we will resurrect next time someone attempts to look it
>> up and d_materialise_unique/d_splice_alias is called.
>
> OK.
>
>> None of that really matters for optimizing d_invalidate, but it is part
>> of the background in which d_invalidate lives. All that is significant
>> in d_invalidate is knowing that d_materialise_unique, and possibly
>> d_splice_alias may run concurrently with d_invalidate.  It is unlikely
>> and essentially harmless.
>> 
>> 
>> After my patchset (because I removed all of the d_drop's from
>> .d_revalidate) the only race that should remain is between two parallel
>> calls of d_invalidate.  Which probably means we can remove the test for
>> d_unhashed altogether.
>> 
>> Right now I just want to make this first big step and make certain the
>> code is solid.  After that optimization is easy.
>
> Thanks for the explanation!

Welcome.

Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 1/3] x86, mpx: add documentation on Intel MPX

[Ren Qiaowei]

On 02/27/2014 05:19 AM, Dave Hansen wrote:

On 02/23/2014 05:27 AM, Qiaowei Ren wrote:

+The other case that generates a #BR is when a BNDSTX instruction
+attempts to save bounds to a BD entry marked as invalid. This is
+an indication that no BT exists for this entry. In this case the
+fault handler will allocate a new BT.


Hi Qiaowei,

Can you make an effort to move these comments over to the code?  The
bounds-table allocation function is a much more appropriate place for
this text than the Documentation/ file.


Ok. They will be moved.

Thanks,
Qiaowei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sparse: Allow override of sizeof(bool) warning

[Joe Perches]

Allow an override to emit or not the sizeof(bool) warning

Signed-off-by: Joe Perches 
---
 evaluate.c | 3 ++-
 lib.c  | 2 ++
 lib.h  | 1 +
 3 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/evaluate.c b/evaluate.c
index 6655615..a45f59b 100644
--- a/evaluate.c
+++ b/evaluate.c
@@ -2057,7 +2057,8 @@ static struct symbol *evaluate_sizeof(struct expression 
*expr)
}
 
if (size == 1 && is_bool_type(type)) {
-   warning(expr->pos, "expression using sizeof bool");
+   if (Wsizeof_bool)
+   warning(expr->pos, "expression using sizeof bool");
size = bits_in_char;
}
 
diff --git a/lib.c b/lib.c
index bf3e91c..676b72e 100644
--- a/lib.c
+++ b/lib.c
@@ -225,6 +225,7 @@ int Wone_bit_signed_bitfield = 1;
 int Wparen_string = 0;
 int Wptr_subtraction_blows = 0;
 int Wreturn_void = 0;
+int Wsizeof_bool = 1;
 int Wshadow = 0;
 int Wtransparent_union = 0;
 int Wtypesign = 0;
@@ -437,6 +438,7 @@ static const struct warning {
{ "paren-string", _string },
{ "ptr-subtraction-blows", _subtraction_blows },
{ "return-void", _void },
+   { "sizeof-bool", _bool },
{ "shadow",  },
{ "transparent-union", _union },
{ "typesign",  },
diff --git a/lib.h b/lib.h
index f09b338..7e3432f 100644
--- a/lib.h
+++ b/lib.h
@@ -119,6 +119,7 @@ extern int Wone_bit_signed_bitfield;
 extern int Wparen_string;
 extern int Wptr_subtraction_blows;
 extern int Wreturn_void;
+extern int Wsizeof_bool;
 extern int Wshadow;
 extern int Wtransparent_union;
 extern int Wtypesign;
-- 
1.8.1.2.459.gbcd45b4.dirty



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

Re: [PATCH] clk:at91: Fix memory leak in of_at91_clk_master_setup()

[Mike Turquette]

Quoting Boris BREZILLON (2014-02-15 09:08:12)
> Hi Mike,
> 
> Could you take this patch for the next 3.14 release ?

Taken in for the next batch of fixes.

Regards,
Mike

> 
> Best Regards,
> 
> Boris
> 
> On 11/02/2014 14:18, Boris BREZILLON wrote:
> > On 11/02/2014 14:15, Masanari Iida wrote:
> >> cppcheck detected following error
> >> [clk-master.c:245]: (error) Memory leak: characteristics
> >>
> >> The original code forgot to free characteristics when
> >> irq_of_parse_and_map() failed.
> >>
> >> Signed-off-by: Masanari Iida 
> > Acked-by Boris BREZILLON 
> >
> > Thanks for fixing this.
> >
> > Best Regards,
> >
> > Boris
> >> ---
> >>   drivers/clk/at91/clk-master.c | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/at91/clk-master.c 
> >> b/drivers/clk/at91/clk-master.c
> >> index bd313f7..c1af80b 100644
> >> --- a/drivers/clk/at91/clk-master.c
> >> +++ b/drivers/clk/at91/clk-master.c
> >> @@ -242,7 +242,7 @@ of_at91_clk_master_setup(struct device_node *np, 
> >> struct at91_pmc *pmc,
> >> irq = irq_of_parse_and_map(np, 0);
> >>   if (!irq)
> >> -return;
> >> +goto out_free_characteristics;
> >> clk = at91_clk_register_master(pmc, irq, name, num_parents,
> >>  parent_names, layout,
> >
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re : [PATCH 4/8] lib: Add prototype declarations in lib/clz_ctz.c

[민찬호]

> -Original Message-
> From: Rashika Kheria [mailto:rashika.khe...@gmail.com]
> Sent: Tuesday, February 25, 2014 4:46 PM
> To: linux-kernel@vger.kernel.org
> Cc: Andrew Morton; Rashika Kheria; Chanho Min; j...@joshtriplett.org
> Subject: [PATCH 4/8] lib: Add prototype declarations in lib/clz_ctz.c
>
> Add prototype declarations of functions in lib/clz_ctz.c. These
> functions are required by GCC builtins and hence can not be removed
> despite of their unreferenced appearance in kernel source.
>
> This eliminates the following warning in lib/clz_ctz.c:
> lib/clz_ctz.c:16:12: warning: no previous prototype for ‘__ctzsi2’ 
> [-Wmissing-prototypes]
> lib/clz_ctz.c:22:12: warning: no previous prototype for ‘__clzsi2’ 
> [-Wmissing-prototypes]
> lib/clz_ctz.c:44:12: warning: no previous prototype for ‘__clzdi2’ 
> [-Wmissing-prototypes]
> lib/clz_ctz.c:50:12: warning: no previous prototype for ‘__ctzdi2’ 
> [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria 
> Reviewed-by: Josh Triplett 
Acked-by: Chanho Min 

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Li Guang]

Kieran Clancy wrote:

A number of Samsung notebooks (530Uxx/535Uxx/540Uxx/550Pxx/900Xxx/etc)
continue to log events during sleep (lid open/close, AC plug/unplug,
battery level change), which accumulate in the EC until a buffer fills.
After the buffer is full (tests suggest it holds 8 events), GPEs stop
being triggered for new events. This state persists on wake or even on
power cycle, and prevents new events from being registered until the EC
is manually polled.

   


that's really nasty EC firmware!


This is the root cause of a number of bugs, including AC not being
detected properly, lid close not triggering suspend, and low ambient
light not triggering the keyboard backlight. The bug also seemed to be
responsible for performance issues on at least one user's machine.

Juan Manuel Cabo found the cause of bug and the workaround of polling
the EC manually on wake.

This patch:
- Adds a function acpi_ec_clear() which polls the EC, at most
   ACPI_EC_CLEAR_MAX (currently 20) times. A warning is logged if this
   limit is reached.
- Adds a flag EC_FLAGS_CLEAR_ON_RESUME which is set to 1 if the DMI
   system vendor is Samsung. This check could be replaced by several more
   specific DMI vendor/product pairs, but it's likely that the bug
   affects more Samsung products than just the five series mentioned
   above. Further, it should not be harmful to run acpi_ec_clear() on
   systems without the bug; it will return immediately after finding no
   data waiting.
- Runs acpi_ec_clear() on initialisation (boot), from acpi_ec_add()
- Runs acpi_ec_clear() on wake, from acpi_ec_unblock_transactions()

References: https://bugzilla.kernel.org/show_bug.cgi?id=44161
References: https://bugzilla.kernel.org/show_bug.cgi?id=45461
References: https://bugzilla.kernel.org/show_bug.cgi?id=57271
Signed-off-by: Kieran Clancy
Signed-off-by: Lan Tianyu
Signed-off-by: Juan Manuel Cabo
Signed-off-by: Dennis Jansen
Tested-by: Maurizio D'Addona
Tested-by: San Zamoyski
---
  drivers/acpi/ec.c | 61 +++
  1 file changed, 61 insertions(+)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 959d41a..f437d9a 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -67,6 +67,8 @@ enum ec_command {
  #define ACPI_EC_DELAY 500 /* Wait 500ms max. during EC ops */
  #define ACPI_EC_UDELAY_GLK1000/* Wait 1ms max. to get global lock */
  #define ACPI_EC_MSI_UDELAY550 /* Wait 550us for MSI EC */
+#define ACPI_EC_CLEAR_MAX  20  /* Maximum number of events to query
+* when trying to clear the EC */
   


20 is enough?
the query index is length of a byte.



  enum {
EC_FLAGS_QUERY_PENDING, /* Query is pending */
@@ -116,6 +118,7 @@ EXPORT_SYMBOL(first_ec);
  static int EC_FLAGS_MSI; /* Out-of-spec MSI controller */
  static int EC_FLAGS_VALIDATE_ECDT; /* ASUStec ECDTs need to be validated */
  static int EC_FLAGS_SKIP_DSDT_SCAN; /* Not all BIOS survive early DSDT scan */
+static int EC_FLAGS_CLEAR_ON_RESUME; /* EC should be polled on boot/resume */
   


seems name is implicit, what about EC_FLAGS_QEVENT_CLR_ON_RESUME?
seems too long :-)



  /* --
   Transaction Management
@@ -440,6 +443,26 @@ acpi_handle ec_get_handle(void)

  EXPORT_SYMBOL(ec_get_handle);

+static int acpi_ec_query_unlocked(struct acpi_ec *ec, u8 *data);
+
+/* run with locked ec mutex */
+static void acpi_ec_clear(struct acpi_ec *ec)
+{
+   int i, status;
+   u8 value = 0;
+
+   for (i = 0; i<  ACPI_EC_CLEAR_MAX; i++) {
+   status = acpi_ec_query_unlocked(ec,);
+   if (status || !value)
+   break;
+   }
+
+   if (i == ACPI_EC_CLEAR_MAX)
+   pr_warn("Warning: Maximum of %d stale EC events cleared\n", i);
+   else
+   pr_info("%d stale EC events cleared\n", i);
+}
+
  void acpi_ec_block_transactions(void)
  {
struct acpi_ec *ec = first_ec;
@@ -463,6 +486,10 @@ void acpi_ec_unblock_transactions(void)
mutex_lock(>mutex);
/* Allow transactions to be carried out again */
clear_bit(EC_FLAGS_BLOCKED,>flags);
+
+   if (EC_FLAGS_CLEAR_ON_RESUME)
+   acpi_ec_clear(ec);
+
mutex_unlock(>mutex);
  }

@@ -821,6 +848,13 @@ static int acpi_ec_add(struct acpi_device *device)

/* EC is fully operational, allow queries */
clear_bit(EC_FLAGS_QUERY_PENDING,>flags);
+
+   /* Some hardware may need the EC to be cleared before use */
   


description is implicit, should specify what we clear is Q event, not EC.

Thanks!
Li Guang


+   if (EC_FLAGS_CLEAR_ON_RESUME) {
+   mutex_lock(>mutex);
+   acpi_ec_clear(ec);
+   mutex_unlock(>mutex);
+   }
return ret;
  }

@@ -922,6 +956,30 @@ static int ec_enlarge_storm_threshold(const struct 

Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%

[Gene Heskett]

On Wednesday 26 February 2014, Ken Moffat wrote:
>On Wed, Feb 26, 2014 at 08:28:29PM -0500, Gene Heskett wrote:
>> On Wednesday 26 February 2014, Ken Moffat wrote:
>> 
>> I don't have any help to offer Ken, but this walks and quacks much like
>> a duck I'm encountering in 3.13.5, with the backup program amanda,
>> which uses gnu tar.  To facilitate intelligent guesses as to the size
>> of the various levels of backup, amanda does a dummy collection using
>> tar, sent to /dev/null, using only the size it reports on the first
>> pass.  Version 1.22, quite old, works on 3.12.9, but not on 3.13.5.  I
>> have now pulled in, built and installed tar-1.27, and rebuilt amanda
>> to let it know that the tar its using is not in /usr/bin, but in
>> /usr/local/bin.  Next run at 1:30AM
>> 
>> This freeze, using 100% of a core, but causing no visible disk activity
>> has killed my backups 3 nights running.  At this point I've no clue as
>> to the cause, but I will be watching this thread closely, it has a
>> similar description.
>> 
>> Cheers, Gene
>
> My box where I see this is a phenom (my intel is still on 3.13.4),
>and from past threads I suspect yours is as well ?
>
>ؤ¸en

Yes, it is Ken, an old slow 2.1 Ghz 9550 phenom, with 8Gb of ram. 32 bit 
PAE build.  I wonder if that is also connected...  But my crystal ball is 
broke, in addition to the wet ram  starting to rust out.  Can't be the 
years, I've only 40 years practice at being 39. ;-)

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

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

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

linux-next: build failure after merge of the drm-tegra tree

[Stephen Rothwell]

Hi Thierry,

After merging the drm-tegra tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/gpu/drm/tegra/sor.c: In function 'tegra_sor_init':
drivers/gpu/drm/tegra/sor.c:924:22: error: 'TEGRA_OUTPUT_LVDS' undeclared 
(first use in this function)

Caused by commit 765db82ce08a ("drm/tegra: Add eDP support").

I have used the drm-tegra tree from next-20140226 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgpty15miu7cK.pgp
Description: PGP signature

Re: The sheer number of sparse warnings in the kernel

[Peter Hurley]

On 02/26/2014 07:11 PM, H. Peter Anvin wrote:

On 02/26/2014 03:28 PM, Greg KH wrote:


What do we need to do to actually make our tools be able to do work for
us?  Newbie projects to clean up?  Trying to get the larger Linux
companies to put resources on it?


It's not the easiest "newbie" project as usually the first reflex to
"just cast it away" is wrong for a lot of sparse warnings.  I know this
from people trying to fix up the sparse warnings in drivers/staging/



I have seen this phenomenon, too.  I also see a bunch of sparse warnings
which are clearly bogus, for example complaining about sizeof(bool) when
in bits like:

__this_cpu_write(swallow_nmi, false);

So getting this to the point where it is genuinely useful and can be
made a ubiquitous part of the Linux development process is going to take
more work and probably involve improvements to sparse so we can indicate
in the kernel sources when something is okay or removing completely
bogus warnings, and so on.

The bigger question, again, is what do we need to do to make this
happen, assuming it is worth doing?  We certainly have had bugs,
including security holes, which sparse would have caught.  At the same
time, this kind of work tends to not be the kind that attract the top
hackers, unfortunately, as it is not "fun".


Well there was that "should we do a bug-fix-only 4.0 release?" message
from Linus back at the 3.12 release.

Or do like Geert does with the build message regressions/fixes. I always scan
that to make sure none of my work is in it :)  (And that could be chunked
up by maintainer).

Just a thought.

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

[PATCH] ASoC: fsl-sai: Add SND_SOC_DAIFMT_DSP_A/B support.

[Xiubo Li]

o Add SND_SOC_DAIFMT_DSP_A support.
o Add SND_SOC_DAIFMT_DSP_B support.

Signed-off-by: Xiubo Li 
---
 sound/soc/fsl/fsl_sai.c | 45 ++---
 sound/soc/fsl/fsl_sai.h |  1 +
 2 files changed, 43 insertions(+), 3 deletions(-)

diff --git a/sound/soc/fsl/fsl_sai.c b/sound/soc/fsl/fsl_sai.c
index 26d9f5e..c4a4231 100644
--- a/sound/soc/fsl/fsl_sai.c
+++ b/sound/soc/fsl/fsl_sai.c
@@ -108,15 +108,44 @@ static int fsl_sai_set_dai_fmt_tr(struct snd_soc_dai 
*cpu_dai,
/* DAI mode */
switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
case SND_SOC_DAIFMT_I2S:
-   /* Data on rising edge of bclk, frame low, 1clk before data */
+   /*
+* Frame low, 1clk before data, one word length for frame sync,
+* frame sync starts one serial clock cycle earlier,
+* that is, together with the last bit of the previous
+* data word.
+*/
val_cr2 &= ~FSL_SAI_CR2_BCP;
val_cr4 |= FSL_SAI_CR4_FSE | FSL_SAI_CR4_FSP;
break;
case SND_SOC_DAIFMT_LEFT_J:
-   /* Data on rising edge of bclk, frame high, 0clk before data */
+   /*
+* Frame high, one word length for frame sync,
+* frame sync asserts with the first bit of the frame.
+*/
val_cr2 &= ~FSL_SAI_CR2_BCP;
val_cr4 &= ~(FSL_SAI_CR4_FSE | FSL_SAI_CR4_FSP);
break;
+   case SND_SOC_DAIFMT_DSP_A:
+   /*
+* Frame high, 1clk before data, one bit for frame sync,
+* frame sync starts one serial clock cycle earlier,
+* that is, together with the last bit of the previous
+* data word.
+*/
+   val_cr2 &= ~FSL_SAI_CR2_BCP;
+   val_cr4 &= ~FSL_SAI_CR4_FSP;
+   val_cr4 |= FSL_SAI_CR4_FSE;
+   sai->is_dsp_mode = true;
+   break;
+   case SND_SOC_DAIFMT_DSP_B:
+   /*
+* Frame high, one bit for frame sync,
+* frame sync asserts with the first bit of the frame.
+*/
+   val_cr2 &= ~FSL_SAI_CR2_BCP;
+   val_cr4 &= ~(FSL_SAI_CR4_FSE | FSL_SAI_CR4_FSP);
+   sai->is_dsp_mode = true;
+   break;
case SND_SOC_DAIFMT_RIGHT_J:
/* To be done */
default:
@@ -219,7 +248,9 @@ static int fsl_sai_hw_params(struct snd_pcm_substream 
*substream,
val_cr5 &= ~FSL_SAI_CR5_W0W_MASK;
val_cr5 &= ~FSL_SAI_CR5_FBT_MASK;
 
-   val_cr4 |= FSL_SAI_CR4_SYWD(word_width);
+   if (!sai->is_dsp_mode)
+   val_cr4 |= FSL_SAI_CR4_SYWD(word_width);
+
val_cr5 |= FSL_SAI_CR5_WNW(word_width);
val_cr5 |= FSL_SAI_CR5_W0W(word_width);
 
@@ -245,6 +276,10 @@ static int fsl_sai_trigger(struct snd_pcm_substream 
*substream, int cmd,
struct fsl_sai *sai = snd_soc_dai_get_drvdata(cpu_dai);
u32 tcsr, rcsr;
 
+   /*
+* The transmitter bit clock and frame sync are to be
+* used by both the transmitter and receiver.
+*/
regmap_update_bits(sai->regmap, FSL_SAI_TCR2, FSL_SAI_CR2_SYNC,
   ~FSL_SAI_CR2_SYNC);
regmap_update_bits(sai->regmap, FSL_SAI_RCR2, FSL_SAI_CR2_SYNC,
@@ -261,6 +296,10 @@ static int fsl_sai_trigger(struct snd_pcm_substream 
*substream, int cmd,
tcsr &= ~FSL_SAI_CSR_FRDE;
}
 
+   /*
+* It is recommended that the transmitter is the last enabled
+* and the first disabled.
+*/
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_RESUME:
diff --git a/sound/soc/fsl/fsl_sai.h b/sound/soc/fsl/fsl_sai.h
index 1571459..e432260 100644
--- a/sound/soc/fsl/fsl_sai.h
+++ b/sound/soc/fsl/fsl_sai.h
@@ -103,6 +103,7 @@ struct fsl_sai {
 
bool big_endian_regs;
bool big_endian_data;
+   bool is_dsp_mode;
 
struct snd_dmaengine_dai_dma_data dma_params_rx;
struct snd_dmaengine_dai_dma_data dma_params_tx;
-- 
1.8.4


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

Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%

[Ken Moffat]

On Wed, Feb 26, 2014 at 08:28:29PM -0500, Gene Heskett wrote:
> On Wednesday 26 February 2014, Ken Moffat wrote:
> 
> I don't have any help to offer Ken, but this walks and quacks much like a 
> duck I'm encountering in 3.13.5, with the backup program amanda, which uses 
> gnu tar.  To facilitate intelligent guesses as to the size of the various 
> levels of backup, amanda does a dummy collection using tar, sent to 
> /dev/null, using only the size it reports on the first pass.  Version 1.22, 
> quite old, works on 3.12.9, but not on 3.13.5.  I have now pulled in, built 
> and installed tar-1.27, and rebuilt amanda to let it know that the tar its 
> using is not in /usr/bin, but in /usr/local/bin.  Next run at 1:30AM
> 
> This freeze, using 100% of a core, but causing no visible disk activity has 
> killed my backups 3 nights running.  At this point I've no clue as to the 
> cause, but I will be watching this thread closely, it has a similar 
> description.
> 
> Cheers, Gene

 My box where I see this is a phenom (my intel is still on 3.13.4),
and from past threads I suspect yours is as well ?

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] tracepoint: Do not waste memory on mods with no tracepoints

[Steven Rostedt]

On Thu, 27 Feb 2014 11:00:35 +1030
Rusty Russell  wrote:

> Steven Rostedt  writes:
> > No reason to allocate tp_module structures for modules that have no
> > tracepoints. This just wastes memory.
> >
> > Fixes: b75ef8b44b1c "Tracepoint: Dissociate from module mutex"
> > Cc: sta...@vger.kernel.org # 3.2+
> 
> Really?  CC:stable?  To save an insignificant amount of memory?

I agree that this rational alone is not sufficient for stable. But this
is required for another patch that warns when tracepoints are not
loaded by a module due to taints. We don't want to warn on all modules.


> 
> The definition of stable seems to be shifting away from "fixes for
> problems with significant effects".  I obviously missed the memo.

Not telling users that tracepoints were not activated, but acting in
every other way like they are is to me a "significant effect". This
just happened to be something that fixing this depended on.

-- Steve


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

Re: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint code

[Steven Rostedt]

On Wed, 26 Feb 2014 21:36:18 + (UTC)
Mathieu Desnoyers  wrote:

> - Original Message -
> > From: "Steven Rostedt" 
> > To: linux-kernel@vger.kernel.org
> > Cc: "Ingo Molnar" , "Andrew Morton" 
> > , "Peter Zijlstra"
> > , "Frederic Weisbecker" , 
> > "Mathieu Desnoyers"
> > 
> > Sent: Wednesday, February 26, 2014 2:01:40 PM
> > Subject: [RFA][PATCH 0/4] tracing: Request for acks on fixing tracepoint 
> > code
> > 
> > [ Request for Acks ]
> > 
> > Due to module tainting, we have tracepoints that silently do not work.
> > That will be solved another way. But the trace event infrastructure should
> > not be created for tainted modules. That is, the debugfs files should
> > not exist for them.
> > 
> > By moving the tracepoint module taint test into tracepoint.h, we can
> > reuse that same test when creating the module tracepoint events.
> > 
> > Note, I had to remove the tracepoint.h include from module.h as there
> > was nothing in module.h that required tracepoint.h, but this broke
> > a couple of event files (migrate.h and writeback.h) because they did
> > not include tracepoint.h, and were just lucky that it was included
> > by module.h.
> 
> When designing tracepoint.h, a lot of care went into making sure it did
> not have needless dependency on other headers, since this header is
> expected to be included into many other files and headers, thus posing
> a clear risk of becoming yet another root of an include dependency hell.

Well, module.h is included in many more.

> 
> While I agree on adding the API you propose, why made it a static inline ?
> This adds this dependency from tracepoint.h on module.h. Instead, we could
> just declare a symbol, and implement a tracepoint_module_has_bad_taint()
> within kernel/tracepoint.c. It should not be a fast path anyway, so I don't
> see the point it making it a static inline.
> 
> I also recommend sticking to the tracepoint_*() API (rather than trace_*).

Well, as this is now not just for tracepoints, but also used by the
trace_events, and because the name is already too big (but
descriptive), I rather not change it.

But as a compromise, I can move it to ftrace_event.h instead.

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

Re: 3.13 i915 brightness settings broken when going from docked -> undocked

[Josh Boyer]

On Tue, Feb 25, 2014 at 3:36 AM, Jani Nikula  wrote:
> On Sun, 23 Feb 2014, Josh Boyer  wrote:
>> Backport of upstream commit c91c9f328
>>
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h   |  1 +
>>  drivers/gpu/drm/i915/intel_opregion.c | 31 ++-
>>  drivers/gpu/drm/i915/intel_panel.c|  4 
>>  3 files changed, 11 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 221ac62..d6d4349 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1371,6 +1371,7 @@ typedef struct drm_i915_private {
>>
>>   /* backlight */
>>   struct {
>> + bool present;
>>   int level;
>>   bool enabled;
>>   spinlock_t lock; /* bl registers and the above bl fields */
>> diff --git a/drivers/gpu/drm/i915/intel_opregion.c 
>> b/drivers/gpu/drm/i915/intel_opregion.c
>> index 6d69a9b..b2a51ae 100644
>> --- a/drivers/gpu/drm/i915/intel_opregion.c
>> +++ b/drivers/gpu/drm/i915/intel_opregion.c
>> @@ -414,38 +414,19 @@ static u32 asle_set_backlight(struct drm_device *dev, 
>> u32 bclp)
>>   return ASLC_BACKLIGHT_FAILED;
>>
>>   mutex_lock(>mode_config.mutex);
>> - /*
>> -  * Could match the OpRegion connector here instead, but we'd also need
>> -  * to verify the connector could handle a backlight call.
>> -  */
>> - list_for_each_entry(encoder, >mode_config.encoder_list, head)
>> - if (encoder->crtc == crtc) {
>> - found = true;
>> - break;
>> - }
>> -
>> - if (!found) {
>> - ret = ASLC_BACKLIGHT_FAILED;
>> - goto out;
>> - }
>>
>> - list_for_each_entry(connector, >mode_config.connector_list, head)
>> - if (connector->encoder == encoder)
>> - intel_connector = to_intel_connector(connector);
>> -
>> - if (!intel_connector) {
>> - ret = ASLC_BACKLIGHT_FAILED;
>> - goto out;
>> + DRM_DEBUG_KMS("updating opregion backlight %d/255\n", bclp);
>> + list_for_each_entry(connector, >mode_config.connector_list, head) 
>> {
>> + intel_connector = to_intel_connector(connector);
>> + if (dev_priv->backlight.present)
>> + intel_panel_set_backlight(intel_connector, bclp, 255);
>>   }
>
> This is not correct because in v3.13 dev_priv->backlight is still driver
> global, not per connector. This means that if you have at least one
> connector with backlight control, the backlight is attempted to change
> on all connectors. In your case, I'm not sure if it leads to anything
> more than extra adjusting of the same backlight.

Well, empirically it leads to the backlight actually changing after
undocking my machine whereas without it, it doesn't.  So maybe by
changing it globally, it is hitting the connector that does have
backlight control.

Anyway, I'm not arguing my patch is correct.  Just that it does do
_something_ to make the backlight work :).

> If you move the 'bool present' field to intel_connector or intel_panel,
> I think this is all right.

That sounds like more of an invasive change.  I could poke at it, but
I'm not sure it would be suitable for e.g. 3.13.y stable.  Thoughts on
that?  Admittedly it is a somewhat minor problem, so if it's not
easily stable material, I don't think anyone is going to lose sleep
over it.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 09/26] arm: mmp: Remove pointless fiddling with irq internals

[Chao Xie]

On Mon, Feb 24, 2014 at 7:31 PM, Thomas Gleixner  wrote:
> On Mon, 24 Feb 2014, Haojian Zhuang wrote:
>
>> On Mon, Feb 24, 2014 at 2:07 PM, Chao Xie  wrote:
>> > On Mon, Feb 24, 2014 at 7:17 AM, Uwe Kleine-König
>> >  wrote:
>> >> Hi Thomas,
>> >>
>> >> On Sun, Feb 23, 2014 at 09:40:13PM -, Thomas Gleixner wrote:
>> >>> The pm-mmp2 and pm-pxa910 power management related irq_set_wake
>> >>> callbacks fiddle pointlessly with the irq actions for no reason except
>> >>> for lack of understanding how the wakeup mechanism works.
>> >>>
>> >>> On supsend the core disables all interrupts lazily, i.e. it does not
>> >>> mask them at the irq controller level. So any interrupt which is
>> >>> firing during supsend will mark the corresponding interrupt line as
>> >> s/supsend/suspend/ twice
>> >>> pending. Just before the core powers down it checks whether there are
>> >>> interrupts pending from interrupt lines which are marked as wakeup
>> >>> sources and if so it aborts the resume and resends the interrupts.
>> >> It's the suspend that is aborted, not the resume.
>> >>
>> >> Other than that your change looks fine.
>> >>
>> > For pxa910 and MMP2, wake up source only wake up the AP subsystem.
>> > The AP subsystem includes the APMU(AP Power Mangament Unit) and cores.
>> > Now the core is still powered down. APMU will check the interrupt
>> > lines, and find
>> > that there are interrupt pending, it will power on the cores.
>> > So if the irq is disabled, even wake up source can wake up AP subsystem, 
>> > but the
>> > core is still powered down. It will not be powered up by APMU.
>> >
>>
>> Yes, suspend/resume can't work if the above code is removed.
>>
>> Interrupt source (logic AND with interrupt mask register) is connected
>> to MPMU as
>> wakeup source. If the interrupt is disabled, there's no wakeup source event.
>>
>> And APMU is waken up by MPMU.
>>
>> So please don't remove the above code. We must keep these interrupt lines 
>> active
>> to wake up the whole system.
>
> They are kept active at the interrupt controller level. You just
> refuse to understand how the internals of the interrupt subsystem
> work.
>
If no irq_disable callback is hooked, when do irq_disable, it will not
actually disable
the interrupt, it will depend on next time when the irq happens, the
handler will first mask
the interrupt as this interrupt never happens.
So after system suspended, the interrupt happens, but the device
driver will not recieve this interrupt
because it is masked.
It results in that the device driver miss a important interrupt which
related to something need to be
handled. If user application for example android has power managment
daemon. It will find that nothing
to handle, it will make the system enter suspend again.

> And even if you would need this flag, then fiddling with the irq desc
> internals is a big NONO. There is a proper way to hand that in.
>

So can you suggest the proper way to handle it? Thanks.

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

[PATCH] err.h: Use bool for IS_ERR and IS_ERR_OR_NULL

[Joe Perches]

Use the more natural return of bool for these tests.

No difference observed in .o files produced by gcc
for x86.

Remove the dentry description of kernel pointers
left over from the 90's and 2002's cleanup move
of parts of fs.h to err.h.

Signed-off-by: Joe Perches 
---
 include/linux/err.h | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/include/linux/err.h b/include/linux/err.h
index 15f92e0..a729120 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -2,12 +2,13 @@
 #define _LINUX_ERR_H
 
 #include 
+#include 
 
 #include 
 
 /*
  * Kernel pointers have redundant information, so we can use a
- * scheme where we can return either an error code or a dentry
+ * scheme where we can return either an error code or a normal
  * pointer with the same return value.
  *
  * This should be a per-architecture thing, to allow different
@@ -29,12 +30,12 @@ static inline long __must_check PTR_ERR(__force const void 
*ptr)
return (long) ptr;
 }
 
-static inline long __must_check IS_ERR(__force const void *ptr)
+static inline bool __must_check IS_ERR(__force const void *ptr)
 {
return IS_ERR_VALUE((unsigned long)ptr);
 }
 
-static inline long __must_check IS_ERR_OR_NULL(__force const void *ptr)
+static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
 {
return !ptr || IS_ERR_VALUE((unsigned long)ptr);
 }


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

Re: [PATCH v2 1/1] arm64: make a single hook to syscall_trace() for all syscall features

[AKASHI Takahiro]

On 02/26/2014 08:25 PM, Will Deacon wrote:

On Wed, Feb 26, 2014 at 02:00:19AM +, AKASHI Takahiro wrote:

On 02/26/2014 12:00 AM, Will Deacon wrote:

On Tue, Feb 25, 2014 at 09:14:43AM +, AKASHI Takahiro wrote:

Currently syscall_trace() is called only for ptrace.
With additional TIF_xx flags defined, it is now called in all the cases
of audit, ftrace and seccomp in addition to ptrace.

Signed-off-by: AKASHI Takahiro 
Acked-by: Richard Guy Briggs 
---
   arch/arm64/include/asm/thread_info.h |   13 ++
   arch/arm64/kernel/entry.S|5 ++--
   arch/arm64/kernel/ptrace.c   |   45 
+-
   3 files changed, 38 insertions(+), 25 deletions(-)


[...]


diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 6a8928b..c70133e 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -1062,31 +1062,30 @@ asmlinkage int syscall_trace(int dir, struct pt_regs 
*regs)
   {
unsigned long saved_reg;

-   if (!test_thread_flag(TIF_SYSCALL_TRACE))
-   return regs->syscallno;
-
-   if (is_compat_task()) {
-   /* AArch32 uses ip (r12) for scratch */
-   saved_reg = regs->regs[12];
-   regs->regs[12] = dir;
-   } else {
-   /*
-* Save X7. X7 is used to denote syscall entry/exit:
-*   X7 = 0 -> entry, = 1 -> exit
-*/
-   saved_reg = regs->regs[7];
-   regs->regs[7] = dir;
-   }
+   if (test_thread_flag(TIF_SYSCALL_TRACE)) {
+   if (is_compat_task()) {
+   /* AArch32 uses ip (r12) for scratch */
+   saved_reg = regs->regs[12];
+   regs->regs[12] = dir;
+   } else {
+   /*
+* Save X7. X7 is used to denote syscall entry/exit:
+*   X7 = 0 -> entry, = 1 -> exit
+*/
+   saved_reg = regs->regs[7];
+   regs->regs[7] = dir;
+   }

-   if (dir)
-   tracehook_report_syscall_exit(regs, 0);
-   else if (tracehook_report_syscall_entry(regs))
-   regs->syscallno = ~0UL;
+   if (dir)
+   tracehook_report_syscall_exit(regs, 0);
+   else if (tracehook_report_syscall_entry(regs))
+   regs->syscallno = ~0UL;

-   if (is_compat_task())
-   regs->regs[12] = saved_reg;
-   else
-   regs->regs[7] = saved_reg;
+   if (is_compat_task())
+   regs->regs[12] = saved_reg;
+   else
+   regs->regs[7] = saved_reg;
+   }


Aren't these changes (to ptrace.c) just a giant NOP?


Umm, the purpose of this big "if" is to run the code only if TIF_SYSCALL_TRACE 
is set,
and to make it easy to add additional hooks, audit and ftrace, around 
tracehook_report_*()
later on.


The existing code already checks TIF_SYSCALL_TRACE. I'd rather you added
this new code when it's actually nedded (e.g. when adding audit on top).


* This patch is required only if you really merge my audit and/or ftrace patch.
* Putting these changes in audit patch would impose an extra (unnecessary) 
dependency on ftrace patch.
* Putting them both in audit and ftrace patch would cause a conflict when 
applying both patches.

Even so, since I don't bother you on this minor issue, I will follow your 
comment and make changes on:
* arm64: make a single hook to syscall_trace() for all syscall features
* arm64: Add audit support
* arm64: Add ftrace support

-Takahiro AKASHI


Will


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] ARM: S3C24XX: select COMMON_CLK_SAMSUNG for S3C24XX

[Pankaj Dubey]

On 02/27/2014 09:16 AM, Mike Turquette wrote:

Quoting Pankaj Dubey (2014-02-25 21:24:07)

CC: Ben Dooks 
CC: Kukjin Kim 
CC: Russell King 
Signed-off-by: Pankaj Dubey 
---
  arch/arm/mach-s3c24xx/Kconfig |3 +++
  1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index 80373da..5cf82a1 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -40,6 +40,7 @@ config CPU_S3C2410
  config CPU_S3C2412
 bool "SAMSUNG S3C2412"
 select COMMON_CLK
+   select COMMON_CLK_SAMSUNG

I guess this depends on Heiko's "[PATCH 00/12] ARM: S3C24XX: convert
s3c2410, s3c2440 s3c2442 to common clock framework" series?

Regards,
Mike


Yes, this series is based on latest kgene/for-next branch where Heiko's 
series is merged.



 select CPU_ARM926T
 select CPU_LLSERIAL_S3C2440
 select S3C2412_COMMON_CLK
@@ -51,6 +52,7 @@ config CPU_S3C2412
  config CPU_S3C2416
 bool "SAMSUNG S3C2416/S3C2450"
 select COMMON_CLK
+   select COMMON_CLK_SAMSUNG
 select CPU_ARM926T
 select CPU_LLSERIAL_S3C2440
 select S3C2416_PM if PM
@@ -89,6 +91,7 @@ config CPU_S3C244X
  config CPU_S3C2443
 bool "SAMSUNG S3C2443"
 select COMMON_CLK
+   select COMMON_CLK_SAMSUNG
 select CPU_ARM920T
 select CPU_LLSERIAL_S3C2440
 select S3C2443_COMMON_CLK
--
1.7.9.5


___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
Best Regards,
Pankaj Dubey

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 0/10] fs: Introduce new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate

[Hugh Dickins]

On Thu, 27 Feb 2014, Dave Chinner wrote:
> On Wed, Feb 26, 2014 at 03:08:58PM -0800, Hugh Dickins wrote:
> > 
> > Thanks for explaining more, I was just about to acknowledge what a good
> > example that is.  Indeed, it seems not unreasonable to be editing the
> > earlier part of a file while the later part of it is still streaming in.
> > 
> > But damn, it now occurs to me that there's still a problem at the
> > streaming end: its file write offset won't be updated to reflect
> > the collapse, so there would be a sparse hole at that end.  And
> > collapse returns -EPERM if IS_APPEND(inode).
> 
> Well, we figure that most applications won't be using append only
> inode flags for files that they know they want to edit at random
> offsets later on. ;)
> 
> However, I can see how DVR apps would use open(O_APPEND) to obtain
> the fd they write to because that sets the write position to the EOF
> on every write() call (i.e. in generic_write_checks()). And collapse
> range should behave sanely with this sort of usage.
> 
> e.g. XFS calls generic_write_checks() after it has taken the IO lock
> to set the current write position to EOF. Hence it will be correctly
> serialised against collapse range calls and so O_APPEND writes will
> not leave sparse holes if collapse range calls are interleaved with
> the write stream

Right, I was getting confused between O_APPEND and APPEND_Only!
Thanks, I'm back to being convinced by your example.

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

Re: The sheer number of sparse warnings in the kernel

[Greg KH]

On Wed, Feb 26, 2014 at 04:11:30PM -0800, H. Peter Anvin wrote:
> On 02/26/2014 03:28 PM, Greg KH wrote:
> >>
> >> What do we need to do to actually make our tools be able to do work for
> >> us?  Newbie projects to clean up?  Trying to get the larger Linux
> >> companies to put resources on it?
> > 
> > It's not the easiest "newbie" project as usually the first reflex to
> > "just cast it away" is wrong for a lot of sparse warnings.  I know this
> > from people trying to fix up the sparse warnings in drivers/staging/
> > 
> 
> I have seen this phenomenon, too.  I also see a bunch of sparse warnings
> which are clearly bogus, for example complaining about sizeof(bool) when
> in bits like:
> 
>   __this_cpu_write(swallow_nmi, false);
> 
> So getting this to the point where it is genuinely useful and can be
> made a ubiquitous part of the Linux development process is going to take
> more work and probably involve improvements to sparse so we can indicate
> in the kernel sources when something is okay or removing completely
> bogus warnings, and so on.

Yes, for some areas of the kernel it will take some work, but for
others, sparse works really well.  As an example, building all of
drivers/usb/* with sparse only brings up 2 issues, both of which should
probably be fixed (or annotated properly in the case of the locking
warning.)  So keeping things "sparse clean" there is quite easy and part
of taking new patches.

> The bigger question, again, is what do we need to do to make this
> happen, assuming it is worth doing?  We certainly have had bugs,
> including security holes, which sparse would have caught.  At the same
> time, this kind of work tends to not be the kind that attract the top
> hackers, unfortunately, as it is not "fun".

I guess the first thing would be to do is look to try to fix things like
the "bool" issue you have here.  And just grind away at the issues, one
by one.  Some of us like doing those types of things, so I'm sure you
can find people willing to do it if you get the word out.

Once we hit a "tipping point" of the kernel being almost sparse clean,
having the main subsystem maintainers always run it would be good.  I
know the 0-day bot runs it, as I get patches all the time from it to fix
up some sparse warnings.

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

Re: 3.13.5 : rm -rf running forever, one cpu at approx 100%

[Gene Heskett]

On Wednesday 26 February 2014, Ken Moffat wrote:
>Hi,
>
> Short summary : on 3.13.5, rm -rf of an application source
>directory on an ext4 filesystem sometimes takes forever (probably
>isn't going anywhere), with one CPU pegged at all-but 100% utilization.
>
> I've nearly finished building a new system from source, to check
>various desktop packages in linuxfromscratch.  On this build, much of
>it is things I don't normally use and I needed to upgrade my
>buildscripts, so most of it was built in chroot using 3.10.32.  But
>late last night I booted the new system using 3.13.5 to finish the
>build.  This morning I discovered that rm -rf for the icedtea source
>directory was still running, and had taken over 5 hours of CPU time
>(one CPU seemd to be running at close to 100%, the others had dropped
>to their slowest frequency).  That script was running as root (yeah,
>but it's a new system) and it looks as if /etc/passwd~ had got
>trashed, because I could no longer su or login.  Not sure if that is
>related, at this stage it might just be a side-effect of my scripts.
>
> Booted another system, chrooted, fixed up passwords.  Started
>again after commenting out icedtea - I hadn't intended to build
>what was an old version, I'd just forgotten it was in this script -
>that's why I do things in userspace, not the kernel :-(
>
> Continued with remaining packages, but a couple of hours later I
>saw a similar "one CPU at 100%, rm -rf GConf source taking forever"
>problem.  Dumped all the processes with Alt-SysRQ-T [ huge log ] but
>at that point 'rm' was merely 'ready' so I doubt there is anything
>useful to see in the log.
>
> Built 3.13.4, booted to that.  So far, everything looks good - but
>I'm now building the _current_ version of icedtea, so if this isn't
>a new 3.13.5 problem I guess I'm fairly likely to see it tomorrow.
>
> Meanwhile, any suggestions about how I can debug this if I hit it
>again, please ?
>
>ؤ¸en

I don't have any help to offer Ken, but this walks and quacks much like a 
duck I'm encountering in 3.13.5, with the backup program amanda, which uses 
gnu tar.  To facilitate intelligent guesses as to the size of the various 
levels of backup, amanda does a dummy collection using tar, sent to 
/dev/null, using only the size it reports on the first pass.  Version 1.22, 
quite old, works on 3.12.9, but not on 3.13.5.  I have now pulled in, built 
and installed tar-1.27, and rebuilt amanda to let it know that the tar its 
using is not in /usr/bin, but in /usr/local/bin.  Next run at 1:30AM

This freeze, using 100% of a core, but causing no visible disk activity has 
killed my backups 3 nights running.  At this point I've no clue as to the 
cause, but I will be watching this thread closely, it has a similar 
description.

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

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

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

Re: [PATCH v5 0/10] fs: Introduce new flag(FALLOC_FL_COLLAPSE_RANGE) for fallocate

[Dave Chinner]

On Wed, Feb 26, 2014 at 03:08:58PM -0800, Hugh Dickins wrote:
> On Wed, 26 Feb 2014, Dave Chinner wrote:
> > On Tue, Feb 25, 2014 at 08:45:15PM -0800, Hugh Dickins wrote:
> > > On Wed, 26 Feb 2014, Dave Chinner wrote:
> > > > On Tue, Feb 25, 2014 at 03:23:35PM -0800, Hugh Dickins wrote:
> > > > 
> > > > > I should mention that when "we" implemented this thirty years ago,
> > > > > we had a strong conviction that the system call should be idempotent:
> > > > > that is, the len argument should indicate the final i_size, not the
> > > > > amount being removed from it.  Now, I don't remember the grounds for
> > > > > that conviction: maybe it was just an idealistic preference for how
> > > > > to design a good system call.  I can certainly see that defining it
> > > > > that way round would surprise many app programmers.  Just mentioning
> > > > > this in case anyone on these lists sees a practical advantage to
> > > > > doing it that way instead.
> > > > 
> > > > I don't see how specifying the end file size as an improvement. What
> > > > happens if you are collapse a range in a file that is still being
> > > > appended to by the application and so you race with a file size
> > > > update? IOWs, with such an API the range to be collapsed is
> > > > completely unpredictable, and IMO that's a fundamentally broken API.
> > > 
> > > That's fine if you don't see the idempotent API as an improvement,
> > > I just wanted to put it on the table in case someone does see an
> > > advantage to it.  But I think I'm missing something in your race
> > > example: I don't see a difference between the two APIs there.
> > 
> > 
> > Userspace can't sample the inode size via stat(2) and then use the value 
> > for a
> > syscall atomically. i.e. if you specify the offset you want to
> > collapse at, and the file size you want to have to define the region
> > to collapse, then the length you need to collapse is (current inode
> > size - end file size). If "current inode size" can change between
> > the stat(2) and fallocate() call (and it can), then the length being
> > collapsed is indeterminate
> 
> Thanks for explaining more, I was just about to acknowledge what a good
> example that is.  Indeed, it seems not unreasonable to be editing the
> earlier part of a file while the later part of it is still streaming in.
> 
> But damn, it now occurs to me that there's still a problem at the
> streaming end: its file write offset won't be updated to reflect
> the collapse, so there would be a sparse hole at that end.  And
> collapse returns -EPERM if IS_APPEND(inode).

Well, we figure that most applications won't be using append only
inode flags for files that they know they want to edit at random
offsets later on. ;)

However, I can see how DVR apps would use open(O_APPEND) to obtain
the fd they write to because that sets the write position to the EOF
on every write() call (i.e. in generic_write_checks()). And collapse
range should behave sanely with this sort of usage.

e.g. XFS calls generic_write_checks() after it has taken the IO lock
to set the current write position to EOF. Hence it will be correctly
serialised against collapse range calls and so O_APPEND writes will
not leave sparse holes if collapse range calls are interleaved with
the write stream

Cheers,

Dave.

-- 
Dave Chinner
da...@fromorbit.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: The sheer number of sparse warnings in the kernel

[H. Peter Anvin]

That would be good.

On February 26, 2014 5:19:51 PM PST, Josh Boyer  
wrote:
>On Wed, Feb 26, 2014 at 6:37 PM, H. Peter Anvin  wrote:
>> On 02/26/2014 03:31 PM, H. Peter Anvin wrote:
>>> On 02/26/2014 03:29 PM, Greg KH wrote:
 On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote:
> On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote:
>> The number of sparse errors in the current kernel is staggering,
>and it
>> makes sparse a lot less valuable of a tool that it otherwise
>could be.
>> On a build of x86-64 allyesconfig I'm getting 20,676 sparse
>messages.
>> Out of those, 12,358 come from linux/err.h.  Given that the
>latter
>> basically spams *everything*, I can only conclude that almost
>noone uses
>> sparse unless they have a filter script.
>
> What errors are you seeing from err.h?  I don't see those when
>building
> different subdirectories with sparse (which is how I normally use
>it.)
>
> And what version of sparse are you running:
> $ sparse --version
> v0.4.5-rc1-407-g345e8943fc36

 Ah, 0.5.0 is now out, maybe you should update to that version?

>>>
>>> Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed
>out
>>> of date.  With 0.5.0 I "only" see 8,207 messages, which means that
>at
>>> least the linux/err.h issue is gone.
>>>
>>
>> For what it's worth, the rpm is called sparse-0.4.5.rc1-2.fc19.x86_64
>> and sparse --version reports 0.4.4...
>
>Fedora rawhide has sparse-0.5.0-1.fc21.  If it matters, we could
>probably update F20 and F19 with that.
>
>josh

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

Re: The sheer number of sparse warnings in the kernel

[Josh Boyer]

On Wed, Feb 26, 2014 at 6:37 PM, H. Peter Anvin  wrote:
> On 02/26/2014 03:31 PM, H. Peter Anvin wrote:
>> On 02/26/2014 03:29 PM, Greg KH wrote:
>>> On Wed, Feb 26, 2014 at 03:28:59PM -0800, Greg KH wrote:
 On Wed, Feb 26, 2014 at 02:49:26PM -0800, H. Peter Anvin wrote:
> The number of sparse errors in the current kernel is staggering, and it
> makes sparse a lot less valuable of a tool that it otherwise could be.
> On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages.
> Out of those, 12,358 come from linux/err.h.  Given that the latter
> basically spams *everything*, I can only conclude that almost noone uses
> sparse unless they have a filter script.

 What errors are you seeing from err.h?  I don't see those when building
 different subdirectories with sparse (which is how I normally use it.)

 And what version of sparse are you running:
 $ sparse --version
 v0.4.5-rc1-407-g345e8943fc36
>>>
>>> Ah, 0.5.0 is now out, maybe you should update to that version?
>>>
>>
>> Yes... it looks like the 0.4.5-rc1 that shipped in Fedora is indeed out
>> of date.  With 0.5.0 I "only" see 8,207 messages, which means that at
>> least the linux/err.h issue is gone.
>>
>
> For what it's worth, the rpm is called sparse-0.4.5.rc1-2.fc19.x86_64
> and sparse --version reports 0.4.4...

Fedora rawhide has sparse-0.5.0-1.fc21.  If it matters, we could
probably update F20 and F19 with that.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / EC: Clear stale EC events on Samsung systems

[Kieran Clancy]

On Thu, Feb 27, 2014 at 11:46 AM, Rafael J. Wysocki  wrote:
> On Thursday, February 27, 2014 11:29:53 AM Kieran Clancy wrote:
>>
>> Oh, and I should add that Juan and Dennis both helped to test the
>> patch extensively.
>
> You can use Tested-by or Reported-and-tested-by for that.

Is it okay to have someone listed as both 'Reviewed-by' and
'Tested-by', or both 'Suggested-by' and 'Tested-by'?

Thank you for your help. Once I fix up these things, I will send a patch v2.

Kieran.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: The sheer number of sparse warnings in the kernel

[Joe Perches]

On Wed, 2014-02-26 at 16:51 -0800, H. Peter Anvin wrote:
> On 02/26/2014 04:48 PM, Joe Perches wrote:
> > err.h could also return bool instead of long for the
> > IS_ERR and IS_ERR_OR_NULL tests.
> 
> This is definitely true... although we should check that that doesn't
> make the code worse as this is used *all over* the kernel.

I tested using arch/x86/crypto/ x86-64 and 32
and there are no .o file differences using
bool or long via objdump -d new and old

> > Maybe something like this could be useful.
> > 
> > Shut up the unsigned<->signed pointer conversions
> > and implicit conversions in the Makefile.
> 
> Sounds like two separate patches to me.

Yeah, it was just for discussion.

I think gcc 4.8 is overly noisy about those 2.


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

[PATCH 2/2] x86: Inline the CLOCK_MONOTONIC vdso code

[Andy Lutomirski]

This saves a nanosecond or so on my box.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/vdso/vclock_gettime.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 260a422..9234c83 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -263,7 +263,7 @@ notrace static int __always_inline do_realtime(struct 
timespec *ts)
return mode;
 }
 
-notrace static int do_monotonic(struct timespec *ts)
+notrace static int __always_inline do_monotonic(struct timespec *ts)
 {
unsigned long seq;
u64 ns;
-- 
1.8.5.3

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

[PATCH 0/2] Improvements/fixes to 32-bit vdso timing

[Andy Lutomirski]

hpa, please either nuke x86/vdso or apply these.  That branch is
certainly *not* ready for merging, but this gets it a little closer.

Andy Lutomirski (2):
  x86: Mark __vdso entries as asmlinkage
  x86: Inline the CLOCK_MONOTONIC vdso code

 arch/x86/vdso/vclock_gettime.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

-- 
1.8.5.3

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

[PATCH 1/2] x86: Mark __vdso entries as asmlinkage

[Andy Lutomirski]

This makes no difference for 64-bit, bit it's critical for 32-bit code:
these functions are called from outside the kernel, so they need to comply
with the ABI.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/vdso/vclock_gettime.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/x86/vdso/vclock_gettime.c b/arch/x86/vdso/vclock_gettime.c
index 82e..260a422 100644
--- a/arch/x86/vdso/vclock_gettime.c
+++ b/arch/x86/vdso/vclock_gettime.c
@@ -25,9 +25,9 @@
 
 #define gtod ((vsyscall_gtod_data))
 
-extern int __vdso_clock_gettime(clockid_t clock, struct timespec *ts);
-extern int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz);
-extern time_t __vdso_time(time_t *t);
+extern asmlinkage int __vdso_clock_gettime(clockid_t clock, struct timespec 
*ts);
+extern asmlinkage int __vdso_gettimeofday(struct timeval *tv, struct timezone 
*tz);
+extern asmlinkage time_t __vdso_time(time_t *t);
 
 #ifdef CONFIG_HPET_TIMER
 static inline u32 read_hpet_counter(const volatile void *addr)
@@ -304,7 +304,7 @@ notrace static void do_monotonic_coarse(struct timespec *ts)
} while (unlikely(gtod_read_retry(gtod, seq)));
 }
 
-notrace int __vdso_clock_gettime(clockid_t clock, struct timespec *ts)
+notrace asmlinkage int __vdso_clock_gettime(clockid_t clock, struct timespec 
*ts)
 {
switch (clock) {
case CLOCK_REALTIME:
@@ -332,7 +332,7 @@ fallback:
 int clock_gettime(clockid_t, struct timespec *)
__attribute__((weak, alias("__vdso_clock_gettime")));
 
-notrace int __vdso_gettimeofday(struct timeval *tv, struct timezone *tz)
+notrace asmlinkage int __vdso_gettimeofday(struct timeval *tv, struct timezone 
*tz)
 {
if (likely(tv != NULL)) {
if (unlikely(do_realtime((struct timespec *)tv) == VCLOCK_NONE))
@@ -353,7 +353,7 @@ int gettimeofday(struct timeval *, struct timezone *)
  * This will break when the xtime seconds get inaccurate, but that is
  * unlikely
  */
-notrace time_t __vdso_time(time_t *t)
+notrace asmlinkage time_t __vdso_time(time_t *t)
 {
/* This is atomic on x86 so we don't need any locks. */
time_t result = ACCESS_ONCE(gtod->wall_time_sec);
-- 
1.8.5.3

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

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Rafael J. Wysocki]

On Thursday, February 27, 2014 11:29:53 AM Kieran Clancy wrote:
> On Thu, Feb 27, 2014 at 11:15 AM, Kieran Clancy  
> wrote:
> >
> > I am the primary author, but I based the loop which calls
> > acpi_ec_query_unlocked() on a patch by Lan Tianyu. Juan provided the
> > initial idea (userspace workaround), and Dennis and Lan Tianyu
> > reviewed and suggested some changes to the code.
> 
> Oh, and I should add that Juan and Dennis both helped to test the
> patch extensively.

You can use Tested-by or Reported-and-tested-by for that.

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Rafael J. Wysocki]

On Thursday, February 27, 2014 11:15:05 AM Kieran Clancy wrote:
> On Thu, Feb 27, 2014 at 10:15 AM, Rafael J. Wysocki  
> wrote:
> > On Thursday, February 27, 2014 02:12:40 AM Kieran Clancy wrote:
> >> Signed-off-by: Kieran Clancy 
> >> Signed-off-by: Lan Tianyu 
> >> Signed-off-by: Juan Manuel Cabo 
> >> Signed-off-by: Dennis Jansen 
> >
> > There are too many sign-offs under this patch.  I suppose some of them
> > should be Acked-by or Reviewed-by.
> >
> > Are you the author?
> 
> Sorry about that, I wasn't sure of the best way to acknowledge the
> people involved.
> 
> I am the primary author, but I based the loop which calls
> acpi_ec_query_unlocked() on a patch by Lan Tianyu. Juan provided the
> initial idea (userspace workaround), and Dennis and Lan Tianyu
> reviewed and suggested some changes to the code.
> 
> What would you usually do this kind of situation?

I usually add acknowledgements to the changelog without using any tags,
like "This patch is based on previous work by ."  And then you
can give a link to that work in References:.

> I suppose I could put something such as:
>
> Signed-off-by: Kieran Clancy 
> Signed-off-by: Lan Tianyu 
> Suggested-by: Juan Manuel Cabo 
> Reviewed-by: Lan Tianyu 
> Reviewed-by: Dennis Jansen 
> 
> Would this be preferable?

Yes, that'd be fine by me.

Thanks!

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ACPI / EC: Clear stale EC events on Samsung systems

[Kieran Clancy]

On Thu, Feb 27, 2014 at 11:15 AM, Kieran Clancy  wrote:
>
> I am the primary author, but I based the loop which calls
> acpi_ec_query_unlocked() on a patch by Lan Tianyu. Juan provided the
> initial idea (userspace workaround), and Dennis and Lan Tianyu
> reviewed and suggested some changes to the code.

Oh, and I should add that Juan and Dennis both helped to test the
patch extensively.

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

Re: [PATCH v2 1/2] [media] rtl28xxu: add USB ID for Genius TVGo DVB-T03

[Antti Palosaari]

Applied, thanks!
Antti

On 26.02.2014 20:33, Jan Vcelak wrote:

0458:707f KYE Systems Corp. (Mouse Systems) TVGo DVB-T03 [RTL2832]

The USB dongle uses RTL2832U demodulator and FC0012 tuner.

Signed-off-by: Jan Vcelak 
---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index fda5c64..b9eb662 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1429,6 +1429,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
_props, "Leadtek WinFast DTV Dongle mini", NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_CPYTO_REDI_PC50A,
_props, "Crypto ReDi PC 50 A", NULL) },
+   { DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
+   _props, "Genius TVGo DVB-T03", NULL) },

{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
_props, "Astrometa DVB-T2", NULL) },




--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] [media] rtl28xxu: add chipset version comments into device list

[Antti Palosaari]

Applied, thanks!
Antti

On 26.02.2014 20:33, Jan Vcelak wrote:

Signed-off-by: Jan Vcelak 
---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index b9eb662..ab1deac 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1382,6 +1382,7 @@ static const struct dvb_usb_device_properties 
rtl2832u_props = {
  };

  static const struct usb_device_id rtl28xxu_id_table[] = {
+   /* RTL2831U devices: */
{ DVB_USB_DEVICE(USB_VID_REALTEK, USB_PID_REALTEK_RTL2831U,
_props, "Realtek RTL2831U reference design", NULL) },
{ DVB_USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_FREECOM_DVBT,
@@ -1389,6 +1390,7 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_FREECOM_DVBT_2,
_props, "Freecom USB2.0 DVB-T", NULL) },

+   /* RTL2832U devices: */
{ DVB_USB_DEVICE(USB_VID_REALTEK, 0x2832,
_props, "Realtek RTL2832U reference design", NULL) },
{ DVB_USB_DEVICE(USB_VID_REALTEK, 0x2838,
@@ -1432,6 +1434,7 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
_props, "Genius TVGo DVB-T03", NULL) },

+   /* RTL2832P devices: */
{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
_props, "Astrometa DVB-T2", NULL) },
{ }




--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Final: Add 32 bit VDSO time function support

[Andy Lutomirski]

Um.  This code doesn't work.  I'll send a patch.  I can't speak
towards how well it compiles in different configurations.

I can't speak towards how well it compiles in different
configurations.  Also, vdso_fallback_gettime needs .cfi annotations, I
think.  I could probably dredge the required incantations from
somewhere, but someone else may know how to do it.

Once I patch it to work, your 32-bit code is considerably faster than
the 64-bit case.  It's enough faster that I suspect a bug.  Dumping
the in-memory shows some rather suspicious nops before the rdtsc
instruction.  I suspect that you've forgotten to run the 32-bit vdso
through the alternatives code.  The is a nasty bug: it will appear to
work, but you'll see non-monotonic times on some SMP systems.

In my configuration, with your patches, I get (64-bit):

CLOCK_REALTIME:
1 loops in 2.07105s = 20.71 nsec / loop
1 loops in 2.06874s = 20.69 nsec / loop
1 loops in 2.29415s = 22.94 nsec / loop
CLOCK_MONOTONIC:
1 loops in 2.06526s = 20.65 nsec / loop
1 loops in 2.10134s = 21.01 nsec / loop
1 loops in 2.10615s = 21.06 nsec / loop
CLOCK_REALTIME_COARSE:
1 loops in 0.37440s = 3.74 nsec / loop
[  503.011756] perf samples too long (2550 > 2500), lowering
kernel.perf_event_max_sample_rate to 5
1 loops in 0.37399s = 3.74 nsec / loop
1 loops in 0.38445s = 3.84 nsec / loop
CLOCK_MONOTONIC_COARSE:
1 loops in 0.40238s = 4.02 nsec / loop
1 loops in 0.40939s = 4.09 nsec / loop
1 loops in 0.41152s = 4.12 nsec / loop

Without the patches, I get:

CLOCK_REALTIME:
1 loops in 2.07348s = 20.73 nsec / loop
1 loops in 2.07346s = 20.73 nsec / loop
1 loops in 2.06922s = 20.69 nsec / loop
CLOCK_MONOTONIC:
1 loops in 1.98955s = 19.90 nsec / loop
1 loops in 1.98895s = 19.89 nsec / loop
1 loops in 1.98881s = 19.89 nsec / loop
CLOCK_REALTIME_COARSE:
1 loops in 0.37462s = 3.75 nsec / loop
1 loops in 0.37460s = 3.75 nsec / loop
1 loops in 0.37428s = 3.74 nsec / loop
CLOCK_MONOTONIC_COARSE:
1 loops in 0.40081s = 4.01 nsec / loop
1 loops in 0.39834s = 3.98 nsec / loop
[   36.706696] perf samples too long (2565 > 2500), lowering
kernel.perf_event_max_sample_rate to 5
1 loops in 0.39949s = 3.99 nsec / loop

This looks like a wash, except for CLOCK_MONOTONIC, which got a bit
slower.  I'll send a followup patch once the bugs are fixed that
improves the timings to:

CLOCK_REALTIME:
1 loops in 2.08621s = 20.86 nsec / loop
1 loops in 2.07122s = 20.71 nsec / loop
1 loops in 2.07089s = 20.71 nsec / loop
CLOCK_MONOTONIC:
1 loops in 2.06831s = 20.68 nsec / loop
1 loops in 2.06862s = 20.69 nsec / loop
1 loops in 2.06195s = 20.62 nsec / loop
CLOCK_REALTIME_COARSE:
1 loops in 0.37274s = 3.73 nsec / loop
1 loops in 0.37247s = 3.72 nsec / loop
1 loops in 0.37234s = 3.72 nsec / loop
CLOCK_MONOTONIC_COARSE:
1 loops in 0.39944s = 3.99 nsec / loop
1 loops in 0.39940s = 3.99 nsec / loop
1 loops in 0.40054s = 4.01 nsec / loop

I'm not quite sure that causes the remaining loss.

Test code is here:

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

Re: [RFC][PATCH 0/5] arch: atomic rework

[Torvald Riegel]

On Wed, 2014-02-26 at 18:43 +, Joseph S. Myers wrote:
> On Wed, 26 Feb 2014, Torvald Riegel wrote:
> 
> > On Fri, 2014-02-21 at 22:10 +, Joseph S. Myers wrote:
> > > On Fri, 21 Feb 2014, Paul E. McKenney wrote:
> > > 
> > > > This needs to be as follows:
> > > > 
> > > > [[carries_dependency]] int getzero(int i [[carries_dependency]])
> > > > {
> > > > return i - i;
> > > > }
> > > > 
> > > > Otherwise dependencies won't get carried through it.
> > > 
> > > C11 doesn't have attributes at all (and no specification regarding calls 
> > > and dependencies that I can see).  And the way I read the C++11 
> > > specification of carries_dependency is that specifying carries_dependency 
> > > is purely about increasing optimization of the caller: that if it isn't 
> > > specified, then the caller doesn't know what dependencies might be 
> > > carried.  "Note: The carries_dependency attribute does not change the 
> > > meaning of the program, but may result in generation of more efficient 
> > > code. - end note".
> > 
> > I think that this last sentence can be kind of misleading, especially
> > when looking at it from an implementation point of view.  How
> > dependencies are handled (ie, preserving the syntactic dependencies vs.
> > emitting barriers) must be part of the ABI, or things like
> > [[carries_dependency]] won't work as expected (or lead to inefficient
> > code).  Thus, in practice, all compiler vendors on a platform would have
> > to agree to a particular handling, which might end up in selecting the
> > easy-but-conservative implementation option (ie, always emitting
> > mo_acquire when the source uses mo_consume).
> 
> Regardless of the ABI, my point is that if a program is valid, it is also 
> valid when all uses of [[carries_dependency]] are removed.  If a function 
> doesn't use [[carries_dependency]], that means "dependencies may or may 
> not be carried through this function".  If a function uses 
> [[carries_dependency]], that means that certain dependencies *are* carried 
> through the function (and the ABI should then specify what this means the 
> caller can rely on, in terms of the architecture's memory model).  (This 
> may or may not be useful, but it's how I understand C++11.)

I agree.  What I tried to point out is that it's not the case that an
*implementation* can just ignore [[carries_dependency]].  So from an
implementation perspective, the attribute does have semantics.

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

3.13.5 : rm -rf running forever, one cpu at approx 100%

[Ken Moffat]

Hi,

 Short summary : on 3.13.5, rm -rf of an application source
directory on an ext4 filesystem sometimes takes forever (probably
isn't going anywhere), with one CPU pegged at all-but 100% utilization.

 I've nearly finished building a new system from source, to check
various desktop packages in linuxfromscratch.  On this build, much of
it is things I don't normally use and I needed to upgrade my
buildscripts, so most of it was built in chroot using 3.10.32.  But
late last night I booted the new system using 3.13.5 to finish the
build.  This morning I discovered that rm -rf for the icedtea source
directory was still running, and had taken over 5 hours of CPU time
(one CPU seemd to be running at close to 100%, the others had dropped
to their slowest frequency).  That script was running as root (yeah,
but it's a new system) and it looks as if /etc/passwd~ had got
trashed, because I could no longer su or login.  Not sure if that is
related, at this stage it might just be a side-effect of my scripts.

 Booted another system, chrooted, fixed up passwords.  Started
again after commenting out icedtea - I hadn't intended to build
what was an old version, I'd just forgotten it was in this script -
that's why I do things in userspace, not the kernel :-(

 Continued with remaining packages, but a couple of hours later I
saw a similar "one CPU at 100%, rm -rf GConf source taking forever"
problem.  Dumped all the processes with Alt-SysRQ-T [ huge log ] but
at that point 'rm' was merely 'ready' so I doubt there is anything
useful to see in the log.

 Built 3.13.4, booted to that.  So far, everything looks good - but
I'm now building the _current_ version of icedtea, so if this isn't
a new 3.13.5 problem I guess I'm fairly likely to see it tomorrow.

 Meanwhile, any suggestions about how I can debug this if I hit it
again, please ?

ĸen
-- 
das eine Mal als Tragödie, dieses Mal als Farce
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: The sheer number of sparse warnings in the kernel

[H. Peter Anvin]

On 02/26/2014 04:48 PM, Joe Perches wrote:
> err.h could also return bool instead of long for the
> IS_ERR and IS_ERR_OR_NULL tests.

This is definitely true... although we should check that that doesn't
make the code worse as this is used *all over* the kernel.

> Maybe something like this could be useful.
> 
> Shut up the unsigned<->signed pointer conversions
> and implicit conversions in the Makefile.

Sounds like two separate patches to me.

-hpa


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

Re: The sheer number of sparse warnings in the kernel

[Joe Perches]

On Wed, 2014-02-26 at 14:49 -0800, H. Peter Anvin wrote:
> The number of sparse errors in the current kernel is staggering, and it
> makes sparse a lot less valuable of a tool that it otherwise could be.
> On a build of x86-64 allyesconfig I'm getting 20,676 sparse messages.
> Out of those, 12,358 come from linux/err.h.  Given that the latter
> basically spams *everything*, I can only conclude that almost noone uses
> sparse unless they have a filter script.
> 
> So a lot of these are certainly nuisance problems, like the
>  stuff which has to do with the handling of error values,
> but some of these look like real bugs.
> 
> What do we need to do to actually make our tools be able to do work for
> us?  Newbie projects to clean up?  Trying to get the larger Linux
> companies to put resources on it?

gcc 4.8 does annoyingly warn on all unsigned/signed
mismatches/implicit conversions too.

err.h could also return bool instead of long for the
IS_ERR and IS_ERR_OR_NULL tests.

Maybe something like this could be useful.

Shut up the unsigned<->signed pointer conversions
and implicit conversions in the Makefile.

Use bool not long for IS_ERR and IS_ERR_OR_NULL

Update the dentry description of kernel pointers
left over from 2002's move to err.h

unsigned...

---
 Makefile| 1 +
 include/linux/err.h | 7 ---
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/Makefile b/Makefile
index fce2ba7..a9c11c4 100644
--- a/Makefile
+++ b/Makefile
@@ -381,6 +381,7 @@ KBUILD_CPPFLAGS := -D__KERNEL__
 KBUILD_CFLAGS   := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
   -fno-strict-aliasing -fno-common \
   -Werror-implicit-function-declaration \
+  -Wno-sign-conversion -Wno-pointer-sign \
   -Wno-format-security \
   -fno-delete-null-pointer-checks
 KBUILD_AFLAGS_KERNEL :=
diff --git a/include/linux/err.h b/include/linux/err.h
index 15f92e0..a729120 100644
--- a/include/linux/err.h
+++ b/include/linux/err.h
@@ -2,12 +2,13 @@
 #define _LINUX_ERR_H
 
 #include 
+#include 
 
 #include 
 
 /*
  * Kernel pointers have redundant information, so we can use a
- * scheme where we can return either an error code or a dentry
+ * scheme where we can return either an error code or a normal
  * pointer with the same return value.
  *
  * This should be a per-architecture thing, to allow different
@@ -29,12 +30,12 @@ static inline long __must_check PTR_ERR(__force const void 
*ptr)
return (long) ptr;
 }
 
-static inline long __must_check IS_ERR(__force const void *ptr)
+static inline bool __must_check IS_ERR(__force const void *ptr)
 {
return IS_ERR_VALUE((unsigned long)ptr);
 }
 
-static inline long __must_check IS_ERR_OR_NULL(__force const void *ptr)
+static inline bool __must_check IS_ERR_OR_NULL(__force const void *ptr)
 {
return !ptr || IS_ERR_VALUE((unsigned long)ptr);
 }


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ACPI / EC: Clear stale EC events on Samsung systems

[Kieran Clancy]

On Thu, Feb 27, 2014 at 10:15 AM, Rafael J. Wysocki  wrote:
> On Thursday, February 27, 2014 02:12:40 AM Kieran Clancy wrote:
>> Signed-off-by: Kieran Clancy 
>> Signed-off-by: Lan Tianyu 
>> Signed-off-by: Juan Manuel Cabo 
>> Signed-off-by: Dennis Jansen 
>
> There are too many sign-offs under this patch.  I suppose some of them
> should be Acked-by or Reviewed-by.
>
> Are you the author?

Sorry about that, I wasn't sure of the best way to acknowledge the
people involved.

I am the primary author, but I based the loop which calls
acpi_ec_query_unlocked() on a patch by Lan Tianyu. Juan provided the
initial idea (userspace workaround), and Dennis and Lan Tianyu
reviewed and suggested some changes to the code.

What would you usually do this kind of situation?

I suppose I could put something such as:

Signed-off-by: Kieran Clancy 
Signed-off-by: Lan Tianyu 
Suggested-by: Juan Manuel Cabo 
Reviewed-by: Lan Tianyu 
Reviewed-by: Dennis Jansen 

Would this be preferable?

Thanks,
Kieran Clancy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PM / devfreq: Fix out of bounds access of transition table array

[Saravana Kannan]

On 02/25/2014 09:12 PM, 함명주 wrote:
>> On 02/23/2014 11:15 PM, Saravana Kannan wrote:
>>> The previous_freq value for a device could be an invalid frequency that
>>> results in a error value being returned from devfreq_get_freq_level().
>>> Check for an error value before using that to index into the transition
>>> table.
>>>
>>> Not doing this check will result in memory corruption when previous_freq is
>>> not a valid frequency.
>>>
>>> Signed-off-by: Saravana Kannan 
>>
>> MyungJoo/Kyungmin,
>>
>> Would either of you have some time to respond to this?
>>
>> Thanks,
>> Saravana
> 
> Dear Saravana,
> 
>>> +   prev_lev = devfreq_get_freq_level(devfreq, devfreq->previous_freq);
>>> +   if (prev_lev < 0)
>>> +   return 0;
> 
> If devfreq_get_freq_level returned error, please return that error
> to the caller. You are retuning 0 in that case.
> 
> Plus, do you think we are going to change profile->freq_table in run-time?
> (by accidently? or intentionally?)

Hi MyungJoo,

The reason for this fix is that some devices can't reliably detect their
current frequency. So, we set the initial freq to 0 so that the first
request from the default governor actually goes through.

If we randomly pick one of the valid frequencies, then the initial
request could get short circuited by devfreq, cause wrong stats, the
device itself might short circuit it after comparing it to prev freq, etc.

The reason I intentionally ignored the error was to prevent printing an
error at boot every time for such devices. I could do better with more
complicated code, but I couldn't imagine any other case where
previous_freq could actually end up being an invalid value.

Hold on, I just realized that the stats code is completely wrong! Isn't
the current code updating the time_in_state[] of the wrong level? It's
updating the new level's time in state instead of the previous one?

I'll send out a patch that fixes all this with in a couple of days.

Thanks,
Saravana

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/9] Input: pmic8xxx-pwrkey - Migrate to regmap APIs

[Stephen Boyd]

On 02/26/14 16:30, Josh Cartwright wrote:
> On Wed, Feb 26, 2014 at 04:20:03PM -0800, Stephen Boyd wrote:
>> On 02/26/14 16:13, Josh Cartwright wrote:
>>> On Wed, Feb 26, 2014 at 04:05:40PM -0800, Stephen Boyd wrote:
 On 02/26/14 15:59, Josh Cartwright wrote:
>>> However, I think it needs to be made clear that your if "Modernize pm8921
>>> with irqdomains, regmap, DT" lands before this patchset, this will start
>>> breaking randconfig builds.  It isn't clear to me how this dependency
>>> should be handled.
>>>
>> Hmm? If pm8921 lands before this what build breakage is there? The
>> pm8xxx_read/write APIs are still exposed.
> Well, with the pm8921 patchset in place, the keypad driver becomes
> selectable, which, when built leads to the error below.  But AFAICT,
> this isn't even addressed in this patchset?!
>
> drivers/input/keyboard/pmic8xxx-keypad.c:24:35: fatal error: 
> linux/mfd/pm8xxx/gpio.h: No such file or directory
>  #include 
>^
>
> So, I'm confused...maybe the pm8921 cleanup patchset should be marking
> the keypad driver BROKEN?
>

Ah, yes probably. I have a patch locally that rips out the gpio stuff
because this driver has been uncompilable since it was introduced. I may
as well send that along with this series so that people can actually
compile this driver. Or like you say, send it along with the removal of
the BROKEN in pm8921 Kconfig.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

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

Re: [PATCH v2 2/4] clk: at91: propagate rate change on system clks

[Mike Turquette]

Quoting Jean-Jacques Hiblot (2014-02-05 00:37:36)
> From: Boris BREZILLON 
> 
> System clks are just gates, and thus do not provide any rate operations.
> Authorize clk rate change to be propagated to system clk parents.
> 
> Signed-off-by: Boris BREZILLON 
> ---
>  drivers/clk/at91/clk-system.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clk/at91/clk-system.c b/drivers/clk/at91/clk-system.c
> index 8f7c043..a98557b 100644
> --- a/drivers/clk/at91/clk-system.c
> +++ b/drivers/clk/at91/clk-system.c
> @@ -84,7 +84,8 @@ at91_clk_register_system(struct at91_pmc *pmc, const char 
> *name,
>  * (see drivers/memory) which would request and enable the ddrck 
> clock.
>  * When this is done we will be able to remove CLK_IGNORE_UNUSED flag.
>  */
> -   init.flags = CLK_IGNORE_UNUSED;
> +   init.flags = CLK_SET_RATE_GATE | CLK_SET_RATE_PARENT |

Just wanted to do a quick sanity check here. Do you really need
CLK_SET_RATE_GATE? Otherwise these patches look fine.

Regards,
Mike

> +CLK_IGNORE_UNUSED;
>  
> sys->id = id;
> sys->hw.init = 
> -- 
> 1.8.5.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/