Re: [PATCH][v6] tools/power turbostat: if --iterations, print for specific count of iterations

[Bityutskiy, Artem]

On Thu, 2018-04-26 at 08:41 +0800, Chen Yu wrote:
> There's a use case during test to only print specific round of iterations
> if --iterations is specified, for example, with this patch applied:
> 
> turbostat -i 5 -r 4
> will capture 4 samples with 5 seconds interval.
> 
> Cc: Len Brown 
> Cc: Rafael J. Wysocki 
> Cc: Artem Bityutskiy 
> Cc: Doug Smythies 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: Rafael J. Wysocki 
> Signed-off-by: Chen Yu 

Reviewed-by: Artem Bityutskiy 

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH][v6] tools/power turbostat: if --iterations, print for specific count of iterations

[Bityutskiy, Artem]

On Thu, 2018-04-26 at 08:41 +0800, Chen Yu wrote:
> There's a use case during test to only print specific round of iterations
> if --iterations is specified, for example, with this patch applied:
> 
> turbostat -i 5 -r 4
> will capture 4 samples with 5 seconds interval.
> 
> Cc: Len Brown 
> Cc: Rafael J. Wysocki 
> Cc: Artem Bityutskiy 
> Cc: Doug Smythies 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Reviewed-by: Rafael J. Wysocki 
> Signed-off-by: Chen Yu 

Reviewed-by: Artem Bityutskiy 

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH][RFC] tools/power turbostat: if --max_loop, print for specific time of loops

[Bityutskiy, Artem]

On Tue, 2018-04-10 at 18:18 +0800, Yu Chen wrote:
> @@ -5076,6 +5084,15 @@ void cmdline(int argc, char **argv)
> print_version();
> exit(0);
> break;
> +   case 'x':
> +   {
> +   unsigned int loops = strtod(optarg, NULL);

It would make sense to error out here if you get a value <= 0.

> +
> +   if (loops % 2)
> +   loops++;

What is this for?

> +   max_loops = loops;

Is the "loops" variable really needed? Can you strtod directly to
max_loops?

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH][RFC] tools/power turbostat: if --max_loop, print for specific time of loops

[Bityutskiy, Artem]

On Tue, 2018-04-10 at 18:18 +0800, Yu Chen wrote:
> @@ -5076,6 +5084,15 @@ void cmdline(int argc, char **argv)
> print_version();
> exit(0);
> break;
> +   case 'x':
> +   {
> +   unsigned int loops = strtod(optarg, NULL);

It would make sense to error out here if you get a value <= 0.

> +
> +   if (loops % 2)
> +   loops++;

What is this for?

> +   max_loops = loops;

Is the "loops" variable really needed? Can you strtod directly to
max_loops?

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

regression: SCSI/SATA failure

[Bityutskiy, Artem]

Hi Christoph,

one of our test box Skylake servers does not boot with v4.16-rcX.
Bisection lead us to this commit:

84676c1f21e8 genirq/affinity: assign vectors to all possible CPUs

Reverting this single commit fixes the problem.

The server is a Dell R640 machine with the latest Dell BIOS. It has a
single SATA SSD and we do not use raid, even though the system does
have a megaraid controller.

Are you aware of this issue? Below is the failure message and the full
dmesg with some debugging boot parameters is here:

https://pastebin.com/raw/tTYrTAEQ

[  201.706075] sd 14:2:0:0: [sda] tag#0 task abort called for 
scmd(c342d874)
[  201.720357] sd 14:2:0:0: [sda] tag#0 CDB: Read(10) 28 00 0d e7 ff 80 00 00 
08 00
[  201.734621] sd 14:2:0:0: task abort: FAILED scmd(c342d874)
[  201.754134] sd 14:2:0:0: target reset called for scmd(c342d874)
[  201.767566] sd 14:2:0:0: [sda] tag#0 megasas: target reset FAILED!!
[  201.780690] sd 14:2:0:0: [sda] tag#0 Controller reset is requested due to IO 
timeout
[  201.780690] SCSI command pointer: (c342d874)  SCSI host state: 5 
 SCSI 
[  201.809709] IO request frame:
[  201.809709] 
[  201.809710] f100 
[  201.827987]  
[  201.836901]  
[  201.846047] 5d88 
[  201.855161] 0062 
[  201.864093] 0020 
[  201.872746]  
[  201.881168] 1000 
[  201.889432] 
[  201.889432] 
[  201.897570]  
[  201.912011] 000a 
[  201.919897]  
[  201.927608]  
[  201.935275]  
[  201.943047]  
[  201.950516]  
[  201.957709] 0200 
[  201.964776] 
[  201.964776] 
[  201.971731] e70d0028 
[  201.983967] 80ff 
[  201.990676] 0008 
[  201.997192]  
[  202.003611]  
[  202.009812]  
[  202.015847]  
[  202.021770]  
[  202.027576] 
[  202.027576] 
[  202.033382] 00140012 
[  202.043209] 0009 
[  202.048521] 0de7ff80 
[  202.053711]  
[  202.058818] 0008 
[  202.063850]  
[  202.068797] 00020100 
[  202.073549]  
[  202.078131] 
[  202.078131] 
[  202.082708] beb56000 
[  202.089903] 002f 
[  202.094106] 1000 
[  202.098230] 4000 
[  202.102238]  
[  202.106134]  
[  202.109878]  
[  202.113456]  
[  202.117008] 
[  202.117008] 
[  202.120545]  
[  202.126100]  
[  202.129656]  
[  202.133191]  
[  202.136716]  
[  202.140241]  
[  202.143767]  
[  202.147264]  
[  202.150772] 
[  202.150772] 
[  202.154257]  
[  202.159702]  
[  202.163206]  
[  202.166706]  
[  202.170204]  
[  202.173697]  
[  202.177186]  
[  202.180659]  
[  202.184135] 
[  202.184135] 
[  202.187592]  
[  202.192952]  
[  202.196440]  
[  202.199892]  
[  202.203349]  
[  202.206798]  
[  202.210252]  
[  202.213691]  
[  202.217140] 

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

regression: SCSI/SATA failure

[Bityutskiy, Artem]

Hi Christoph,

one of our test box Skylake servers does not boot with v4.16-rcX.
Bisection lead us to this commit:

84676c1f21e8 genirq/affinity: assign vectors to all possible CPUs

Reverting this single commit fixes the problem.

The server is a Dell R640 machine with the latest Dell BIOS. It has a
single SATA SSD and we do not use raid, even though the system does
have a megaraid controller.

Are you aware of this issue? Below is the failure message and the full
dmesg with some debugging boot parameters is here:

https://pastebin.com/raw/tTYrTAEQ

[  201.706075] sd 14:2:0:0: [sda] tag#0 task abort called for 
scmd(c342d874)
[  201.720357] sd 14:2:0:0: [sda] tag#0 CDB: Read(10) 28 00 0d e7 ff 80 00 00 
08 00
[  201.734621] sd 14:2:0:0: task abort: FAILED scmd(c342d874)
[  201.754134] sd 14:2:0:0: target reset called for scmd(c342d874)
[  201.767566] sd 14:2:0:0: [sda] tag#0 megasas: target reset FAILED!!
[  201.780690] sd 14:2:0:0: [sda] tag#0 Controller reset is requested due to IO 
timeout
[  201.780690] SCSI command pointer: (c342d874)  SCSI host state: 5 
 SCSI 
[  201.809709] IO request frame:
[  201.809709] 
[  201.809710] f100 
[  201.827987]  
[  201.836901]  
[  201.846047] 5d88 
[  201.855161] 0062 
[  201.864093] 0020 
[  201.872746]  
[  201.881168] 1000 
[  201.889432] 
[  201.889432] 
[  201.897570]  
[  201.912011] 000a 
[  201.919897]  
[  201.927608]  
[  201.935275]  
[  201.943047]  
[  201.950516]  
[  201.957709] 0200 
[  201.964776] 
[  201.964776] 
[  201.971731] e70d0028 
[  201.983967] 80ff 
[  201.990676] 0008 
[  201.997192]  
[  202.003611]  
[  202.009812]  
[  202.015847]  
[  202.021770]  
[  202.027576] 
[  202.027576] 
[  202.033382] 00140012 
[  202.043209] 0009 
[  202.048521] 0de7ff80 
[  202.053711]  
[  202.058818] 0008 
[  202.063850]  
[  202.068797] 00020100 
[  202.073549]  
[  202.078131] 
[  202.078131] 
[  202.082708] beb56000 
[  202.089903] 002f 
[  202.094106] 1000 
[  202.098230] 4000 
[  202.102238]  
[  202.106134]  
[  202.109878]  
[  202.113456]  
[  202.117008] 
[  202.117008] 
[  202.120545]  
[  202.126100]  
[  202.129656]  
[  202.133191]  
[  202.136716]  
[  202.140241]  
[  202.143767]  
[  202.147264]  
[  202.150772] 
[  202.150772] 
[  202.154257]  
[  202.159702]  
[  202.163206]  
[  202.166706]  
[  202.170204]  
[  202.173697]  
[  202.177186]  
[  202.180659]  
[  202.184135] 
[  202.184135] 
[  202.187592]  
[  202.192952]  
[  202.196440]  
[  202.199892]  
[  202.203349]  
[  202.206798]  
[  202.210252]  
[  202.213691]  
[  202.217140] 

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: sync issues in 4.3-rc1?

[Bityutskiy, Artem]

On Fri, 2015-09-18 at 19:46 +0300, Artem Bityutskiy wrote:
> Hi,
> 
> I observe a problem in 4.3-rc1 which looks like there are issues with
> sync - it does not really sync all.

The FS is ext4, a plain partition mounted (no lvm, no encryption, etc).
The disk is SATA SSD, but I believe I observed this on a SATA HDD too
today (I have several machines).

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: sync issues in 4.3-rc1?

[Bityutskiy, Artem]

On Fri, 2015-09-18 at 19:46 +0300, Artem Bityutskiy wrote:
> Hi,
> 
> I observe a problem in 4.3-rc1 which looks like there are issues with
> sync - it does not really sync all.

The FS is ext4, a plain partition mounted (no lvm, no encryption, etc).
The disk is SATA SSD, but I believe I observed this on a SATA HDD too
today (I have several machines).

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: autoNUMA web workload regression

[Bityutskiy, Artem]

On Wed, 2015-05-06 at 13:35 +0300, Artem Bityutskiy wrote:
> If I take 4.1-rc1 and revert this patch, I observe 300% or more average
> response time improvement comparing to vanilla 3.17.

Sorry, I meant vanilla 4.1-rc1 here, not 3.17.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: autoNUMA web workload regression

[Bityutskiy, Artem]

On Wed, 2015-05-06 at 13:35 +0300, Artem Bityutskiy wrote:
 If I take 4.1-rc1 and revert this patch, I observe 300% or more average
 response time improvement comparing to vanilla 3.17.

Sorry, I meant vanilla 4.1-rc1 here, not 3.17.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 3/4] UBI: Fastmap: Care about the protection queue

[Bityutskiy, Artem]

On Mon, 2014-10-13 at 18:23 +0300, Artem Bityutskiy wrote:
> > The interface would work but some work in wl.c is needed.
> > For example if I want to find out in which state PEB 1 is wl.c would have to
> > look int free free, used free, protection queue, etc.. to tell me the 
> > state. This is slow.
> 
> Well, used and free are RB-trees, looking them up is slow.

I wanted to say "not slow" here, sorry.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 3/4] UBI: Fastmap: Care about the protection queue

[Bityutskiy, Artem]

On Mon, 2014-10-13 at 18:23 +0300, Artem Bityutskiy wrote:
  The interface would work but some work in wl.c is needed.
  For example if I want to find out in which state PEB 1 is wl.c would have to
  look int free free, used free, protection queue, etc.. to tell me the 
  state. This is slow.
 
 Well, used and free are RB-trees, looking them up is slow.

I wanted to say not slow here, sorry.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 1/4] UBI: Ensure that all fastmap work is done upon WL shutdown

[Bityutskiy, Artem]

On Tue, 2014-09-30 at 08:58 +0200, Richard Weinberger wrote:
> Am 30.09.2014 08:26, schrieb Artem Bityutskiy:
> > On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
> >> ...otherwise the deferred work might run after datastructures
> >> got freed and corrupt memory.
> > 
> > How can this happend? The background thread is stopped by this time
> > already, so what are the other possibilities? And why is this
> > fastmap-only?
> 
> This has nothing do to with the background thread.
> Fastmap has a work queue. If one fastmap work has been
> scheuled we have to wait for it.

I expected a bit more explanation. But OK, here is what I think.

UBI consists of subsystems. Subsystems try to be more or less
independent, whenever possible. They expose interface functions for
other subsystems. Of course the split is not ideal, but we do our best.

* wl.c does wear-levelling.
* wl.c does not do fastmap.
* fastmap.c does fastmap.
* I am unhappy seeing yet another ifdef to wl.c
* I am unhappy seeing wl.c calling 'flush_work(>fm_work)', because
fastmap.c should deal with 'fm_work'. Or said differently, wl.c is not a
fastmap queue baby-sitter. fastmap.c is.

Most UB subsystems have the init and close function. May be adding one
for fastmap would help? Then you could flush whatever from
'ubi_wl_close()' ?

Historically the work queue was implemented in wl.c because wl.c was the
only user of it.

If this layout is not good enough, we should probably extend it, may be
separate work queue management out of wl.c.

But populating wl.c with macros and little "take care of this fatmap
bit" stuff is a not going to lead to better code structure.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled

[Bityutskiy, Artem]

On Tue, 2014-09-30 at 08:59 +0200, Richard Weinberger wrote:
> Am 30.09.2014 08:45, schrieb Bityutskiy, Artem:
> > On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
> >> +   spin_lock(>wl_lock);
> >> +   ubi->fm_work_scheduled = 0;
> >> +   spin_unlock(>wl_lock);
> > 
> > Andrew Morton once said me that if I am protecting an integer change
> > like this with a spinlock, I have a problem in my locking design. He was
> > right for my particular case.
> > 
> > Integer is changes atomic. The only other thing spinlock adds are the
> > barriers.
> 
> I've added the spinlock to have a barrier in any case.

Examples of any?

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled

[Bityutskiy, Artem]

On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
> +   spin_lock(>wl_lock);
> +   ubi->fm_work_scheduled = 0;
> +   spin_unlock(>wl_lock);

Andrew Morton once said me that if I am protecting an integer change
like this with a spinlock, I have a problem in my locking design. He was
right for my particular case.

Integer is changes atomic. The only other thing spinlock adds are the
barriers.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC] UBI bitrot checking

[Bityutskiy, Artem]

On Wed, 2014-09-24 at 00:06 +0200, Richard Weinberger wrote:
> This is a very initial draft for one possibility of bitrot checking in UBI.
> The basic idea is to have a worker function which reads a complete PEB and
> schedules scrubbing if bit flips are detected.
> Currently this check is triggered by accessing any UBI debugfs file (yes, I'm 
> lazy!).
> We have to agree on an interface first.
> Do we want a debugfs file? Another ioctl()?
> Automatic in-kernel schedules?
> Of course this interface has to return EBUSY if currently a check is 
> running...
> 
> The current implementation has one limitation, it can only check PEBs which 
> are used.
> As of now ubi_wl_scrub_peb() works only for used PEBs but I think we could 
> change that.

Most probably we do want to give user-space some kind of control. At the
very least:

1. Whether the unflipper (or bitunrotter?) is triggered or not at all
2. When is it triggered
3. Whether the unflipper finished the job or not
4. For #3, it is preferrable that user-space has a possibility to wait
for an event, rather than poll. Should be easy to do with sysfs.

And no, not debugfs, this is not a debugging feature. Sysfs or, less
preferrably, IMO, ioctl.

Then, question - do we want user-space to have more control over the
unflipper, e.g., pause it and resume? E.g., if we are talking a critical
path, like a phone call on a phone, user-space may pause the unflipper
to make sure the phone UI latency stays within certain limits.

We need to consider various usage scenarios and make sure the interface
is suitable.

And we do not have to implement all the features, just make sure we can
add them in the future if needed.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Two lame typo fixes

[Bityutskiy, Artem]

On Tue, 2014-09-30 at 00:24 +0200, Richard Weinberger wrote:
> On Tue, Sep 16, 2014 at 3:30 PM, Richard Weinberger  wrote:
> > ...found them while browsing.
> >
> > Thanks,
> > //richard
> >
> > [PATCH 1/2] UBI: Fix trivial typo in __schedule_ubi_work
> > [PATCH 2/2] UBIFS: Fix trivial typo in power_cut_emulated()
> 
> ping?

Pushed both, thanks!

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: Two lame typo fixes

[Bityutskiy, Artem]

On Tue, 2014-09-30 at 00:24 +0200, Richard Weinberger wrote:
 On Tue, Sep 16, 2014 at 3:30 PM, Richard Weinberger rich...@nod.at wrote:
  ...found them while browsing.
 
  Thanks,
  //richard
 
  [PATCH 1/2] UBI: Fix trivial typo in __schedule_ubi_work
  [PATCH 2/2] UBIFS: Fix trivial typo in power_cut_emulated()
 
 ping?

Pushed both, thanks!

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC] UBI bitrot checking

[Bityutskiy, Artem]

On Wed, 2014-09-24 at 00:06 +0200, Richard Weinberger wrote:
 This is a very initial draft for one possibility of bitrot checking in UBI.
 The basic idea is to have a worker function which reads a complete PEB and
 schedules scrubbing if bit flips are detected.
 Currently this check is triggered by accessing any UBI debugfs file (yes, I'm 
 lazy!).
 We have to agree on an interface first.
 Do we want a debugfs file? Another ioctl()?
 Automatic in-kernel schedules?
 Of course this interface has to return EBUSY if currently a check is 
 running...
 
 The current implementation has one limitation, it can only check PEBs which 
 are used.
 As of now ubi_wl_scrub_peb() works only for used PEBs but I think we could 
 change that.

Most probably we do want to give user-space some kind of control. At the
very least:

1. Whether the unflipper (or bitunrotter?) is triggered or not at all
2. When is it triggered
3. Whether the unflipper finished the job or not
4. For #3, it is preferrable that user-space has a possibility to wait
for an event, rather than poll. Should be easy to do with sysfs.

And no, not debugfs, this is not a debugging feature. Sysfs or, less
preferrably, IMO, ioctl.

Then, question - do we want user-space to have more control over the
unflipper, e.g., pause it and resume? E.g., if we are talking a critical
path, like a phone call on a phone, user-space may pause the unflipper
to make sure the phone UI latency stays within certain limits.

We need to consider various usage scenarios and make sure the interface
is suitable.

And we do not have to implement all the features, just make sure we can
add them in the future if needed.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled

[Bityutskiy, Artem]

On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
 +   spin_lock(ubi-wl_lock);
 +   ubi-fm_work_scheduled = 0;
 +   spin_unlock(ubi-wl_lock);

Andrew Morton once said me that if I am protecting an integer change
like this with a spinlock, I have a problem in my locking design. He was
right for my particular case.

Integer is changes atomic. The only other thing spinlock adds are the
barriers.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 4/4] UBI: Fastmap: Ensure that only one fastmap work is scheduled

[Bityutskiy, Artem]

On Tue, 2014-09-30 at 08:59 +0200, Richard Weinberger wrote:
 Am 30.09.2014 08:45, schrieb Bityutskiy, Artem:
  On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
  +   spin_lock(ubi-wl_lock);
  +   ubi-fm_work_scheduled = 0;
  +   spin_unlock(ubi-wl_lock);
  
  Andrew Morton once said me that if I am protecting an integer change
  like this with a spinlock, I have a problem in my locking design. He was
  right for my particular case.
  
  Integer is changes atomic. The only other thing spinlock adds are the
  barriers.
 
 I've added the spinlock to have a barrier in any case.

Examples of any?

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH 1/4] UBI: Ensure that all fastmap work is done upon WL shutdown

[Bityutskiy, Artem]

On Tue, 2014-09-30 at 08:58 +0200, Richard Weinberger wrote:
 Am 30.09.2014 08:26, schrieb Artem Bityutskiy:
  On Tue, 2014-09-30 at 00:20 +0200, Richard Weinberger wrote:
  ...otherwise the deferred work might run after datastructures
  got freed and corrupt memory.
  
  How can this happend? The background thread is stopped by this time
  already, so what are the other possibilities? And why is this
  fastmap-only?
 
 This has nothing do to with the background thread.
 Fastmap has a work queue. If one fastmap work has been
 scheuled we have to wait for it.

I expected a bit more explanation. But OK, here is what I think.

UBI consists of subsystems. Subsystems try to be more or less
independent, whenever possible. They expose interface functions for
other subsystems. Of course the split is not ideal, but we do our best.

* wl.c does wear-levelling.
* wl.c does not do fastmap.
* fastmap.c does fastmap.
* I am unhappy seeing yet another ifdef to wl.c
* I am unhappy seeing wl.c calling 'flush_work(ubi-fm_work)', because
fastmap.c should deal with 'fm_work'. Or said differently, wl.c is not a
fastmap queue baby-sitter. fastmap.c is.

Most UB subsystems have the init and close function. May be adding one
for fastmap would help? Then you could flush whatever from
'ubi_wl_close()' ?

Historically the work queue was implemented in wl.c because wl.c was the
only user of it.

If this layout is not good enough, we should probably extend it, may be
separate work queue management out of wl.c.

But populating wl.c with macros and little take care of this fatmap
bit stuff is a not going to lead to better code structure.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH] sysctl: Add a feature to drop caches selectively

[Bityutskiy, Artem]

On Fri, 2014-06-27 at 12:08 +0300, Artem Bityutskiy wrote:
> To make 100% sure you'd not only need to drop VFS-level caches but also
> file-system-level caches. Indeed, file-systems have their own rather
Sorry, I wanted to say "rather complex" here
> buffers for different indexing data-structures, etc. The unmount/mount
> sequence takes care of that.
> 

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH] sysctl: Add a feature to drop caches selectively

[Bityutskiy, Artem]

On Fri, 2014-06-27 at 12:08 +0300, Artem Bityutskiy wrote:
 To make 100% sure you'd not only need to drop VFS-level caches but also
 file-system-level caches. Indeed, file-systems have their own rather
Sorry, I wanted to say rather complex here
 buffers for different indexing data-structures, etc. The unmount/mount
 sequence takes care of that.
 

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC/PATCH] mtd: ubi: Free peb's synchronously for fastmap

[Bityutskiy, Artem]

On Tue, 2014-04-08 at 16:42 +0300, Artem Bityutskiy wrote:
> On Tue, 2014-04-01 at 11:01 +0300, Tanya Brokhman wrote:
> > At first mount it's possible that there are not enough free PEBs since
> > there are PEB's pending to be erased. In such scenario, fm_pool (which is
> > the pool from which user required PEBs are allocated) will be empty.
> > Try fixing the above described situation by synchronously performing
> > pending erase work, thus produce another free PEB.
> > 
> > Signed-off-by: Tatyana Brokhman 
> 
> Pushed to linux-ubifs.git / master, thanks!

Oh, sorry, this one I actually _dropped_. Would you please rather
re-structure the code to avoid duplication. E.g., do what Richard
suggested.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [RFC/PATCH] mtd: ubi: Free peb's synchronously for fastmap

[Bityutskiy, Artem]

On Tue, 2014-04-08 at 16:42 +0300, Artem Bityutskiy wrote:
 On Tue, 2014-04-01 at 11:01 +0300, Tanya Brokhman wrote:
  At first mount it's possible that there are not enough free PEBs since
  there are PEB's pending to be erased. In such scenario, fm_pool (which is
  the pool from which user required PEBs are allocated) will be empty.
  Try fixing the above described situation by synchronously performing
  pending erase work, thus produce another free PEB.
  
  Signed-off-by: Tatyana Brokhman tlin...@codeaurora.org
 
 Pushed to linux-ubifs.git / master, thanks!

Oh, sorry, this one I actually _dropped_. Would you please rather
re-structure the code to avoid duplication. E.g., do what Richard
suggested.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

please, remove UBI tree from linux-next

[Bityutskiy, Artem]

Hi Stephen,

could you please remove the UBI git tree from linux-next?

git://git.infradead.org/linux-ubi

I will use the UBIFS git tree for both UBI and UBIFS patches from now
on. The traffic became so low that it does not make sense to keep 2
separate trees for these very related subsystems.

The UBIFS git tree is also in linux-next, so both UBI and UBIFS will be
covered through the UBIFS git tree.

Thanks!

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

please, remove UBI tree from linux-next

[Bityutskiy, Artem]

Hi Stephen,

could you please remove the UBI git tree from linux-next?

git://git.infradead.org/linux-ubi

I will use the UBIFS git tree for both UBI and UBIFS patches from now
on. The traffic became so low that it does not make sense to keep 2
separate trees for these very related subsystems.

The UBIFS git tree is also in linux-next, so both UBI and UBIFS will be
covered through the UBIFS git tree.

Thanks!

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

[GIT PULL] UBI changes for 3.11-rc1

[Bityutskiy, Artem]

Hellow Linus!

The following changes since commit f722406faae2d073cc1d01063d1123c35425939e:

  Linux 3.10-rc1 (2013-05-11 17:14:08 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-ubi.git tags/upstream-3.11-rc1

for you to fetch changes up to 83ff59a066637a6c28844bbf43009459408240f4:

  UBI: support ubi_num on mtd.ubi command line (2013-07-01 08:32:57 +0300)


A couple of fixes and clean-ups, allow for assigning user-defined
UBI device numbers when attaching MTD devices by using the "mtd="
module parameter.


Brian Pomerantz (1):
  UBI: fastmap break out of used PEB search

Mike Frysinger (4):
  UBI: drop redundant "UBI error" string
  UBI: do not abort init when ubi.mtd devices cannot be found
  UBI: document UBI_IOCVOLUP better in user header
  UBI: support ubi_num on mtd.ubi command line

 drivers/mtd/ubi/build.c | 59 
---
 drivers/mtd/ubi/fastmap.c   |  4 +++-
 include/uapi/mtd/ubi-user.h |  5 -

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[GIT PULL] UBI changes for 3.11-rc1

[Bityutskiy, Artem]

Hellow Linus!

The following changes since commit f722406faae2d073cc1d01063d1123c35425939e:

  Linux 3.10-rc1 (2013-05-11 17:14:08 -0700)

are available in the git repository at:

  git://git.infradead.org/linux-ubi.git tags/upstream-3.11-rc1

for you to fetch changes up to 83ff59a066637a6c28844bbf43009459408240f4:

  UBI: support ubi_num on mtd.ubi command line (2013-07-01 08:32:57 +0300)


A couple of fixes and clean-ups, allow for assigning user-defined
UBI device numbers when attaching MTD devices by using the mtd=
module parameter.


Brian Pomerantz (1):
  UBI: fastmap break out of used PEB search

Mike Frysinger (4):
  UBI: drop redundant UBI error string
  UBI: do not abort init when ubi.mtd devices cannot be found
  UBI: document UBI_IOCVOLUP better in user header
  UBI: support ubi_num on mtd.ubi command line

 drivers/mtd/ubi/build.c | 59 
---
 drivers/mtd/ubi/fastmap.c   |  4 +++-
 include/uapi/mtd/ubi-user.h |  5 -

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH] x86/PCI: setup data may be in highmem

[Bityutskiy, Artem]

On Sat, 2013-06-08 at 14:15 +0300, Artem Bityutskiy wrote:
> On Wed, 2013-05-22 at 10:43 +0100, Matt Fleming wrote:
> > From: Matt Fleming 
> > 
> > pcibios_add_device() assumes that the physical addresses stored in
> > setup_data are accessible via the direct kernel mapping, and that
> > calling phys_to_virt() is valid. This isn't guaranteed to be true on x86
> > where the direct mapping range is much smaller than on x86-64.
> > 
> > Calling phys_to_virt() on a highmem address results in the following,
> 
> Fixes paging request oops for me as well, thanks! Would you please add a
> -stable tag to this patch?

Oh, pardon, you did CC -stable.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] x86/PCI: setup data may be in highmem

[Bityutskiy, Artem]

On Sat, 2013-06-08 at 14:15 +0300, Artem Bityutskiy wrote:
 On Wed, 2013-05-22 at 10:43 +0100, Matt Fleming wrote:
  From: Matt Fleming matt.flem...@intel.com
  
  pcibios_add_device() assumes that the physical addresses stored in
  setup_data are accessible via the direct kernel mapping, and that
  calling phys_to_virt() is valid. This isn't guaranteed to be true on x86
  where the direct mapping range is much smaller than on x86-64.
  
  Calling phys_to_virt() on a highmem address results in the following,
 
 Fixes paging request oops for me as well, thanks! Would you please add a
 -stable tag to this patch?

Oh, pardon, you did CC -stable.

-- 
Best Regards,
Artem Bityutskiy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�j:+v���zZ+��+zf���h���~i���z��w���?��)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH] of: mtd: nuke useless const qualifier

[Bityutskiy, Artem]

On Tue, 2012-07-10 at 10:35 -0500, Rob Herring wrote:
> > Remove also the unnecessary "extern" qualifier to be consistent with other
> > declarations in this file.
> > 
> > Signed-off-by: Artem Bityutskiy 
> > ---
> 
> Applied. Next time please don't PGP sign patches.

Thanks. Sure, I'll try.

-- 
Best Regards,
Artem Bityutskiy


signature.asc
Description: This is a digitally signed message part
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[PATCH] of: mtd: nuke useless const qualifier

[Bityutskiy, Artem]

From: Artem Bityutskiy 

This patch does the following:
 -const int of_get_nand_ecc_mode(struct device_node *np)
 +int of_get_nand_ecc_mode(struct device_node *np)

because:
1. it is probably just a typo?
2. it causes warnings like this when people assing the returned
   value to an 'int' variable:
   include/linux/of_mtd.h:14:18: warning: type qualifiers ignored on function 
return type [-Wignored-qualifiers]

Remove also the unnecessary "extern" qualifier to be consistent with other
declarations in this file.

Signed-off-by: Artem Bityutskiy 
---
 drivers/of/of_mtd.c|2 +-
 include/linux/of_mtd.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index e7cad62..a27ec94 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -32,7 +32,7 @@ static const char *nand_ecc_modes[] = {
  * The function gets ecc mode string from property 'nand-ecc-mode',
  * and return its index in nand_ecc_modes table, or errno in error case.
  */
-const int of_get_nand_ecc_mode(struct device_node *np)
+int of_get_nand_ecc_mode(struct device_node *np)
 {
const char *pm;
int err, i;
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
index bae1b60..ed7f267 100644
--- a/include/linux/of_mtd.h
+++ b/include/linux/of_mtd.h
@@ -11,7 +11,7 @@
 
 #ifdef CONFIG_OF_MTD
 #include 
-extern const int of_get_nand_ecc_mode(struct device_node *np);
+int of_get_nand_ecc_mode(struct device_node *np);
 int of_get_nand_bus_width(struct device_node *np);
 bool of_get_nand_on_flash_bbt(struct device_node *np);
 #endif
-- 
1.7.10



signature.asc
Description: This is a digitally signed message part
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

[PATCH] of: mtd: nuke useless const qualifier

[Bityutskiy, Artem]

From: Artem Bityutskiy artem.bityuts...@linux.intel.com

This patch does the following:
 -const int of_get_nand_ecc_mode(struct device_node *np)
 +int of_get_nand_ecc_mode(struct device_node *np)

because:
1. it is probably just a typo?
2. it causes warnings like this when people assing the returned
   value to an 'int' variable:
   include/linux/of_mtd.h:14:18: warning: type qualifiers ignored on function 
return type [-Wignored-qualifiers]

Remove also the unnecessary extern qualifier to be consistent with other
declarations in this file.

Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
---
 drivers/of/of_mtd.c|2 +-
 include/linux/of_mtd.h |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index e7cad62..a27ec94 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -32,7 +32,7 @@ static const char *nand_ecc_modes[] = {
  * The function gets ecc mode string from property 'nand-ecc-mode',
  * and return its index in nand_ecc_modes table, or errno in error case.
  */
-const int of_get_nand_ecc_mode(struct device_node *np)
+int of_get_nand_ecc_mode(struct device_node *np)
 {
const char *pm;
int err, i;
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
index bae1b60..ed7f267 100644
--- a/include/linux/of_mtd.h
+++ b/include/linux/of_mtd.h
@@ -11,7 +11,7 @@
 
 #ifdef CONFIG_OF_MTD
 #include linux/of.h
-extern const int of_get_nand_ecc_mode(struct device_node *np);
+int of_get_nand_ecc_mode(struct device_node *np);
 int of_get_nand_bus_width(struct device_node *np);
 bool of_get_nand_on_flash_bbt(struct device_node *np);
 #endif
-- 
1.7.10



signature.asc
Description: This is a digitally signed message part
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

Re: [PATCH] of: mtd: nuke useless const qualifier

[Bityutskiy, Artem]

On Tue, 2012-07-10 at 10:35 -0500, Rob Herring wrote:
  Remove also the unnecessary extern qualifier to be consistent with other
  declarations in this file.
  
  Signed-off-by: Artem Bityutskiy artem.bityuts...@linux.intel.com
  ---
 
 Applied. Next time please don't PGP sign patches.

Thanks. Sure, I'll try.

-- 
Best Regards,
Artem Bityutskiy


signature.asc
Description: This is a digitally signed message part
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.