Re: Kernel 4.1.6 Panic due to slab corruption

[Christoph Lameter]

On Wed, 9 Sep 2015, Nikolay Borisov wrote:

> [root@kernighan vm]# ./slabinfo -da kmalloc-32
> Cannot write to dma-kmalloc-32/sanity
> [root@kernighan vm]# ./slabinfo -dF kmalloc-32
> Cannot write to dma-kmalloc-32/sanity
> [root@kernighan vm]# ./slabinfo -dz kmalloc-32
> kmalloc-32 not empty cannot enable redzoning
> [root@kernighan vm]# ./slabinfo -dp kmalloc-32
> kmalloc-32 not empty cannot enable poisoning
> [root@kernighan vm]# ./slabinfo -du kmalloc-32
> kmalloc-32 not empty cannot enable tracking
> [root@kernighan vm]# ./slabinfo -dt ^kmalloc-32$
> kmalloc-32 can only enable trace for one slab at a time


H.. Whats the problem here?

christoph@gentwo:/sys/kernel/slab/kmalloc-32$ ls -l
total 0
-r 1 root root 4096 Sep  9 08:57 aliases
-r 1 root root 4096 Sep  9 08:57 align
-r 1 root root 4096 Sep  9 08:57 alloc_calls
-r 1 root root 4096 Sep  9 08:57 cache_dma
-rw--- 1 root root 4096 Sep  9 08:57 cpu_partial
-r 1 root root 4096 Sep  9 08:57 cpu_slabs
-r 1 root root 4096 Sep  9 08:57 ctor
-r 1 root root 4096 Sep  9 08:57 destroy_by_rcu
-r 1 root root 4096 Sep  9 08:57 free_calls
-r 1 root root 4096 Sep  9 08:57 hwcache_align
-rw--- 1 root root 4096 Sep  9 08:57 min_partial
-r 1 root root 4096 Sep  9 08:57 objects
-r 1 root root 4096 Sep  9 08:57 object_size
-r 1 root root 4096 Sep  9 08:57 objects_partial
-r 1 root root 4096 Sep  9 08:57 objs_per_slab
-rw--- 1 root root 4096 Sep  9 08:57 order
-r 1 root root 4096 Sep  9 08:57 partial
-rw--- 1 root root 4096 Sep  9 08:57 poison
-rw--- 1 root root 4096 Sep  9 08:57 reclaim_account
-rw--- 1 root root 4096 Sep  9 08:57 red_zone
-rw--- 1 root root 4096 Sep  9 08:57 remote_node_defrag_ratio
-r 1 root root 4096 Sep  9 08:57 reserved
-rw--- 1 root root 4096 Sep  9 08:57 sanity_checks
-rw--- 1 root root 4096 Sep  9 08:57 shrink
-r 1 root root 4096 Sep  9 08:57 slabs
-r 1 root root 4096 Sep  9 08:57 slabs_cpu_partial
-r 1 root root 4096 Sep  9 08:57 slab_size
-rw--- 1 root root 4096 Sep  9 08:57 store_user
-r 1 root root 4096 Sep  9 08:57 total_objects
-rw--- 1 root root 4096 Sep  9 08:57 trace
-rw--- 1 root root 4096 Sep  9 08:57 validate

Try

echo 1 >santy_checks


>
> I did however had success with enabling tracing but couldn't see where
> the output is produced - tried dmesg and the ftrace buffer but nothing
> turned up.

dmesg is the output channel for tracing.

What does:

echo 1 >trace

do? Could crash the sysem due to overload of messages.

> But it seems it is not possible to enable any debugging whatsoever, so I
> will restor to doing it at boot time. In this case can you advice which
> options might not result in very high performance degradation - I'm
> thinking of sanity checking and maybe redzoning?

Sanity checking is ok. But I would think you should be fine with enabling
full debugging on the particular caches of interest.

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

Re: [PATCH 0/5] Add eeprom to the Olimex series of boards

[Maxime Ripard]

On Wed, Sep 09, 2015 at 11:25:10AM +0200, Olliver Schinagl wrote:
> Some of the olimex series of boards feature a permanently connected eeprom on
> i2c-1. This patch series adds them on all the boards that have them according
> to the spec-sheets.
> 
> I explicitly added my personal --Tested-by to boards I actually tested.

Testing your changes is the strict minimum before testing your
patches. Just like running checkpatch on them, which you clearly
failed to do, otherwise you would have seen that this is not the right
syntax. Drop the tested-by, fix your SoB.

> There are two boards, that according to the sheets have them as well
> and physically inspecting the boards shows them clearly, I did not
> actually test them on those the boards that are missing the
> --Tested-by.

Then don't send those patches.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [PATCH v1 3/8] sched/completion: convert completions to use simple wait queues

[Peter Zijlstra]

On Wed, Sep 09, 2015 at 02:05:29PM +0200, Daniel Wagner wrote:
> @@ -50,10 +50,10 @@ void complete_all(struct completion *x)
>  {
>   unsigned long flags;
>  
> - spin_lock_irqsave(>wait.lock, flags);
> + raw_spin_lock_irqsave(>wait.lock, flags);
>   x->done += UINT_MAX/2;
> - __wake_up_locked(>wait, TASK_NORMAL, 0);
> - spin_unlock_irqrestore(>wait.lock, flags);
> + swake_up_locked(>wait);
> + raw_spin_unlock_irqrestore(>wait.lock, flags);
>  }
>  EXPORT_SYMBOL(complete_all);

I don't think that's correct; __wake_up_locked(.nr=0) would wake all
waiters, where swake_up_locked() will only wake one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] Add eeprom to the Olimex series of boards

[Olliver Schinagl]

On 09-09-15 16:05, Maxime Ripard wrote:

On Wed, Sep 09, 2015 at 11:25:10AM +0200, Olliver Schinagl wrote:

Some of the olimex series of boards feature a permanently connected eeprom on
i2c-1. This patch series adds them on all the boards that have them according
to the spec-sheets.

I explicitly added my personal --Tested-by to boards I actually tested.

Testing your changes is the strict minimum before testing your
patches. Just like running checkpatch on them, which you clearly
failed to do, otherwise you would have seen that this is not the right
syntax. Drop the tested-by, fix your SoB.
Actually, I did run check-patch and it complained about the format, but 
it was the same as when outputted with a git -s. I obviously missed 
something there! So I double check that. I will resubmit without a 
tested-by for the boards I did test it on.



There are two boards, that according to the sheets have them as well
and physically inspecting the boards shows them clearly, I did not
actually test them on those the boards that are missing the
--Tested-by.

Then don't send those patches.
I put them out there so someone could pick up on that with the least 
amount of effort. I will drop them


Maxime



--
Met vriendelijke groeten, Kind regards, 与亲切的问候

Olliver Schinagl
Research & Development
Ultimaker B.V.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mpt3sas: Refcount sas_device objects and fix unsafe list usage

[Chaitra Basappa]

From: Sreekanth Reddy [mailto:sreekanth.re...@avagotech.com]
Sent: Tuesday, September 08, 2015 5:26 PM
To: Nicholas A. Bellinger
Cc: linux-scsi; linux-kernel; James Bottomley; Calvin Owens; Christoph
Hellwig; MPT-FusionLinux.pdl; kernel-team; Nicholas Bellinger; Chaitra
Basappa
Subject: Re: [PATCH-v2 1/2] mpt3sas: Refcount sas_device objects and fix
unsafe list usage

On Sun, Aug 30, 2015 at 1:24 PM, Nicholas A. Bellinger 
wrote:
> From: Nicholas Bellinger 
>
> These objects can be referenced concurrently throughout the driver, we
> need a way to make sure threads can't delete them out from under each
> other. This patch adds the refcount, and refactors the code to use it.
>
> Additionally, we cannot iterate over the sas_device_list without
> holding the lock, or we risk corrupting random memory if items are
> added or deleted as we iterate. This patch refactors
> _scsih_probe_sas() to use the sas_device_list in a safe way.
>
> This patch is a port of Calvin's PATCH-v4 for mpt2sas code, atop
> mpt3sas changes in scsi.git/for-next.
>
> Cc: Calvin Owens 
> Cc: Christoph Hellwig 
> Cc: Sreekanth Reddy 
> Cc: MPT-FusionLinux.pdl 
> Signed-off-by: Nicholas Bellinger 
> ---
>  drivers/scsi/mpt3sas/mpt3sas_base.h  |  25 +-
>  drivers/scsi/mpt3sas/mpt3sas_scsih.c | 479
> +--
>  drivers/scsi/mpt3sas/mpt3sas_transport.c |  18 +-
>  3 files changed, 364 insertions(+), 158 deletions(-)
>
> @@ -2763,7 +2874,7 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc,
> u16 handle)
> struct scsi_device *sdev;
> struct _sas_device *sas_device;
>

[Sreekanth] Here sas_device_lock spin lock needs to be acquired before
calling
  __mpt3sas_get_sdev_by_addr() function.

[Chaitra]Here instead of calling " __mpt3sas_get_sdev_by_handle()" function
calling
"mpt3sas_get_sdev_by_handle()" function will fixes "invalid page access"
type of kernel panic

> -   sas_device = _scsih_sas_device_find_by_handle(ioc, handle);
> +   sas_device = __mpt3sas_get_sdev_by_handle(ioc, handle);
> if (!sas_device)
> return;
>
> @@ -2779,6 +2890,8 @@ _scsih_block_io_device(struct MPT3SAS_ADAPTER *ioc,
> u16 handle)
> continue;
> _scsih_internal_device_block(sdev, sas_device_priv_data);
> }
> +
> +   sas_device_put(sas_device);
>  }
>


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

RE: [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order

[Anaczkowski, Lukasz]

-Original Message-
From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com] 
Sent: Wednesday, September 9, 2015 3:56 PM

> On Wed, Sep 09, 2015 at 10:30:18AM +0100, Lukasz Anaczkowski wrote:
> > () it's hard to predict how cores and threads are enumerated

> So ? Why would the logical cpus order matters at all ? I guessed
> there are probeable properties that allows the kernel to build
> the affinity (ie topology list, shared caches, smt siblings, etc).
> Please explain, since I am confused, to me all you need is a list
> of existing physical ids, in whatever order they come, that's at least
> what we need on ARM.

Hi Lorenzo,

Sure, let me try to explain this better.

Proper (i.e. predictable way of CPU enumeration) matters for HPC software,
(this is where I come from) as there are workloads that have some assumptions 
on CPU enumeration in order to keep cache hit ratio as high as possible.
E.g. in KNL cores share L2 caches, and if during enumeration logical cores do 
not
reflect physical cores, S/W can start affinitize threads to the same physical 
cores
causing great performance impact exactly due to L2 cache misses.
(e.g. s/w assumes that HT CPUs are separated by core count).

Now, those changes would not be required if someone who have written
APIC spec had reserved more than just 1 byte for CPU id :)
Unfortunately, it's the case for x86 APIC ID and once it turns out there's a 
need
to enumerate more than that, they added X2APIC spec which has 4 bytes for ID.
Even that would be also fine if there were just physical cores, but with HT, 
ACPI
clearly says, that first must be listed physical cores and only after that HT 
CPUs
(and that's why APIC/X2APIC subtables are interleaved).

When GIC spec was added, someone was smart enough to put 4 bytes from
the begging, so you don't need to care about it on ARM :)

> > () enumeration is inconsistent with how threads are enumerated on
> >other Intel Xeon processors

> And why does that matter ? Is it because userspace is making assumptions
> on the logical cpu enumeration scheme ? I am just asking, I would
> like to understand.

Yes, HPC software makes some assumptions about CPU enumeration (as mentioned 
above) and having inconsistent enumeration between different x86 CPUs (Xeon vs 
Xeon Phi)
make such s/w basically not portable.

> > So, order in which MADT APIC/X2APIC handlers are passed is
> > reverse and both handlers are passed to be called during same MADT
> > table to walk to achieve correct CPU enumeration.

> Define "correct" please, you define the logical ordering you
> want to achieve, you do not define why that's more "correct"
> than the current implementation.

Ok, probably 'correct' word is not the best here :)
Does 'compatible' sound better?

Thanks,
Lukasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sched: Implement interface for cgroup unified hierarchy

[Paul Turner]

[ Picking this back up, I was out of the country last week.  Note that
we are also wrestling with some DMARC issues as it was just activated
for Google.com so apologies if people do not receive this directly. ]

On Tue, Aug 25, 2015 at 2:02 PM, Tejun Heo  wrote:
> Hello,
>
> On Mon, Aug 24, 2015 at 04:06:39PM -0700, Paul Turner wrote:
>> > This is an erratic behavior on cpuset's part tho.  Nothing else
>> > behaves this way and it's borderline buggy.
>>
>> It's actually the only sane possible interaction here.
>>
>> If you don't overwrite the masks you can no longer manage cpusets with
>> a multi-threaded application.
>> If you partially overwrite the masks you can create a host of
>> inconsistent behaviors where an application suddenly loses
>> parallelism.
>
> It's a layering problem.  It'd be fine if cpuset either did "layer
> per-thread affinities below w/ config change notification" or "ignore
> and/or reject per-thread affinities".  What we have now is two layers
> manipulating the same field without any mechanism for coordination.
>

I think this is a mischaracterization.  With respect to the two
proposed solutions:

a) Notifications do not solve this problem.
b) Rejecting per-thread affinities is a non-starter.  It's absolutely
needed.  (Aside:  This would also wholly break the existing
sched_setaffinity/getaffinity syscalls.)

I do not think this is a layering problem.  This is more like C++:
there is no sane way to concurrently use all the features available,
however, reasonably self-consistent subsets may be chosen.

>> The *only* consistent way is to clobber all masks uniformly.  Then
>> either arrange for some notification to the application to re-sync, or
>> use sub-sub-containers within the cpuset hierarchy to advertise
>> finer-partitions.
>
> I don't get it.  How is that the only consistent way?  Why is making
> irreversible changes even a good way?  Just layer the masks and
> trigger notification on changes.

I'm not sure if you're agreeing or disagreeing here.  Are you saying
there's another consistent way from "clobbering then triggering
notification changes" since it seems like that's what is rejected and
then described.  This certainly does not include any provisions for
reversibility (which I think is a non-starter).

With respect to layering:  Are you proposing we maintain a separate
mask for sched_setaffinity and cpusets, then do different things
depending on their intersection, or lack thereof?  I feel this would
introduce more consistencies than it would solve as these masks would
not be separately inspectable from user-space, leading to confusing
interactions as they are changed.

There are also very real challenges with how any notification is
implemented, independent of delivery:
The 'main' of an application often does not have good control or even
understanding over its own threads since many may be library managed.
Designation of responsibility for updating these masks is difficult.
That said, I think a notification would still be a useful improvement
here and that some applications would benefit.

At the very least, I do not think that cpuset's behavior here can be
dismissed as unreasonable.

>
>> I don't think the case of having a large compute farm with
>> "unimportant" and "important" work is particularly fringe.  Reducing
>> the impact on the "important" work so that we can scavenge more cycles
>> for the latency insensitive "unimportant" is very real.
>
> What if optimizing cache allocation across competing threads of a
> process can yield, say, 3% gain across large compute farm?  Is that
> fringe?

Frankly, yes.  If you have a compute farm sufficiently dedicated to a
single application I'd say that's a fairly specialized use.  I see no
reason why a more 'technical' API should be a challenge for such a
user.  The fundamental point here was that it's ok for the API of some
controllers to be targeted at system rather than user control in terms
of interface.  This does not restrict their use by users where
appropriate.

>
>> Right, but it's exactly because of _how bad_ those other mechanisms
>> _are_ that cgroups was originally created.Its growth was not
>> managed well from there, but let's not step away from the fact that
>> this interface was created to solve this problem.
>
> Sure, at the same time, please don't forget that there are ample
> reasons we can't replace more basic mechanisms with cgroups.  I'm not
> saying this can't be part of cgroup but rather that it's misguided to
> do plunge into cgroups as the first and only step.
>

So there is definitely a proliferation of discussion regarding
applying cgroups to other problems which I agree we need to take a
step back and re-examine.

However, here we're fundamentally talking about APIs designed to
partition resources which is the problem that cgroups was introduced
to address.  If we want to introduce another API to do that below the
process level we need to talk about why it's 

[PATCH v3 2/5] selftests: mqueue: allow extra cflags

[Bamvor Jian Zhang]

Change from = to += in order to allows the user to pass whatever
CFLAGS they wish(E.g. pass the proper headers and librareis
(popt.h and libpopt.so) in cross-compiling)

Suggested-by: Michael Ellermani 
Signed-off-by: Bamvor Jian Zhang 
Acked-by: Michael Ellermani 
---
 tools/testing/selftests/mqueue/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/mqueue/Makefile 
b/tools/testing/selftests/mqueue/Makefile
index 0e3b41e..ca8327f 100644
--- a/tools/testing/selftests/mqueue/Makefile
+++ b/tools/testing/selftests/mqueue/Makefile
@@ -1,4 +1,4 @@
-CFLAGS = -O2
+CFLAGS += -O2
 
 all:
$(CC) $(CFLAGS) mq_open_tests.c -o mq_open_tests -lrt
-- 
2.1.4

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

[PATCH v3 4/5] selftests: change install command to rsync

[Bamvor Jian Zhang]

The command of install could not handle the special files in exec
testcases, change the default rule to rsync to fix this.

The installation is unchanged after this commit.

Suggested-by: Michael Ellerman 
Signed-off-by: Bamvor Jian Zhang 
---
 tools/testing/selftests/ftrace/Makefile |  2 +-
 tools/testing/selftests/lib.mk  | 11 ---
 2 files changed, 5 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/ftrace/Makefile 
b/tools/testing/selftests/ftrace/Makefile
index 0acbeca..4e6ed13 100644
--- a/tools/testing/selftests/ftrace/Makefile
+++ b/tools/testing/selftests/ftrace/Makefile
@@ -1,7 +1,7 @@
 all:
 
 TEST_PROGS := ftracetest
-TEST_DIRS := test.d/
+TEST_DIRS := test.d
 
 include ../lib.mk
 
diff --git a/tools/testing/selftests/lib.mk b/tools/testing/selftests/lib.mk
index 97f1c67..50a93f5 100644
--- a/tools/testing/selftests/lib.mk
+++ b/tools/testing/selftests/lib.mk
@@ -12,13 +12,10 @@ run_tests: all
$(RUN_TESTS)
 
 define INSTALL_RULE
-   @if [ "X$(TEST_PROGS)$(TEST_PROGS_EXTENDED)$(TEST_FILES)" != "X" ]; 
then\
-   mkdir -p $(INSTALL_PATH);   
\
-   for TEST_DIR in $(TEST_DIRS); do
\
-   cp -r $$TEST_DIR $(INSTALL_PATH);   
\
-   done;   
\
-   echo "install -t $(INSTALL_PATH) $(TEST_PROGS) 
$(TEST_PROGS_EXTENDED) $(TEST_FILES)";   \
-   install -t $(INSTALL_PATH) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) 
$(TEST_FILES);  \
+   @if [ "X$(TEST_PROGS)$(TEST_PROGS_EXTENDED)$(TEST_FILES)" != "X" ]; 
then\
+   mkdir -p ${INSTALL_PATH};   
\
+   echo "rsync -a $(TEST_DIRS) $(TEST_PROGS) 
$(TEST_PROGS_EXTENDED) $(TEST_FILES) $(INSTALL_PATH)/";   \
+   rsync -a $(TEST_DIRS) $(TEST_PROGS) $(TEST_PROGS_EXTENDED) 
$(TEST_FILES) $(INSTALL_PATH)/;  \
fi
 endef
 
-- 
2.1.4

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

[PATCH v3 5/5] selftests: exec: revert to default emit rule

[Bamvor Jian Zhang]

With the previous patch, the installation method change from install
to rsync. There is no need to create subdir during test, the
default EMIT_TESTS is enough.

This patch essentially revert commit 84cbd9e4 ("selftests/exec: do not
install subdir as it is already created").

Suggested-by: Michael Ellerman 
Signed-off-by: Bamvor Jian Zhang 
---
 tools/testing/selftests/exec/Makefile | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/tools/testing/selftests/exec/Makefile 
b/tools/testing/selftests/exec/Makefile
index 6b76bfd..4e400eb 100644
--- a/tools/testing/selftests/exec/Makefile
+++ b/tools/testing/selftests/exec/Makefile
@@ -1,6 +1,6 @@
 CFLAGS = -Wall
 BINARIES = execveat
-DEPS = execveat.symlink execveat.denatured script
+DEPS = execveat.symlink execveat.denatured script subdir
 all: $(BINARIES) $(DEPS)
 
 subdir:
@@ -22,7 +22,5 @@ TEST_FILES := $(DEPS)
 
 include ../lib.mk
 
-override EMIT_TESTS := echo "mkdir -p subdir; (./execveat && echo \"selftests: 
execveat [PASS]\") || echo \"selftests: execveat [FAIL]\""
-
 clean:
rm -rf $(BINARIES) $(DEPS) subdir.moved execveat.moved x*
-- 
2.1.4

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

[PATCH linux-next v6 1/8] mtd: spi-nor: read JEDEC ID with multiple I/O protocols

[Cyrille Pitchen]

When their quad or dual I/O mode is enabled, Micron and Macronix spi-nor
memories don't reply to the regular Read ID (0x9f) command. Instead they
reply to a new dedicated command Read ID Multiple I/O (0xaf).

If the Read ID (0x9f) command fails (the read ID is all 1's or all 0's),
then the Read ID Multiple I/O (0xaf) is used, first with SPI 4-4-4 protocol
(supported by both Micron and Macronix memories), lately with SPI-2-2-2
protocol (supported only by Micron memories).

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/spi-nor.c | 28 +++-
 include/linux/mtd/spi-nor.h   | 23 +--
 2 files changed, 48 insertions(+), 3 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index f59aedfe1462..80a0db078aaa 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -703,8 +703,9 @@ static const struct flash_info spi_nor_ids[] = {
 
 static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
 {
-   int tmp;
+   int i, tmp;
u8  id[SPI_NOR_MAX_ID_LEN];
+   enum spi_protocol   proto[2] = {SPI_PROTO_4_4_4, SPI_PROTO_2_2_2};
const struct flash_info *info;
 
tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
@@ -713,6 +714,25 @@ static const struct flash_info *spi_nor_read_id(struct 
spi_nor *nor)
return ERR_PTR(tmp);
}
 
+   /* Special case for Micron/Macronix qspi nor. */
+   for (i = 0; i < ARRAY_SIZE(proto); ++i) {
+   if (!((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
+ (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00)))
+   break;
+
+   nor->erase_proto = proto[i];
+   nor->read_proto = proto[i];
+   nor->write_proto = proto[i];
+   nor->reg_proto = proto[i];
+   tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID,
+   id, SPI_NOR_MAX_ID_LEN);
+   if (tmp < 0) {
+   dev_dbg(nor->dev,
+   " error %d reading JEDEC ID (MULTI IO)\n", tmp);
+   return ERR_PTR(tmp);
+   }
+   }
+
for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
info = _nor_ids[tmp];
if (info->id_len) {
@@ -1013,6 +1033,12 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
enum read_mode mode)
if (ret)
return ret;
 
+   /* Reset SPI protocol for all commands */
+   nor->erase_proto = SPI_PROTO_1_1_1;
+   nor->read_proto = SPI_PROTO_1_1_1;
+   nor->write_proto = SPI_PROTO_1_1_1;
+   nor->reg_proto = SPI_PROTO_1_1_1;
+
if (name)
info = spi_nor_match_id(name);
/* Try to auto-detect if chip name wasn't specified or not found */
diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index e5409524bb0a..66a5f144728a 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -57,8 +57,9 @@
 #define SPINOR_OP_BRWR 0x17/* Bank register write */
 
 /* Used for Micron flashes only. */
-#define SPINOR_OP_RD_EVCR  0x65/* Read EVCR register */
-#define SPINOR_OP_WD_EVCR  0x61/* Write EVCR register */
+#define SPINOR_OP_MIO_RDID 0xaf/* Multiple I/O Read JEDEC ID */
+#define SPINOR_OP_RD_EVCR  0x65/* Read EVCR register */
+#define SPINOR_OP_WD_EVCR  0x61/* Write EVCR register */
 
 /* Status Register bits. */
 #define SR_WIP 1   /* Write in progress */
@@ -87,6 +88,16 @@ enum read_mode {
SPI_NOR_QUAD,
 };
 
+enum spi_protocol {
+   SPI_PROTO_1_1_1,/* SPI */
+   SPI_PROTO_1_1_2,/* Dual Output */
+   SPI_PROTO_1_1_4,/* Quad Output */
+   SPI_PROTO_1_2_2,/* Dual IO */
+   SPI_PROTO_1_4_4,/* Quad IO */
+   SPI_PROTO_2_2_2,/* Dual Command */
+   SPI_PROTO_4_4_4,/* Quad Command */
+};
+
 /**
  * struct spi_nor_xfer_cfg - Structure for defining a Serial Flash transfer
  * @wren:  command for "Write Enable", or 0x00 for not required
@@ -142,6 +153,10 @@ enum spi_nor_option_flags {
  * @sst_write_second:  used by the SST write operation
  * @flags: flag options for the current SPI-NOR (SNOR_F_*)
  * @cfg:   used by the read_xfer/write_xfer
+ * @erase_proto:   the SPI protocol used by erase operations
+ * @read_proto:the SPI protocol used by read operations
+ * @write_proto:   the SPI protocol used by write operations
+ * @reg_proto  the SPI protocol used by read_reg/write_reg operations
  * @cmd_buf:   used by the write_reg
  * @prepare:   [OPTIONAL] do some preparations for the
  * read/write/erase/lock/unlock operations
@@ 

[PATCH linux-next v6 3/8] mtd: spi-nor: update the SPI protocol when enabling manufacturer Quad mode

[Cyrille Pitchen]

Micron:
Once their Quad SPI protocol enabled, Micron spi-nor memories expect all
commands to use the SPI 4-4-4 protocol. Also when the Dual SPI protocol is
enabled, all commands must use the SPI 2-2-2 protocol.

Macronix:
When the QPI mode is enabled, all commands must use the SPI 4-4-4 protocol.

Spansion:
When Quad I/O operations are enabled, the Fast Read Quad Output (0x6b / 0x6c)
commands use the SPI 1-1-4 protocol, the Page Program Quad Output (0x32 /
0x34) command use the SPI 1-1-4 protocol whereas other commands use the
SPI 1-1-1 protocol.

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/spi-nor.c | 74 ---
 include/linux/mtd/spi-nor.h   |  1 +
 2 files changed, 70 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 80a0db078aaa..4b36aada3f4c 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -891,6 +891,12 @@ static int macronix_quad_enable(struct spi_nor *nor)
nor->cmd_buf[0] = val | SR_QUAD_EN_MX;
nor->write_reg(nor, SPINOR_OP_WRSR, nor->cmd_buf, 1, 0);
 
+   /* Once QPI mode enabled, all commands use SPI 4-4-4 protocol. */
+   nor->erase_proto = SPI_PROTO_4_4_4;
+   nor->read_proto = SPI_PROTO_4_4_4;
+   nor->write_proto = SPI_PROTO_4_4_4;
+   nor->reg_proto = SPI_PROTO_4_4_4;
+
if (spi_nor_wait_till_ready(nor))
return 1;
 
@@ -938,10 +944,16 @@ static int spansion_quad_enable(struct spi_nor *nor)
return -EINVAL;
}
 
+   /* set read/write protocols */
+   nor->read_proto = SPI_PROTO_1_1_4;
+   nor->write_proto = SPI_PROTO_1_1_4;
+
return 0;
 }
 
-static int micron_quad_enable(struct spi_nor *nor)
+static int micron_set_protocol(struct spi_nor *nor,
+  u8 mask, u8 value,
+  enum spi_protocol proto)
 {
int ret;
u8 val;
@@ -954,14 +966,20 @@ static int micron_quad_enable(struct spi_nor *nor)
 
write_enable(nor);
 
-   /* set EVCR, enable quad I/O */
-   nor->cmd_buf[0] = val & ~EVCR_QUAD_EN_MICRON;
+   /* set EVCR protocol bits */
+   nor->cmd_buf[0] = (val & ~mask) | value;
ret = nor->write_reg(nor, SPINOR_OP_WD_EVCR, nor->cmd_buf, 1, 0);
if (ret < 0) {
dev_err(nor->dev, "error while writing EVCR register\n");
return ret;
}
 
+   /* switch protocol for ALL commands */
+   nor->erase_proto = proto;
+   nor->read_proto = proto;
+   nor->write_proto = proto;
+   nor->reg_proto = proto;
+
ret = spi_nor_wait_till_ready(nor);
if (ret)
return ret;
@@ -972,14 +990,23 @@ static int micron_quad_enable(struct spi_nor *nor)
dev_err(nor->dev, "error %d reading EVCR\n", ret);
return ret;
}
-   if (val & EVCR_QUAD_EN_MICRON) {
-   dev_err(nor->dev, "Micron EVCR Quad bit not clear\n");
+   if ((val & mask) != value) {
+   dev_err(nor->dev, "Micron EVCR protocol bits not valid\n");
return -EINVAL;
}
 
return 0;
 }
 
+static inline int micron_quad_enable(struct spi_nor *nor)
+{
+   /* Clear Quad bit to enable quad mode */
+   return micron_set_protocol(nor,
+  EVCR_QUAD_EN_MICRON | EVCR_DUAL_EN_MICRON,
+  EVCR_DUAL_EN_MICRON,
+  SPI_PROTO_4_4_4);
+}
+
 static int set_quad_mode(struct spi_nor *nor, const struct flash_info *info)
 {
int status;
@@ -1009,6 +1036,38 @@ static int set_quad_mode(struct spi_nor *nor, const 
struct flash_info *info)
}
 }
 
+static inline int micron_dual_enable(struct spi_nor *nor)
+{
+   /* Clear Dual bit but keep Quad bit set to enable dual mode */
+   return micron_set_protocol(nor,
+  EVCR_QUAD_EN_MICRON | EVCR_DUAL_EN_MICRON,
+  EVCR_QUAD_EN_MICRON,
+  SPI_PROTO_2_2_2);
+}
+
+static int set_dual_mode(struct spi_nor *nor, const struct flash_info *info)
+{
+   int status;
+
+   switch (JEDEC_MFR(info)) {
+   case CFI_MFR_ST:
+   status = micron_dual_enable(nor);
+   if (status) {
+   dev_err(nor->dev, "Micron dual-read not enabled\n");
+   return -EINVAL;
+   }
+   return status;
+   case CFI_MFR_MACRONIX:
+   case CFI_MFR_AMD:
+   nor->read_proto = SPI_PROTO_1_1_2;
+   break;
+   default:
+   break;
+   }
+
+   return 0;
+}
+
 static int spi_nor_check(struct spi_nor *nor)
 {
if (!nor->dev || !nor->read || !nor->write ||
@@ -1160,6 +1219,11 @@ int spi_nor_scan(struct spi_nor *nor, const char *name, 
enum read_mode mode)
}
  

[PATCH linux-next v6 2/8] mtd: spi-nor: remove unused read_xfer/write_xfer hooks

[Cyrille Pitchen]

struct spi_nor_xfer_cfg and read_xfer/write_xfer hooks were never used by
any driver. Do some cleanup by removing them.

Signed-off-by: Cyrille Pitchen 
---
 include/linux/mtd/spi-nor.h | 35 ---
 1 file changed, 35 deletions(-)

diff --git a/include/linux/mtd/spi-nor.h b/include/linux/mtd/spi-nor.h
index 66a5f144728a..08e405cbb6af 100644
--- a/include/linux/mtd/spi-nor.h
+++ b/include/linux/mtd/spi-nor.h
@@ -98,33 +98,6 @@ enum spi_protocol {
SPI_PROTO_4_4_4,/* Quad Command */
 };
 
-/**
- * struct spi_nor_xfer_cfg - Structure for defining a Serial Flash transfer
- * @wren:  command for "Write Enable", or 0x00 for not required
- * @cmd:   command for operation
- * @cmd_pins:  number of pins to send @cmd (1, 2, 4)
- * @addr:  address for operation
- * @addr_pins: number of pins to send @addr (1, 2, 4)
- * @addr_width:number of address bytes
- * (3,4, or 0 for address not required)
- * @mode:  mode data
- * @mode_pins: number of pins to send @mode (1, 2, 4)
- * @mode_cycles:   number of mode cycles (0 for mode not required)
- * @dummy_cycles:  number of dummy cycles (0 for dummy not required)
- */
-struct spi_nor_xfer_cfg {
-   u8  wren;
-   u8  cmd;
-   u8  cmd_pins;
-   u32 addr;
-   u8  addr_pins;
-   u8  addr_width;
-   u8  mode;
-   u8  mode_pins;
-   u8  mode_cycles;
-   u8  dummy_cycles;
-};
-
 #define SPI_NOR_MAX_CMD_SIZE   8
 enum spi_nor_ops {
SPI_NOR_OPS_READ = 0,
@@ -152,7 +125,6 @@ enum spi_nor_option_flags {
  * @flash_read:the mode of the read
  * @sst_write_second:  used by the SST write operation
  * @flags: flag options for the current SPI-NOR (SNOR_F_*)
- * @cfg:   used by the read_xfer/write_xfer
  * @erase_proto:   the SPI protocol used by erase operations
  * @read_proto:the SPI protocol used by read operations
  * @write_proto:   the SPI protocol used by write operations
@@ -162,8 +134,6 @@ enum spi_nor_option_flags {
  * read/write/erase/lock/unlock operations
  * @unprepare: [OPTIONAL] do some post work after the
  * read/write/erase/lock/unlock operations
- * @read_xfer: [OPTIONAL] the read fundamental primitive
- * @write_xfer:[OPTIONAL] the writefundamental primitive
  * @read_reg:  [DRIVER-SPECIFIC] read out the register
  * @write_reg: [DRIVER-SPECIFIC] write data to the register
  * @read:  [DRIVER-SPECIFIC] read data from the SPI NOR
@@ -191,15 +161,10 @@ struct spi_nor {
enum read_mode  flash_read;
boolsst_write_second;
u32 flags;
-   struct spi_nor_xfer_cfg cfg;
u8  cmd_buf[SPI_NOR_MAX_CMD_SIZE];
 
int (*prepare)(struct spi_nor *nor, enum spi_nor_ops ops);
void (*unprepare)(struct spi_nor *nor, enum spi_nor_ops ops);
-   int (*read_xfer)(struct spi_nor *nor, struct spi_nor_xfer_cfg *cfg,
-u8 *buf, size_t len);
-   int (*write_xfer)(struct spi_nor *nor, struct spi_nor_xfer_cfg *cfg,
- u8 *buf, size_t len);
int (*read_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len);
int (*write_reg)(struct spi_nor *nor, u8 opcode, u8 *buf, int len,
int write_enable);
-- 
1.8.2.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 linux-next v6 0/8] add driver for Atmel QSPI controller

[Cyrille Pitchen]

ChangeLog

v6:
- add new patch which tries to read the JEDEC ID with different SPI protocols
  and different commands: 0x9f (SPI-1-1-1), 0xaf (SPI-4-4-4) and finally
  0xaf (SPI-2-2-2).
- remove the set_protocol() hook from struct spi_nor and add 4 new members
  instead of type enum spi_protocol:
  read_proto, write_proto, erase_proto, reg_proto.
  The relevant protocol value should be checked by the driver specific read(),
  write(), erase(), read_reg() and write_reg() hook implementations.
- remove unused hooks: write_xfer() and read_xfer().
- tune the op code for read, write and erase commands depending on the memory
  manufacturer.
- remove some previously added "Acked-by" since the protocol switch strategy
  has been changed but not discussed yet.

v5:
- remove unused inline functions qspi_read[bw]() and qspi_write[bw](),
  keep only qspi_readl() and qspi_writel().
- use reinit_completion() instead of init_completion() during run time,
  call init_completion() once for all in the probe().
- add a dev_warn() when trying to tune the number of dummy cycles for
  spi-nor of a not supported manufacturer then fall back to the default
  framework value.
- reword some comments.
- add "Acked-by: Marek Vasut " for patches 1 and 4.
- add "Acked-by: Bean Huo " for patch 1.

v4:
- add "OF && HAS_DMA" dependency in Kconfig for Atmel Quad SPI driver.
- return -ENOMEM instead of the return code of dma_mapping_error() as this
  function returns a boolean on ARM achitecture.
- add "Acked-by: Nicolas Ferre " for Atmel Quad
  SPI driver and its DT binding documentation.

v3:
- reword the comment which explains that spi_nor_set_protocol() is used by
  the spi-nor framework to notify lower layers, especially the (Q)SPI
  controller about a protocol change.
- change the definitions of register/bitfield macros in the Atmel QSPI
  controller driver: get rid of concatenation operator and use BIT and
  GENMASK macros when possible.
- use #define[SPACE] instead of #define[TAB]

v2:
- remove the patches to set the "latency code" of Spansion QSPI memories
  (support of Spansion memories may be submitted in later series).
- rename "qspi" node into "spi" in the DT example to fit ePAPR standard.
- remove the useless "qspi0" label from the DT node example.
- remove the leading 0 from the size of the second memory region to make
  it consistent with the size of the first memory region.
- indent the DT bindings documentation to make it more readable.
- remove the useless ".bus  = _bus_type," line from the
  platform driver definition.

v1:

This series of patches add support for the new Atmel QSPI controller
embedded inside sama5d2x SoCs.

These patches were first developped for linux-3.18-at91 and tested on a
sama5d27 Xplained ultra board, which embeds a Micron n25q128a13 QSPI NOR
flash memory. Then the series was adapted for mainline.

Cyrille Pitchen (8):
  mtd: spi-nor: read JEDEC ID with multiple I/O protocols
  mtd: spi-nor: remove unused read_xfer/write_xfer hooks
  mtd: spi-nor: update the SPI protocol when enabling manufacturer Quad
mode
  mtd: spi-nor: use optimized commands for read/write/erase operations
  Documentation: mtd: add a DT property to set the number of dummy
cycles
  mtd: spi-nor: allow to tune the number of dummy cycles
  Documentation: atmel-quadspi: add binding file for Atmel QSPI driver
  mtd: atmel-quadspi: add driver for Atmel QSPI controller

 .../devicetree/bindings/mtd/atmel-quadspi.txt  |  29 +
 .../devicetree/bindings/mtd/jedec,spi-nor.txt  |   6 +
 drivers/mtd/spi-nor/Kconfig|   7 +
 drivers/mtd/spi-nor/Makefile   |   1 +
 drivers/mtd/spi-nor/atmel-quadspi.c| 889 +
 drivers/mtd/spi-nor/spi-nor.c  | 356 +++--
 include/linux/mtd/spi-nor.h|  63 +-
 7 files changed, 1269 insertions(+), 82 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
 create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c

-- 
1.8.2.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 v12 16/21] x86/asm/crypto: Create stack frames in clmul_ghash_mul/update()

[Josh Poimboeuf]

clmul_ghash_mul() and clmul_ghash_update() are callable non-leaf
functions which don't honor CONFIG_FRAME_POINTER, which can result in
bad stack traces.

Create stack frames for them when CONFIG_FRAME_POINTER is enabled.

Signed-off-by: Josh Poimboeuf 
Cc: Herbert Xu 
Cc: "David S. Miller" 
---
 arch/x86/crypto/ghash-clmulni-intel_asm.S | 5 +
 1 file changed, 5 insertions(+)

diff --git a/arch/x86/crypto/ghash-clmulni-intel_asm.S 
b/arch/x86/crypto/ghash-clmulni-intel_asm.S
index 5d1e007..eed55c8 100644
--- a/arch/x86/crypto/ghash-clmulni-intel_asm.S
+++ b/arch/x86/crypto/ghash-clmulni-intel_asm.S
@@ -18,6 +18,7 @@
 
 #include 
 #include 
+#include 
 
 .data
 
@@ -94,6 +95,7 @@ ENDPROC(__clmul_gf128mul_ble)
 
 /* void clmul_ghash_mul(char *dst, const u128 *shash) */
 ENTRY(clmul_ghash_mul)
+   FRAME_BEGIN
movups (%rdi), DATA
movups (%rsi), SHASH
movaps .Lbswap_mask, BSWAP
@@ -101,6 +103,7 @@ ENTRY(clmul_ghash_mul)
call __clmul_gf128mul_ble
PSHUFB_XMM BSWAP DATA
movups DATA, (%rdi)
+   FRAME_END
ret
 ENDPROC(clmul_ghash_mul)
 
@@ -109,6 +112,7 @@ ENDPROC(clmul_ghash_mul)
  *const u128 *shash);
  */
 ENTRY(clmul_ghash_update)
+   FRAME_BEGIN
cmp $16, %rdx
jb .Lupdate_just_ret# check length
movaps .Lbswap_mask, BSWAP
@@ -128,5 +132,6 @@ ENTRY(clmul_ghash_update)
PSHUFB_XMM BSWAP DATA
movups DATA, (%rdi)
 .Lupdate_just_ret:
+   FRAME_END
ret
 ENDPROC(clmul_ghash_update)
-- 
2.4.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 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory

[Tomasz Nowicki]

Hi Lorenzo,

On 08.09.2015 17:07, Lorenzo Pieralisi wrote:

Hi Tomasz,

On Mon, Sep 07, 2015 at 10:59:44AM +0100, Tomasz Nowicki wrote:

On 31.08.2015 13:01, Tomasz Nowicki wrote:

On 08.06.2015 17:14, Lorenzo Pieralisi wrote:

On Mon, Jun 08, 2015 at 03:57:38AM +0100, Hanjun Guo wrote:

[...]


Why can't we make use of the ECAM implementation used by
pci-host-generic
and drivers/pci/access.c?


We had that question when I had posted MMCFG patch set separately,
please see:
https://lkml.org/lkml/2015/3/11/492


Yes, but the real question is, why do we need to have PCI config
space
up and running before a bus struct is even created ? I think the
reason is
the PCI configuration address space format (ACPI 6.0, Table 5-27,
page
108):

"PCI Configuration space addresses must be confined to devices on
PCI Segment Group 0, bus 0. This restriction exists to accommodate
access to fixed hardware prior to PCI bus enumeration".

On HW reduced platforms I do not even think this is required at all,
we have to look into this to avoid code duplication that might well
turn out useless.


This is only for the fixed hardware, which will be not available for
ARM64 (reduced hardware mode), but in Generic Hardware Programming
Model, we using OEM-provided ACPI Machine Language (AML) code to
access
generic hardware registers, this will be available for reduced
hardware
too.

So in ACPI spec, it says: (ACPI 6.0 page 66, last paragraph)

ACPI defines eight address spaces that may be accessed by generic
hardware implementations. These include:
* System I/O space
* System memory space
* PCI configuration space
* Embedded controller space
* System Management Bus (SMBus) space
* CMOS
* PCI BAR Target
* IPMI space

So if any device using the PCI address space for control, such
as a system reset control device, its address space can be reside
in PCI configuration space (who can prevent a OEM do that crazy
thing? :) ), and it should be accessible before the PCI bus is
created.


Us, by changing attitude and questioning features whose usefulness
is questionable. I will look into this and raise the point, I am not
thrilled by the idea of adding another set of PCI accessor functions
and drivers because we have to access a register through PCI before
enumerating the bus (and on arm64 this is totally useless since
we are not meant to support fixed HW anyway). Maybe we can make acpica
code use a "special" stub (ACPI specific, PCI configuration space
address
space has restrictions anyway), I have to review this set in its
entirety to see how to do that (and I would kindly ask you to do
it too, before saying it is not possible to implement it).


I'm willing to do that, actually, if we don't need a mechanism to
access PCI config space before the bus is created, the code can be
simplified a lot.


After more investigation on the spec and the ACPI core code, I'm
still not convinced that accessing to PCI config space before PCI
bus creating is impossible, also there is no enough ARM64 hardware
to prove that too. But I think we can go in this way, reuse the
ECAM implementation by pci-host-generic for now, and implement the PCI
accessor functions before enumerating PCI bus when needed in the
future, does it make sense?


You mean we rewrite the patch to make sure we can use the PCI host
generic
driver with MCFG and we leave the acpica PCI config call empty stubs on
arm64 (as they are now) ?



Hi Bjorn, Rafael,

Lorenzo pointed out very important problem we are having with PCI config
space access for ARM64. Please refer to the above discussion and add
your 2 cents. Can we forget about accessing PCI config space (for
Hardware Reduced profile) before PCI bus creation? If not, do you see a
way to use drivers/pci/access.c accessors here, like acpica change? Any
opinion is very appreciated.



Kindly remainder.


I think (but I am happy to be corrected) that the map_bus() hook
(ie that's why struct pci_bus is required in eg pci_generic_config_write)
is there to ensure that when the generic accessors are called
a) we have a valid bus b) the host controllers implementing it
has been initialized.

I had another look and I noticed you are trying to solve multiple
things at once:

1) ACPICA seems to need PCI config space on bus 0 to be working
before PCI enumerates (ie before we have a root bus), we need to
countercheck on that, but you can't use the generic PCI accessors
for that reasons (ie root bus might not be available, you do not
have a pci_bus struct)
2) the raw_pci_read/write require _generic_ mmio back-ends, since AMD
can't cope with standard x86 read/write{b,w,l}

Overall, it seems to me that we can avoid code duplication by
shuffling your code a bit.

You could modify the generic accessors in drivers/pci/access.c to
use your mmio back-end instead of using plain read/write{b,w,l}
functions (we should check if RobH is ok with that there can be
reasons that prevent this from happening). This would solve the
AMD mmio issue.

By 

Re: [PATCH 0/4] MIPS: ath79: Add USB support on the TL-WR1043ND

[Arnd Bergmann]

On Wednesday 09 September 2015 16:14:59 Alban wrote:
> On Mon, 07 Sep 2015 15:20:42 +0200
> Arnd Bergmann  wrote:
> 
> > On Tuesday 01 September 2015 17:23:10 Alban Bedel wrote:
> > > 
> > > this serie add a driver for the USB phy on the ATH79 SoCs and enable the
> > > USB port on the TL-WR1043ND. The phy controller is really trivial as it
> > > only use reset lines.
> > > 
> > 
> > Is this a common thing to have? If other PHY devices are like this, we
> > could instead add a simple generic PHY driver that just asserts all
> > its reset lines in the order as provided, rather than making this a
> > hardware specific driver that ends up getting copied several times.
> 
> I don't know how common it is. However I agree that a simple driver that
> can start a clock and toggle a few GPIO and/or reset would make sense.
> 
> However in the case of the ATH79 SoC some models have a reset line that
> is misused to force the PHY in sleep mode. Sadly this extra reset must
> be asserted for the PHY to work, so it wouldn't fit in such a generic
> design.
> 
> Still we could have such a generic driver and let the ATH79 driver
> build on top of it. Honestly that's what I wanted to do, but getting
> generic drivers with DT support accepted is not easy. That's why I went
> with this driver, it is technically inferior but much easier to get
> considered for merging.

Ok, fair enough. If we end up doing a more generic driver for this,
we can still consider adding the compatible string there, potentially
with some workaround for the sleep mode.

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

Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

[Alan Stern]

On Wed, 9 Sep 2015, Oliver Neukum wrote:

> On Tue, 2015-09-08 at 10:44 -0400, Alan Stern wrote:
> > It would not put the device into runtime suspend immediately, like you
> > are proposing.  Instead it would mean the same as the "auto" mode,
> > except that remote wakeup should be disabled during runtime suspend.
> 
> Hi,
> 
> this proposal is incomplete. If you don't want remote wakeup you
> imply that input is no longer needed or possible. If that is
> already known, we can just as well inform the driver, so that
> it can cease IO for input.

Like I said, it was never implemented.  For that reason, it was never 
completely fleshed out.

> Yet that is not necessarily the only scenario. For example
> if you run a screensaver, you might not care for where the
> user touches the screen, but the event as such is valuable.

I suspect it's not worth the effort to distinguish between getting an 
event with all the details and merely knowing that an event occurred.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Revert "task_work: remove fifo ordering guarantee"

[Oleg Nesterov]

sorry for delay,

On 09/08, Linus Torvalds wrote:
>
> On Tue, Sep 8, 2015 at 10:14 AM, Oleg Nesterov  wrote:
> >
> > Now that fput() can't abuse ->task_works list, we can restore the FIFO
> > ordering. Yes, currently there are no in-kernel users which need this,
> > but I think task_work_add() will have more users and FIFO makes more
> > sense if (unlike fput/mntput) the callbacks change the task's state.
>
> So quite frankly, regardless of the other patches, I'd almost rather
> see the workqueue not being ordered. I don't think anybody pointed at
> any code that could possibly care. And if nobody cares, why add the
> code and the CPU cycles to do this?

Currently nobody cares, yes. IIRC, even the out-of-tree code I know about,
although I didn't recheck.

Again, rightly or not I believe that FIFO makes task_work_add() more useful.
Perhaps I am wrong, so far I can only provide the artificial examples...

To me this does not differ from, say, stop_one_cpu_nowait(). I would be
surprised if it wasn't FIFO.

At least this should be cheap after 1/3. And in any case the time we spend
in the "reverse" loop is nothing compared to the next one which actually
runs the callbacks.

Thanks. Lets see what Al thinks...

Oleg.

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

Re: [PATCH v12 07/21] x86/xen: Add stack frame dependency to hypercall inline asm calls

[David Vrabel]

On 09/09/15 14:21, Josh Poimboeuf wrote:
> If a hypercall is inlined at the beginning of a function, gcc can insert
> the call instruction before setting up a stack frame, which breaks frame
> pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
> a bad stack trace.
> 
> Force a stack frame to be created if CONFIG_FRAME_POINTER is enabled by
> listing the stack pointer as an output operand for the hypercall inline
> asm statements.

Reviewed-by: David Vrabel 

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

[PATCH v12 17/21] x86/asm/entry: Create stack frames in thunk functions

[Josh Poimboeuf]

Thunk functions are callable non-leaf functions that don't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.  Also they
aren't annotated as ELF callable functions which can confuse tooling.

Create stack frames for them when CONFIG_FRAME_POINTER is enabled and
add the ELF function type.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/entry/thunk_64.S | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/entry/thunk_64.S b/arch/x86/entry/thunk_64.S
index efb2b93..98df1fa 100644
--- a/arch/x86/entry/thunk_64.S
+++ b/arch/x86/entry/thunk_64.S
@@ -8,11 +8,14 @@
 #include 
 #include "calling.h"
 #include 
+#include 
 
/* rdi: arg1 ... normal C conventions. rax is saved/restored. */
.macro THUNK name, func, put_ret_addr_in_rdi=0
.globl \name
+   .type \name, @function
 \name:
+   FRAME_BEGIN
 
/* this one pushes 9 elems, the next one would be %rIP */
pushq %rdi
@@ -62,6 +65,7 @@ restore:
popq %rdx
popq %rsi
popq %rdi
+   FRAME_END
ret
_ASM_NOKPROBE(restore)
 #endif
-- 
2.4.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 linux-next v6 8/8] mtd: atmel-quadspi: add driver for Atmel QSPI controller

[Cyrille Pitchen]

This driver add support to the new Atmel QSPI controller embedded into
sama5d2x SoCs. It expects a NOR memory to be connected to the QSPI
controller.

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/Kconfig |   7 +
 drivers/mtd/spi-nor/Makefile|   1 +
 drivers/mtd/spi-nor/atmel-quadspi.c | 889 
 3 files changed, 897 insertions(+)
 create mode 100644 drivers/mtd/spi-nor/atmel-quadspi.c

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 89bf4c1faa2b..7a3d55429550 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -29,6 +29,13 @@ config SPI_FSL_QUADSPI
  This controller does not support generic SPI. It only supports
  SPI NOR.
 
+config SPI_ATMEL_QUADSPI
+   tristate "Atmel Quad SPI Controller"
+   depends on OF && HAS_DMA && (ARCH_AT91 || COMPILE_TEST)
+   help
+ This enables support for the Quad SPI controller in master mode.
+ We only connect the NOR to this controller now.
+
 config SPI_NXP_SPIFI
tristate "NXP SPI Flash Interface (SPIFI)"
depends on OF && (ARCH_LPC18XX || COMPILE_TEST)
diff --git a/drivers/mtd/spi-nor/Makefile b/drivers/mtd/spi-nor/Makefile
index e5ef8582..f5d23d7379bb 100644
--- a/drivers/mtd/spi-nor/Makefile
+++ b/drivers/mtd/spi-nor/Makefile
@@ -1,3 +1,4 @@
 obj-$(CONFIG_MTD_SPI_NOR)  += spi-nor.o
 obj-$(CONFIG_SPI_FSL_QUADSPI)  += fsl-quadspi.o
+obj-$(CONFIG_SPI_ATMEL_QUADSPI)+= atmel-quadspi.o
 obj-$(CONFIG_SPI_NXP_SPIFI)+= nxp-spifi.o
diff --git a/drivers/mtd/spi-nor/atmel-quadspi.c 
b/drivers/mtd/spi-nor/atmel-quadspi.c
new file mode 100644
index ..dc0c1d8293d5
--- /dev/null
+++ b/drivers/mtd/spi-nor/atmel-quadspi.c
@@ -0,0 +1,889 @@
+/*
+ * Driver for Atmel QSPI Controller
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Author: Cyrille Pitchen 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ *
+ * This driver is based on drivers/mtd/spi-nor/fsl-quadspi.c from Freescale.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+
+/* QSPI register offsets */
+#define QSPI_CR  0x  /* Control Register */
+#define QSPI_MR  0x0004  /* Mode Register */
+#define QSPI_RD  0x0008  /* Receive Data Register */
+#define QSPI_TD  0x000c  /* Transmit Data Register */
+#define QSPI_SR  0x0010  /* Status Register */
+#define QSPI_IER 0x0014  /* Interrupt Enable Register */
+#define QSPI_IDR 0x0018  /* Interrupt Disable Register */
+#define QSPI_IMR 0x001c  /* Interrupt Mask Register */
+#define QSPI_SCR 0x0020  /* Serial Clock Register */
+
+#define QSPI_IAR 0x0030  /* Instruction Address Register */
+#define QSPI_ICR 0x0034  /* Instruction Code Register */
+#define QSPI_IFR 0x0038  /* Instruction Frame Register */
+
+#define QSPI_SMR 0x0040  /* Scrambling Mode Register */
+#define QSPI_SKR 0x0044  /* Scrambling Key Register */
+
+#define QSPI_WPMR0x00E4  /* Write Protection Mode Register */
+#define QSPI_WPSR0x00E8  /* Write Protection Status Register */
+
+#define QSPI_VERSION 0x00FC  /* Version Register */
+
+
+/* Bitfields in QSPI_CR (Control Register) */
+#define QSPI_CR_QSPIEN  BIT(0)
+#define QSPI_CR_QSPIDIS BIT(1)
+#define QSPI_CR_SWRST   BIT(7)
+#define QSPI_CR_LASTXFERBIT(24)
+
+/* Bitfields in QSPI_MR (Mode Register) */
+#define QSPI_MR_SSM BIT(0)
+#define QSPI_MR_LLB BIT(1)
+#define QSPI_MR_WDRBT   BIT(2)
+#define QSPI_MR_SMRMBIT(3)
+#define QSPI_MR_CSMODE_MASK GENMASK(5, 4)
+#define QSPI_MR_CSMODE_NOT_RELOADED (0 << 4)
+#define QSPI_MR_CSMODE_LASTXFER (1 << 4)
+#define QSPI_MR_CSMODE_SYSTEMATICALLY   (2 << 4)
+#define QSPI_MR_NBBITS_MASK GENMASK(11, 8)
+#define QSPI_MR_NBBITS(n)   n) - 8) << 8) & 
QSPI_MR_NBBITS_MASK)
+#define QSPI_MR_DLYBCT_MASK GENMASK(23, 16)
+#define QSPI_MR_DLYBCT(n)   (((n) << 16) & QSPI_MR_DLYBCT_MASK)
+#define QSPI_MR_DLYCS_MASK  GENMASK(31, 24)
+#define QSPI_MR_DLYCS(n)(((n) << 24) & QSPI_MR_DLYCS_MASK)
+

[PATCH linux-next v6 7/8] Documentation: atmel-quadspi: add binding file for Atmel QSPI driver

[Cyrille Pitchen]

This patch documents the DT bindings for the driver of the Atmel QSPI
controller embedded inside sama5d2x SoCs.

Signed-off-by: Cyrille Pitchen 
Acked-by: Nicolas Ferre 
Acked-by: Marek Vasut 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/mtd/atmel-quadspi.txt  | 29 ++
 1 file changed, 29 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mtd/atmel-quadspi.txt

diff --git a/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
new file mode 100644
index ..0b8d545bb198
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/atmel-quadspi.txt
@@ -0,0 +1,29 @@
+* Atmel Quad Serial Peripheral Interface (QSPI)
+
+Required properties:
+- compatible: should be "atmel,sama5d2-qspi"
+- reg:the first contains the register location and length,
+  the second contains the memory mapping address and length
+- interrupts: should contain the interrupt for the device
+- clocks: the phandle of the clock needed by the QSPI controller
+- #address-cells: should be <1>
+- #size-cells:should be <0>
+
+Example:
+
+spi@f002 {
+   compatible = "atmel,sama5d2-qspi";
+   reg = <0xf002 0x100>,
+ <0xd000 0x800>;
+   interrupts = <52 IRQ_TYPE_LEVEL_HIGH 7>;
+   clocks = <_clk>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_spi0_default>;
+   status = "okay";
+
+   m25p80@0 {
+   ...
+   };
+};
-- 
1.8.2.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 v12 19/21] x86/asm: Create stack frames in rwsem functions

[Josh Poimboeuf]

rwsem.S has several callable non-leaf functions which don't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.

Create stack frames for them when CONFIG_FRAME_POINTER is enabled.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/lib/rwsem.S | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S
index 40027db..be110ef 100644
--- a/arch/x86/lib/rwsem.S
+++ b/arch/x86/lib/rwsem.S
@@ -15,6 +15,7 @@
 
 #include 
 #include 
+#include 
 
 #define __ASM_HALF_REG(reg)__ASM_SEL(reg, e##reg)
 #define __ASM_HALF_SIZE(inst)  __ASM_SEL(inst##w, inst##l)
@@ -84,24 +85,29 @@
 
 /* Fix up special calling conventions */
 ENTRY(call_rwsem_down_read_failed)
+   FRAME_BEGIN
save_common_regs
__ASM_SIZE(push,) %__ASM_REG(dx)
movq %rax,%rdi
call rwsem_down_read_failed
__ASM_SIZE(pop,) %__ASM_REG(dx)
restore_common_regs
+   FRAME_END
ret
 ENDPROC(call_rwsem_down_read_failed)
 
 ENTRY(call_rwsem_down_write_failed)
+   FRAME_BEGIN
save_common_regs
movq %rax,%rdi
call rwsem_down_write_failed
restore_common_regs
+   FRAME_END
ret
 ENDPROC(call_rwsem_down_write_failed)
 
 ENTRY(call_rwsem_wake)
+   FRAME_BEGIN
/* do nothing if still outstanding active readers */
__ASM_HALF_SIZE(dec) %__ASM_HALF_REG(dx)
jnz 1f
@@ -109,15 +115,18 @@ ENTRY(call_rwsem_wake)
movq %rax,%rdi
call rwsem_wake
restore_common_regs
-1: ret
+1: FRAME_END
+   ret
 ENDPROC(call_rwsem_wake)
 
 ENTRY(call_rwsem_downgrade_wake)
+   FRAME_BEGIN
save_common_regs
__ASM_SIZE(push,) %__ASM_REG(dx)
movq %rax,%rdi
call rwsem_downgrade_wake
__ASM_SIZE(pop,) %__ASM_REG(dx)
restore_common_regs
+   FRAME_END
ret
 ENDPROC(call_rwsem_downgrade_wake)
-- 
2.4.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 v12 21/21] x86/asm/power: Create stack frames in hibernate_asm_64.S

[Josh Poimboeuf]

swsusp_arch_suspend() and restore_registers() are callable non-leaf
functions which don't honor CONFIG_FRAME_POINTER, which can result in
bad stack traces.  Also they aren't annotated as ELF callable functions
which can confuse tooling.

Create a stack frame for them when CONFIG_FRAME_POINTER is enabled and
give them proper ELF function annotations.

Signed-off-by: Josh Poimboeuf 
Acked-by: Pavel Machek 
Cc: "Rafael J. Wysocki" 
---
 arch/x86/power/hibernate_asm_64.S | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/x86/power/hibernate_asm_64.S 
b/arch/x86/power/hibernate_asm_64.S
index e2386cb..4400a43 100644
--- a/arch/x86/power/hibernate_asm_64.S
+++ b/arch/x86/power/hibernate_asm_64.S
@@ -21,8 +21,10 @@
 #include 
 #include 
 #include 
+#include 
 
 ENTRY(swsusp_arch_suspend)
+   FRAME_BEGIN
movq$saved_context, %rax
movq%rsp, pt_regs_sp(%rax)
movq%rbp, pt_regs_bp(%rax)
@@ -50,7 +52,9 @@ ENTRY(swsusp_arch_suspend)
movq%rax, restore_cr3(%rip)
 
call swsusp_save
+   FRAME_END
ret
+ENDPROC(swsusp_arch_suspend)
 
 ENTRY(restore_image)
/* switch to temporary page tables */
@@ -107,6 +111,7 @@ ENTRY(core_restore_code)
 */
 
 ENTRY(restore_registers)
+   FRAME_BEGIN
/* go back to the original page tables */
movq%rbx, %cr3
 
@@ -147,4 +152,6 @@ ENTRY(restore_registers)
/* tell the hibernation core that we've just restored the memory */
movq%rax, in_suspend(%rip)
 
+   FRAME_END
ret
+ENDPROC(restore_registers)
-- 
2.4.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 1/3] sysfs: Fix is_visible() support for binary attributes

[Guenter Roeck]

On 09/09/2015 06:14 AM, Emilio López wrote:

On 09/09/15 01:12, Guenter Roeck wrote:

On 09/08/2015 08:58 PM, Greg KH wrote:

On Tue, Sep 08, 2015 at 06:10:16PM -0700, Guenter Roeck wrote:

Hi Emilio,

On 09/08/2015 05:51 PM, Emilio López wrote:

Hi Greg & Guenter,


[ ... ]


Unless I am missing something, this is not explained anywhere,
but it is
not entirely trivial to understand. I think it should be documented.


I agree. I couldn't find any mention of what this int was supposed
to be by looking at Documentation/ (is_visible is not even mentioned
:/) or include/linux/sysfs.h. Once we settle on something I'll
document it before sending a v2.


In the include file ? No strong preference, though.


By the way, I wrote a quick coccinelle script to match is_visible()
users which reference the index (included below), and it found
references to drivers which do not seem to use any binary
attributes, so I believe changing the index meaning shouldn't be an
issue.


Good.


I agree, make i the number of the bin attribute and that should solve
this issue.


No, that would conflict with the "normal" use of is_visible for
non-binary
attributes, and make the index all but useless, since the
is_visible function
would have to search through all the attributes anyway to figure
out which one
is being checked.


Yeah, using the same indexes would be somewhat pointless, although
not many seem to be using it anyway (only 14 files matched). Others
seem to be comparing the attr* instead. An alternative would be to
use negative indexes for binary attributes and positive indexes for
normal attributes.


... and I probably wrote or reviewed a significant percentage of
those ;-).

Using negative numbers for binary attributes is an interesting idea.
Kind of unusual, though. Greg, any thoughts on that ?


Ick, no, that's a mess, maybe we just could drop the index alltogether?



No, please don't. Having to manually compare dozens of index pointers
would be
even more of a mess.


So, what about keeping it the way it is in the patch, and documenting it thoroughly? 
Otherwise, we could introduce another "is_bin_visible" function to do this same 
thing but just on binary attributes, but I'd rather not add a new function pointer if 
possible.



I would prefer to keep and document it.

Guenter

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

Re: [PATCH] sched: make policy-testing consistent in core

[Peter Zijlstra]

On Wed, Sep 09, 2015 at 11:32:43AM +0200, Henrik Austad wrote:
> As per-irc request
> 
> *prod*

I see no objection to his; but it appears I never actually received the
original patch. Do you mind resending so I can apply?


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] pwm: atmel-hlcdc: add sama5d2 SoC support.

[Nicolas Ferre]

Add sama5d2 hlcdc backlight PWM support. This chip doesn't have to deal with an
errata, so it's a simple addition of the mfd compatible string.

Signed-off-by: Nicolas Ferre 
---
 drivers/pwm/pwm-atmel-hlcdc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/pwm/pwm-atmel-hlcdc.c b/drivers/pwm/pwm-atmel-hlcdc.c
index fa5feaba25a5..6974a0ef986e 100644
--- a/drivers/pwm/pwm-atmel-hlcdc.c
+++ b/drivers/pwm/pwm-atmel-hlcdc.c
@@ -222,6 +222,9 @@ static const struct of_device_id atmel_hlcdc_dt_ids[] = {
.data = _hlcdc_pwm_at91sam9x5_errata,
},
{
+   .compatible = "atmel,sama5d2-hlcdc",
+   },
+   {
.compatible = "atmel,sama5d3-hlcdc",
.data = _hlcdc_pwm_sama5d3_errata,
},
-- 
2.1.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 v2 1/1] ARM: dts: sun7i: Enable axp209 driver on olinuxino lime2

[Olliver Schinagl]

The Olimex OLinuXino Lime2 uses the same AXP209 as was recently
introduced this driver for its power regulation.

Signed-off-by: Olliver Schinagl 
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 87 +
 1 file changed, 31 insertions(+), 56 deletions(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..dd90a1d 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -71,14 +71,6 @@
default-state = "on";
};
};
-
-   reg_axp_ipsout: axp_ipsout {
-   compatible = "regulator-fixed";
-   regulator-name = "axp-ipsout";
-   regulator-min-microvolt = <500>;
-   regulator-max-microvolt = <500>;
-   regulator-always-on;
-   };
 };
 
  {
@@ -86,6 +78,10 @@
status = "okay";
 };
 
+ {
+   cpu-supply = <_dcdc2>;
+};
+
  {
status = "okay";
 };
@@ -112,57 +108,9 @@
status = "okay";
 
axp209: pmic@34 {
-   compatible = "x-powers,axp209";
reg = <0x34>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-
-   interrupt-controller;
-   #interrupt-cells = <1>;
-
-   acin-supply = <_axp_ipsout>;
-   vin2-supply = <_axp_ipsout>;
-   vin3-supply = <_axp_ipsout>;
-   ldo24in-supply = <_axp_ipsout>;
-   ldo3in-supply = <_axp_ipsout>;
-
-   regulators {
-   vdd_rtc: ldo1 {
-   regulator-min-microvolt = <130>;
-   regulator-max-microvolt = <130>;
-   regulator-always-on;
-   };
-
-   avcc: ldo2 {
-   regulator-min-microvolt = <180>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
-
-   vcc_csi0: ldo3 {
-   regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <350>;
-   regulator-always-on;
-   };
-
-   vcc_csi1: ldo4 {
-   regulator-min-microvolt = <125>;
-   regulator-max-microvolt = <330>;
-   regulator-always-on;
-   };
-
-   vdd_cpu: dcdc2 {
-   regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <2275000>;
-   regulator-always-on;
-   };
-
-   vdd_int: dcdc3 {
-   regulator-min-microvolt = <70>;
-   regulator-max-microvolt = <350>;
-   regulator-always-on;
-   };
-   };
};
 };
 
@@ -243,6 +191,33 @@
status = "okay";
 };
 
+#include "axp209.dtsi"
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <145>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <100>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-int-dll";
+};
+
+_ldo1 {
+   regulator-name = "vdd-rtc";
+};
+
+_ldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "avcc";
+};
+
 _usb0_vbus {
pinctrl-0 = <_vbus_pin_lime2>;
gpio = < 2 17 GPIO_ACTIVE_HIGH>;
-- 
2.1.4

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

[PATCH v12 20/21] x86/asm/efi: Create a stack frame in efi_call()

[Josh Poimboeuf]

efi_call() is a callable non-leaf function which doesn't honor
CONFIG_FRAME_POINTER, which can result in bad stack traces.

Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.

Signed-off-by: Josh Poimboeuf 
Reviewed-by: Matt Fleming 
---
 arch/x86/platform/efi/efi_stub_64.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/platform/efi/efi_stub_64.S 
b/arch/x86/platform/efi/efi_stub_64.S
index 86d0f9e..0df2dcc 100644
--- a/arch/x86/platform/efi/efi_stub_64.S
+++ b/arch/x86/platform/efi/efi_stub_64.S
@@ -11,6 +11,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define SAVE_XMM   \
mov %rsp, %rax; \
@@ -74,6 +75,7 @@
.endm
 
 ENTRY(efi_call)
+   FRAME_BEGIN
SAVE_XMM
mov (%rsp), %rax
mov 8(%rax), %rax
@@ -88,6 +90,7 @@ ENTRY(efi_call)
RESTORE_PGT
addq $48, %rsp
RESTORE_XMM
+   FRAME_END
ret
 ENDPROC(efi_call)
 
-- 
2.4.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 v2 2/3] efi: Change abbreviation of EFI_MEMORY_RUNTIME from "RUN" to "RT"

[Ard Biesheuvel]

On 9 September 2015 at 15:27, Matt Fleming  wrote:
> On Thu, 27 Aug, at 02:11:29AM, Taku Izumi wrote:
>> Now efi_md_typeattr_format() outputs "RUN" if passed EFI memory
>> descriptor has EFI_MEMORY_RUNTIME attribute. But "RT" is preferer
>> because it is shorter and clearer.
>>
>> This patch changes abbreviation of EFI_MEMORY_RUNTIME from "RUN"
>> to "RT".
>>
>> Suggested-by: Ard Biesheuvel 
>> Signed-off-by: Taku Izumi 
>> ---
>>  drivers/firmware/efi/efi.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
>> index 8124078..25b6477 100644
>> --- a/drivers/firmware/efi/efi.c
>> +++ b/drivers/firmware/efi/efi.c
>> @@ -594,8 +594,8 @@ char * __init efi_md_typeattr_format(char *buf, size_t 
>> size,
>>   snprintf(pos, size, "|attr=0x%016llx]",
>>(unsigned long long)attr);
>>   else
>> - snprintf(pos, size, 
>> "|%3s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
>> -  attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
>> + snprintf(pos, size, 
>> "|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
>> +  attr & EFI_MEMORY_RUNTIME ? "RT" : "",
>>attr & EFI_MEMORY_MORE_RELIABLE ? "MR" : "",
>>attr & EFI_MEMORY_XP  ? "XP"  : "",
>>attr & EFI_MEMORY_RP  ? "RP"  : "",
>
> I know that Ard suggested this change but I don't think I should apply
> this and the reason is that developers, particularly distro
> developers, come to rely on the output we print for debugging
> purposes.
>
> They don't necessarily monitor all the patches getting merged upstream
> closely enough to realise that it impacts their debugging strategy. So
> when they notice that the output has gone from "RUN" to "RT" they're
> naturally going to ask what the difference is... and the answer is "it
> looks prettier". That's not a good enough reason.
>
> Obviously if we're printing something that's completely incorrect, or
> we can improve the message considerably, then yes, it makes sense to
> change it - but that's not the case here.
>
> Thanks for the patch, but sorry, I'm not going to apply this one.
>

Ack. It was more an illustration of my argument for preferring MR over
REL[IY] than anything else,.

-- 
ard.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 3/3] x86, efi: Add "efi_fake_mem_mirror" boot option

[Matt Fleming]

On Thu, 27 Aug, at 02:11:37AM, Taku Izumi wrote:
> This patch introduces new boot option named "efi_fake_mem_mirror".
> By specifying this parameter, you can mark specific memory as
> mirrored memory. This is useful for debugging of Address Range
> Mirroring feature.
> 
> For example, if you specify "efi_fake_mem_mirror=2G@4G,2G@0x10a000",
> the original (firmware provided) EFI memmap will be updated so that
> the specified memory regions have EFI_MEMORY_MORE_RELIABLE attribute:
> 
>  
>efi: mem00: [Boot Data  |  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x-0x1000) (0MB)
>efi: mem01: [Loader Data|  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x1000-0x2000) (0MB)
>...
>efi: mem35: [Boot Data  |  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x47ee6000-0x48014000) (1MB)
>efi: mem36: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x0001-0x0020a000) (129536MB)
>efi: mem37: [Reserved   |RT|  |  |  |  |   |  |  |  |UC] 
> range=[0x6000-0x9000) (768MB)
> 
>  
>efi: mem00: [Boot Data  |  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x-0x1000) (0MB)
>efi: mem01: [Loader Data|  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x1000-0x2000) (0MB)
>...
>efi: mem35: [Boot Data  |  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x47ee6000-0x48014000) (1MB)
>efi: mem36: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] 
> range=[0x0001-0x00018000) (2048MB)
>efi: mem37: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x00018000-0x0010a000) (61952MB)
>efi: mem38: [Conventional Memory|  |MR|  |  |  |   |WB|WT|WC|UC] 
> range=[0x0010a000-0x00112000) (2048MB)
>efi: mem39: [Conventional Memory|  |  |  |  |  |   |WB|WT|WC|UC] 
> range=[0x00112000-0x0020a000) (63488MB)
>efi: mem40: [Reserved   |RT|  |  |  |  |   |  |  |  |UC] 
> range=[0x6000-0x9000) (768MB)
> 
> And you will find that the following message is output:
> 
>efi: Memory: 4096M/131455M mirrored memory
> 
> Signed-off-by: Taku Izumi 
> ---
>  Documentation/kernel-parameters.txt |   8 ++
>  arch/x86/include/asm/efi.h  |   1 +
>  arch/x86/kernel/setup.c |   4 +-
>  arch/x86/platform/efi/efi.c |   2 +-
>  drivers/firmware/efi/Kconfig|  12 +++
>  drivers/firmware/efi/Makefile   |   1 +
>  drivers/firmware/efi/fake_mem.c | 204 
> 
>  include/linux/efi.h |   6 ++
>  8 files changed, 236 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/firmware/efi/fake_mem.c

[...]

> diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
> index e4308fe..eee8068 100644
> --- a/arch/x86/platform/efi/efi.c
> +++ b/arch/x86/platform/efi/efi.c
> @@ -222,7 +222,7 @@ int __init efi_memblock_x86_reserve_range(void)
>   return 0;
>  }
>  
> -static void __init print_efi_memmap(void)
> +void __init print_efi_memmap(void)
>  {
>  #ifdef EFI_DEBUG
>   efi_memory_desc_t *md;

If we're going to make this function global we should stick to the
existing naming convention and rename it efi_print_memmap() in a
separate patch.

> diff --git a/drivers/firmware/efi/fake_mem.c b/drivers/firmware/efi/fake_mem.c
> new file mode 100644
> index 000..2645d4a
> --- /dev/null
> +++ b/drivers/firmware/efi/fake_mem.c
> @@ -0,0 +1,204 @@
> +/*
> + * fake_mem.c
> + *
> + * Copyright (C) 2015 FUJITSU LIMITED
> + * Author: Taku Izumi 
> + *
> + * This code introduces new boot option named "efi_fake_mem_mirror"
> + * By specifying this parameter, you can mark specific memory as
> + * mirrored memory by updating original (firmware provided) EFI
> + * memmap.
> + *
> + *  This program is free software; you can redistribute it and/or modify it
> + *  under the terms and conditions of the GNU General Public License,
> + *  version 2, as published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope it will be useful, but WITHOUT
> + *  ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + *  FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
> + *  more details.
> + *
> + *  You should have received a copy of the GNU General Public License along 
> with
> + *  this program; if not, see .
> + *
> + *  The full GNU General Public License is included in this distribution in
> + *  the file called "COPYING".
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define EFI_MAX_FAKE_MIRROR 8
> +static struct range fake_mirrors[EFI_MAX_FAKE_MIRROR];

Should we make this a Kconfig option? Is there any 

Re: [RFC PATCH] PM / Runtime: runtime: Add sysfs option for forcing runtime suspend

[Oliver Neukum]

On Wed, 2015-09-09 at 14:22 +0200, Rafael J. Wysocki wrote:
> > Note that when the screen is turned-on again, we want to resume the
> > touchscreen so that it can send events again.

Why is it impractical to close the fd for the touchscreen?
> 
> In fact, then, what you need seems to be the feature discussed by Alan
> and me some time ago allowing remote wakeup do be disabled for runtime
> PM from user space as that in combination with autosuspend should
> address your use case.

I'd doubt that. Suppose you put the phone into your pocket while
the device isn't suspended. The continuous stream of spurious events
will keep it awake.
The ability to disable remote wakeup is necessary but not sufficient.

Regards
Oliver


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: very slow disk write speed: WARNING: CPU: 4 PID: 12891 at fs/inode.c:390 ihold+0x30/0x40()

[Dexuan Cui]

With the recent linux-next tree (e.g., next-20150909), I can easily get the 
below callstack (see the end of the mail) when I run some heavy I/O workloads, 
like building a kernel with "make -j16".

After the callstack happens, "dd if=/dev/zero of=zero.bin  bs=1M" shows the 
disk write speed goes down to a value far less than 1MB/s (I get the speed by 
iostat or iotop), while the normal write speed should be 100MB/s. However, at 
this time, "cat a_big_file > /dev/null" shows the disk read speed is still 
normal, e.g., >100MB/s.

Though I found the issue in Hyper-V VM, I don't think it's caused by a change 
in the Linux Hyper-V drivers, because I don't see any change in the Linux 
Hyper-V drivers can cause this issue.

NOTE: only the linux-next tree (maybe since some Aug version or even July 
version?) has the issue.
The latest Linus's tree and Greg's char-misc.git tree don't have the issue.
With respect to the Linux Hyper-V drivers, I'm sure there is no real difference 
between linux-next and Greg's char-misc.git.

Any idea?

Thanks!
-- Dexuan

The callstack is:
[ 1799.156370] ld (36538) used greatest stack depth: 12344 bytes left
[ 1860.388015] [ cut here ]
[ 1860.388015] WARNING: CPU: 4 PID: 12891 at fs/inode.c:390 ihold+0x30/0x40()
[ 1860.388015] Modules linked in: xt_tcpudp iptable_filter ip_tables x_tables 
i2c_piix4 i2c_core serio_raw evdev hid_generic hid_hyperv hid hyperv_keyboard 
autofs4 hv_netvsc hv_utils hv_storvsc psmouse hyperv_fb atkbd hv_vmbus
[ 1860.389888] CPU: 4 PID: 12891 Comm: kworker/u130:3 Not tainted 
4.2.0-next-20150909 #1
[ 1860.389888] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090006  05/23/2012
[ 1860.389888] Workqueue: writeback wb_workfn (flush-8:16)
[ 1860.389888]  8c808fa0 880368253a60 8c30d002 

[ 1860.389888]  880368253a98 8c056396 880291eb0870 
880291eb08f0
[ 1860.389888]  88044e142120 0001 0641 
880368253aa8
[ 1860.389888] Call Trace:
[ 1860.389888]  [] dump_stack+0x44/0x62
[ 1860.389888]  [] warn_slowpath_common+0x86/0xc0
[ 1860.389888]  [] warn_slowpath_null+0x1a/0x20
[ 1860.389888]  [] ihold+0x30/0x40
[ 1860.389888]  [] inode_switch_wbs+0x1b6/0x270
[ 1860.389888]  [] ? inode_switch_wbs+0x72/0x270
[ 1860.389888]  [] wbc_detach_inode+0x1a1/0x1d0
[ 1860.389888]  [] writeback_sb_inodes+0x27e/0x480
[ 1860.389888]  [] __writeback_inodes_wb+0x89/0xc0
[ 1860.389888]  [] wb_writeback+0x207/0x280
[ 1860.389888]  [] wb_workfn+0x299/0x3d0
[ 1860.389888]  [] process_one_work+0x1b8/0x4b0
[ 1860.389888]  [] ? process_one_work+0x14f/0x4b0
[ 1860.389888]  [] worker_thread+0x4b/0x440
[ 1860.389888]  [] ? rescuer_thread+0x2d0/0x2d0
[ 1860.389888]  [] ? rescuer_thread+0x2d0/0x2d0
[ 1860.389888]  [] kthread+0xf3/0x110
[ 1860.389888]  [] ? kthread_create_on_node+0x230/0x230
[ 1860.389888]  [] ret_from_fork+0x3f/0x70
[ 1860.389888]  [] ? kthread_create_on_node+0x230/0x230
[ 1860.389888] ---[ end trace b4922878dcd2b65d ]---
[ 1865.692016] kworker/dying (163) used greatest stack depth: 11976 bytes left
[ 1943.756018] [ cut here ]
[ 1943.756018] WARNING: CPU: 3 PID: 339 at fs/inode.c:390 ihold+0x30/0x40()
[ 1943.756018] Modules linked in: xt_tcpudp iptable_filter ip_tables x_tables 
i2c_piix4 i2c_core serio_raw evdev hid_generic hid_hyperv hid hyperv_keyboard 
autofs4 hv_netvsc hv_utils hv_storvsc psmouse hyperv_fb atkbd hv_vmbus
[ 1943.756018] CPU: 3 PID: 339 Comm: kworker/u129:1 Tainted: GW   
4.2.0-next-20150909 #1
[ 1943.764006] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090006  05/23/2012
[ 1943.764006] Workqueue: writeback wb_workfn (flush-8:16)
[ 1943.764006]  8c808fa0 8802967f7a60 8c30d002 

[ 1943.764006]  8802967f7a98 8c056396 880295417170 
8802954171f0
[ 1943.764006]  880294864000 0001 0757 
8802967f7aa8
[ 1943.764006] Call Trace:
[ 1943.764006]  [] dump_stack+0x44/0x62
[ 1943.764006]  [] warn_slowpath_common+0x86/0xc0
[ 1943.764006]  [] warn_slowpath_null+0x1a/0x20
[ 1943.764006]  [] ihold+0x30/0x40
[ 1943.764006]  [] inode_switch_wbs+0x1b6/0x270
[ 1943.764006]  [] ? inode_switch_wbs+0x72/0x270
[ 1943.764793]  [] wbc_detach_inode+0x1a1/0x1d0
[ 1943.764793]  [] writeback_sb_inodes+0x27e/0x480
[ 1943.768142]  [] __writeback_inodes_wb+0x89/0xc0
[ 1943.768142]  [] wb_writeback+0x207/0x280
[ 1943.772350]  [] wb_workfn+0x299/0x3d0
[ 1943.772656]  [] process_one_work+0x1b8/0x4b0
[ 1943.780012]  [] ? process_one_work+0x14f/0x4b0
[ 1943.780012]  [] worker_thread+0x4b/0x440
[ 1943.780012]  [] ? rescuer_thread+0x2d0/0x2d0
[ 1943.780614]  [] ? rescuer_thread+0x2d0/0x2d0
[ 1943.780614]  [] kthread+0xf3/0x110
[ 1943.784614]  [] ? kthread_create_on_node+0x230/0x230
[ 1943.784614]  [] ret_from_fork+0x3f/0x70
[ 1943.784614]  [] ? kthread_create_on_node+0x230

RE: [PATCH v2 0/4] iio: bmc150 regmap and SPI

[Tirdea, Irina]

> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 20 August, 2015 15:50
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen; 
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v2 0/4] iio: bmc150 regmap and SPI
> 
> Hi,
> 

Hi Markus,

I tested your patches with my BMA250E driver connected on the i2c bus .
The code looks good and most of it works. There are a couple of issues I will 
mention
below and in the individual patches.

The patches in this version no longer apply cleanly on the togreg branch of the 
iio tree.
I did the rebase myself, but since there were many conflicts I will do another 
test
when you send the new rebased v3.

> this series converts the bmc150 driver to use regmap and adds an SPI 
> interface.
> 
> In v1 this was part of the series "Regmap max_raw_io and bmc150 SPI support".
> It now depends on "regmap: i2c block support".
> 

I used the patches that were already merged in the regmap tree. This bmc150 
series should
probably wait until the regmap patches end up in Jonathan's tree, otherwise 
they will
break the build.

Thanks,
Irina

> Changes in v2:
> - Removed default values for regmap_config fields.
> - Redesigned the fifo_transfer function to avoid running in errors first.
> - Dropped irq checks patch as it is already mainline
> - Core can now be built as module with autoselection of i2c and spi parts
> 
> As my hardware is missing an interrupt line from the SPI connected bmc150 I am
> not able to test the iio buffer code path and the i2c code path. Tests would 
> be
> appreciated.
> 
> Best regards,
> 
> Markus
> 
> 
> Markus Pargmann (4):
>   iio: bmc150: Use i2c regmap
>   iio: bcm150: Remove i2c_client from private data
>   iio: bmc150: Split the driver into core and i2c
>   iio: bmc150: Add SPI driver
> 
>  drivers/iio/accel/Kconfig  |  14 +-
>  drivers/iio/accel/Makefile |   4 +-
>  .../accel/{bmc150-accel.c => bmc150-accel-core.c}  | 398 
> -
>  drivers/iio/accel/bmc150-accel-i2c.c   |  99 +
>  drivers/iio/accel/bmc150-accel-spi.c   |  83 +
>  drivers/iio/accel/bmc150-accel.h   |  21 ++
>  6 files changed, 367 insertions(+), 252 deletions(-)
>  rename drivers/iio/accel/{bmc150-accel.c => bmc150-accel-core.c} (81%)
>  create mode 100644 drivers/iio/accel/bmc150-accel-i2c.c
>  create mode 100644 drivers/iio/accel/bmc150-accel-spi.c
>  create mode 100644 drivers/iio/accel/bmc150-accel.h
> 
> --
> 2.4.6

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mmc: block: Add new ioctl to send combo commands

[Ulf Hansson]

On 3 September 2015 at 17:08, Jon Hunter  wrote:
> Hi Olof,
>
> On 02/09/15 19:28, Olof Johansson wrote:
>> Hi,
>>
>> On Wed, Sep 2, 2015 at 7:21 AM, Jon Hunter  wrote:
>>> From: Seshagiri Holi 
>>>
>>> Certain eMMC devices allow vendor specific device information to be read
>>> via a sequence of vendor commands. These vendor commands must be issued
>>> in sequence and an atomic fashion. One way to support this would be to
>>> add an ioctl function for sending a sequence of commands to the device
>>> atomically as proposed here. These combo commands are simple array of
>>> the existing mmc_ioc_cmd structure.
>>
>> This seems reasonable to me, being able to do a sequence of
>> back-to-back operations without system read/writes slipping through.

I agree, this change seems reasonable!

Perhaps, from clarification point of view, we should change from
naming it "combo" commands to *sequence* of commands. Both in the code
and in the change log, please.

>>
>>> diff --git a/include/uapi/linux/mmc/ioctl.h b/include/uapi/linux/mmc/ioctl.h
>>> index 1f5e68923929..5943e51f22b3 100644
>>> --- a/include/uapi/linux/mmc/ioctl.h
>>> +++ b/include/uapi/linux/mmc/ioctl.h
>>> @@ -45,8 +45,23 @@ struct mmc_ioc_cmd {
>>>  };
>>>  #define mmc_ioc_cmd_set_data(ic, ptr) ic.data_ptr = (__u64)(unsigned long) 
>>> ptr
>>>
>>> -#define MMC_IOC_CMD _IOWR(MMC_BLOCK_MAJOR, 0, struct mmc_ioc_cmd)
>>> +/**
>>> + * struct mmc_ioc_combo_cmd - combo command information
>>> + * @num_of_cmds: number of commands to send
>>> + * @mmc_ioc_cmd_list: pointer to list of commands
>>> + */
>>> +struct mmc_ioc_combo_cmd {
>>> +   uint8_t num_of_cmds;
>>> +   struct mmc_ioc_cmd *mmc_ioc_cmd_list;
>>> +};
>>
>> The size of this struct will depend on the pointer size of userspace.
>>
>> It might be better to use a u64 for the pointer instead. Otherwise
>> you'd need a compat ioctl wrapper to copy a 32-bit pointer over on a
>> 64-bit kernel.
>
> Oh, good point. I have made this change today. I have also tested
> this now with a hacked version of mmc-utils to send a couple status
> commands back-to-back. I have tested on -next with ARM32 and on
> ARM64 with an older 3.18 kernel (due to lack of mmc support in the
> mainline for my ARM64 board) and seems to be working fine. Here is
> an updated version ...
>
> Jon
>
> From fe5849a0d91ebbcfd092c74696f3fa7d7de3a156 Mon Sep 17 00:00:00 2001
> From: Seshagiri Holi 
> Date: Mon, 4 Nov 2013 17:27:43 +0530
> Subject: [PATCH] mmc: block: Add new ioctl to send combo commands
>
> Certain eMMC devices allow vendor specific device information to be read
> via a sequence of vendor commands. These vendor commands must be issued
> in sequence and an atomic fashion. One way to support this would be to
> add an ioctl function for sending a sequence of commands to the device
> atomically as proposed here. These combo commands are simple array of
> the existing mmc_ioc_cmd structure.
>
> Signed-off-by: Seshagiri Holi 
> [ jonath...@nvidia.com: Rebased on linux-next from v3.18. Changed
>   userspace pointer type for combo command to be a u64. Updated
>   commit message ]
> Signed-off-by: Jon Hunter 
> ---
>  drivers/mmc/card/block.c   | 199 
> -
>  include/uapi/linux/mmc/ioctl.h |  17 +++-
>  2 files changed, 171 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
> index c742cfd7674e..0423d95ea020 100644
> --- a/drivers/mmc/card/block.c
> +++ b/drivers/mmc/card/block.c
> @@ -387,6 +387,22 @@ out:
> return ERR_PTR(err);
>  }
>
> +static int mmc_blk_ioctl_copy_to_user(struct mmc_ioc_cmd __user *ic_ptr,
> + struct mmc_blk_ioc_data *idata)
> +{
> +   if (copy_to_user(&(ic_ptr->response), idata->ic.response,
> +sizeof(idata->ic.response)))
> +   return -EFAULT;
> +
> +   if (!idata->ic.write_flag) {
> +   if (copy_to_user((void __user *)(unsigned 
> long)idata->ic.data_ptr,
> +idata->buf, idata->buf_bytes))
> +   return -EFAULT;
> +   }
> +
> +   return 0;
> +}
> +
>  static int ioctl_rpmb_card_status_poll(struct mmc_card *card, u32 *status,
>u32 retries_max)
>  {
> @@ -447,12 +463,9 @@ out:
> return err;
>  }
>
> -static int mmc_blk_ioctl_cmd(struct block_device *bdev,
> -   struct mmc_ioc_cmd __user *ic_ptr)
> +static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data 
> *md,
> +  struct mmc_blk_ioc_data *idata)
>  {
> -   struct mmc_blk_ioc_data *idata;
> -   struct mmc_blk_data *md;
> -   struct mmc_card *card;
> struct mmc_command cmd = {0};
> struct mmc_data data = {0};
> struct mmc_request mrq = {NULL};
> @@ -461,33 

Re: [llvmlinux] percpu | bitmap issue? (Cannot boot on bare metal due to a kernel NULL pointer dereference)

[Peter Zijlstra]

On Wed, Sep 09, 2015 at 12:05:50PM +0200, Sedat Dilek wrote:
> I can boot into a CLANG v3.7 compiled Linux-kernel when lib/bitmap is
> compiled with GCC (here: v4.9).
> 
> CONFIG_OPTIMIZE_INLINING has no effect on this.
> 
> Attached are the single llvmlinux patch for AMD64 (x86_64), my
> kernel-config and 2 objdumps with bitmap.o file alltogether.

I suggest you go tell the LLVM people their compiler is broken.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3] mtd: mtk-nor: mtk serial flash controller driver

[Lothar Waßmann]

Hi,

> > +   writeb(len, mt8173_nor->base + MTK_NOR_CNT_REG);
> > +   return mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_PRG_CMD);
> > +}
> > +
> > +static int mt8173_nor_get_para(struct mt8173_nor *mt8173_nor, u8 *buf, int 
> > len)
> > +{
> > +   if (len > 1) {
> > +   /* read JEDEC ID need 4 bytes commands */
> > +   mt8173_nor_set_cmd(mt8173_nor, 0, 32, SPINOR_OP_RDID);
> > +   buf[2] = readb(mt8173_nor->base + MTK_NOR_SHREG0_REG);
> > +   buf[1] = readb(mt8173_nor->base + MTK_NOR_SHREG1_REG);
> > +   buf[0] = readb(mt8173_nor->base + MTK_NOR_SHREG2_REG);
> > +   } else {
> > +   if (mt8173_nor_execute_cmd(mt8173_nor, MTK_NOR_RDSR_CMD)) {
> > +   dev_err(mt8173_nor->dev, "read status failed!\n");
> > +   return -EINVAL;
> > +   }
> > +   *buf = readb(mt8173_nor->base + MTK_NOR_RDSR_REG);
> > +   }
> > +   return 0;
> > +}
> > +
> > +/* cmd1 sent to nor flash, cmd2 write to nor controller */
> > +static int mt8173_nor_set_para(struct mt8173_nor *mt8173_nor, int cmd1,
> > +  int cmd2)
> > +{
> > +   if (mt8173_nor_set_cmd(mt8173_nor, 0, 8, SPINOR_OP_WREN)) {
> > +   dev_err(mt8173_nor->dev,
> > +   "write enable failed in write protect!\n");
> > +   return -EINVAL;
> > +   }
> > +   writeb(cmd1, mt8173_nor->base + MTK_NOR_PRGDATA5_REG);
> > +   writeb(8, mt8173_nor->base + MTK_NOR_CNT_REG);
> > +   if (mt8173_nor_execute_cmd(mt8173_nor, cmd2)) {
> > +   dev_err(mt8173_nor->dev, "execute cmd failed!\n");
> 
> mt8173_nor_execute_cmd() will already have printed an error message.
> 
And mt8173_nor_execute_cmd()/mt8173_nor_set_cmd() returned an error
code which should be promoted to the caller rather than
inventing a new one.
The same for other instances of this code fragment.


Lothar Waßmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/5] kselftest improvement and cleanup

[Bamvor Jian Zhang]

This is my third attempt for improving the kselftest for arm/arm64
architecture. Eventually, we hope we could build(in an cross compile
environment) and run all the kselftest cases automatically(successful
of courses). The first and second version is here[1][2].

In this series, I try to make all the testcases compiling and
installation successful.

Changes since v2:
1.  Remove the patch "selftests: only compile userfaultfd for x86 and
powperpc". Michael sent anther better patch.
2.  Improve the commits and patches according to Michael's suggestion.

c 9fae100 selftests: breakpoints: fix installing error on the architecture 
except x86
c a7d0f07 selftests: check before install
a 1189f67 selftests: rename jump label to static_keys
a 4ee06bb selftests: mqueue: allow extra cflags
  9767a8e selftests: mqueue: Simplify the Makefile
  980ac26 selftests: change install command to rsync
  82775ac selftests: exec: Revert to default emit rule

"c" means committed by Shuah Khan 
"a" means acked by Shuah Khan  or Michael Ellermani 



Bamvor Jian Zhang (5):
  selftests: rename jump label to static_keys
  selftests: mqueue: allow extra cflags
  selftests: mqueue: simplify the Makefile
  selftests: change install command to rsync
  selftests: exec: revert to default emit rule

 tools/testing/selftests/Makefile|  2 +-
 tools/testing/selftests/exec/Makefile   |  4 +---
 tools/testing/selftests/ftrace/Makefile |  2 +-
 tools/testing/selftests/lib.mk  | 11 ---
 tools/testing/selftests/mqueue/Makefile | 10 --
 5 files changed, 11 insertions(+), 18 deletions(-)

-- 
2.1.4

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

[PATCH v3 1/5] selftests: rename jump label to static_keys

[Bamvor Jian Zhang]

Commit 2bf9e0ab08c6 ("locking/static_keys: Provide a selftest")
renamed jump_label directory to static_keys and failed to update
the Makefile, causing the selftests build to fail.

This commit fixes it by updating the Makefile with the new name
and also moves the entry into the correct position to keep the
list alphabetically sorted.

Fixes: 2bf9e0ab08c6 ("locking/static_keys: Provide a selftest")
Signed-off-by: Bamvor Jian Zhang 
Acked-by: Shuah Khan 
Acked-by: Michael Ellerman 
---
 tools/testing/selftests/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index ac40ec9..8922c21 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -17,12 +17,12 @@ TARGETS += powerpc
 TARGETS += ptrace
 TARGETS += seccomp
 TARGETS += size
+TARGETS += static_keys
 TARGETS += sysctl
 ifneq (1, $(quicktest))
 TARGETS += timers
 endif
 TARGETS += user
-TARGETS += jumplabel
 TARGETS += vm
 TARGETS += x86
 TARGETS += zram
-- 
2.1.4

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

[PATCH v3 3/5] selftests: mqueue: simplify the Makefile

[Bamvor Jian Zhang]

Use make's implict rule for building simple C programs.

Suggested-by: Michael Ellermani 
Signed-off-by: Bamvor Jian Zhang 
---
 tools/testing/selftests/mqueue/Makefile | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/testing/selftests/mqueue/Makefile 
b/tools/testing/selftests/mqueue/Makefile
index ca8327f..eebac29 100644
--- a/tools/testing/selftests/mqueue/Makefile
+++ b/tools/testing/selftests/mqueue/Makefile
@@ -1,8 +1,8 @@
 CFLAGS += -O2
+LDLIBS = -lrt -lpthread -lpopt
+TEST_PROGS := mq_open_tests mq_perf_tests
 
-all:
-   $(CC) $(CFLAGS) mq_open_tests.c -o mq_open_tests -lrt
-   $(CC) $(CFLAGS) -o mq_perf_tests mq_perf_tests.c -lrt -lpthread -lpopt
+all: $(TEST_PROGS)
 
 include ../lib.mk
 
@@ -11,8 +11,6 @@ override define RUN_TESTS
@./mq_perf_tests || echo "selftests: mq_perf_tests [FAIL]"
 endef
 
-TEST_PROGS := mq_open_tests mq_perf_tests
-
 override define EMIT_TESTS
echo "./mq_open_tests /test1 || echo \"selftests: mq_open_tests 
[FAIL]\""
echo "./mq_perf_tests || echo \"selftests: mq_perf_tests [FAIL]\""
-- 
2.1.4

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

[PATCH v12 00/21] Compile-time stack metadata validation

[Josh Poimboeuf]

This is v12 of the compile-time stack metadata validation patch set,
along with proposed fixes for many of the warnings it found.  It's based
on the tip/master branch.

Biggest changes since v11:

- Moved the tool from scripts/ to tools/ so it can be a standalone
  program for use by non-kernel code bases.

- Renamed from "stackvalidate" to "stacktool" (for lack of a better
  name).  "stackvalidate" is too limiting because eventually it will do
  more than just validation -- it will also have the ability to modify
  the object file when CFI generation support gets added.

v11 can be found here:

  https://lkml.kernel.org/r/cover.1440423732.git.jpoim...@redhat.com

For more information about the motivation behind this patch set, and
more details about what it does, see the patch 4 changelog and
tools/stacktool/Documentation/stack-validation.txt.

Patch 1 fixes the formatting for the "make -C tools" help message.

Patches 2-6 add stacktool and some related macros.

Patches 7-21 are some proposed fixes for several of the warnings
reported by stacktool.  They've been compile-tested and boot-tested in a
VM, but I haven't attempted any meaningful testing for many of them.

v12:
- rename "stackvalidate" -> "stacktool"
- move from scripts/ to tools/:
  - makefile rework
  - make a copy of the x86 insn code (and warn if the code diverges)
  - use tools/include/linux/list.h
- move warning macros to a new warn.h file
- change wording: "stack validation" -> "stack metadata validation"

v11:
- attempt to answer the "why" question better in the documentation and
  commit message
- s/FP_SAVE/FRAME_BEGIN/ in documentation

v10:
- add scripts/mod to directory ignores
- remove circular dependencies for ignored objects which are built
  before stackvalidate
- fix CONFIG_MODVERSIONS incompatibility

v9:
- rename FRAME/ENDFRAME -> FRAME_BEGIN/FRAME_END
- fix jump table issue for when the original instruction is a jump
- drop paravirt thunk alignment patch
- add maintainers to CC for proposed warning fixes

v8:
- add proposed fixes for warnings
- fix all memory leaks
- process ignores earlier and add more ignore checks
- always assume POPCNT alternative is enabled
- drop hweight inline asm fix
- drop __schedule() ignore patch
- change .Ltemp_\@ to .Lstackvalidate_ignore_\@ in asm macro
- fix CONFIG_* checks in asm macros
- add C versions of ignore macros and frame macros
- change ";" to "\n" in C macros
- add ifdef CONFIG_STACK_VALIDATION checks in C ignore macros
- use numbered label in C ignore macro
- add missing break in switch case statement in arch-x86.c

v7:
- sibling call support
- document proposed solution for inline asm() frame pointer issues
- say "kernel entry/exit" instead of "context switch"
- clarify the checking of switch statement jump tables
- discard __stackvalidate_ignore_* sections in linker script
- use .Ltemp_\@ to get a unique label instead of static 3-digit number
- change STACKVALIDATE_IGNORE_FUNC variable to a static
- move STACKVALIDATE_IGNORE_INSN to arch-specific .h file

v6:
- rename asmvalidate -> stackvalidate (again)
- gcc-generated object file support
- recursive branch state analysis
- external jump support
- fixup/exception table support
- jump label support
- switch statement jump table support
- added documentation
- detection of "noreturn" dead end functions
- added a Kbuild mechanism for skipping files and dirs
- moved frame pointer macros to arch/x86/include/asm/frame.h
- moved ignore macros to include/linux/stackvalidate.h

v5:
- stackvalidate -> asmvalidate
- frame pointers only required for non-leaf functions
- check for the use of the FP_SAVE/RESTORE macros instead of manually
  analyzing code to detect frame pointer usage
- additional checks to ensure each function doesn't leave its boundaries
- make the macros simpler and more flexible
- support for analyzing ALTERNATIVE macros
- simplified the arch interfaces in scripts/asmvalidate/arch.h
- fixed some asmvalidate warnings
- rebased onto latest tip asm cleanups
- many more small changes

v4:
- Changed the default to CONFIG_STACK_VALIDATION=n, until all the asm
  code can get cleaned up.
- Fixed a stackvalidate error path exit code issue found by Michal
  Marek.

v3:
- Added a patch to make the push/pop CFI macros arch-independent, as
  suggested by H. Peter Anvin

v2:
- Fixed memory leaks reported by Petr Mladek

Cc: linux-kernel@vger.kernel.org
Cc: live-patch...@vger.kernel.org
Cc: Michal Marek 
Cc: Peter Zijlstra 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Andi Kleen 
Cc: Pedro Alves 
Cc: Namhyung Kim 
Cc: Bernd Petrovitsch 
Cc: "Chris J Arges" 
Cc: Andrew Morton 

Josh Poimboeuf (21):
  tools: Fix formatting of the "make -C tools" help message
  x86/asm: Frame 

[PATCH linux-next v6 4/8] mtd: spi-nor: use optimized commands for read/write/erase operations

[Cyrille Pitchen]

The op codes used by the spi-nor framework are now tuned depending on the
memory manufacturer.

Signed-off-by: Cyrille Pitchen 
---
 drivers/mtd/spi-nor/spi-nor.c | 156 +++---
 include/linux/mtd/spi-nor.h   |   6 ++
 2 files changed, 138 insertions(+), 24 deletions(-)

diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
index 4b36aada3f4c..820a2177ed5e 100644
--- a/drivers/mtd/spi-nor/spi-nor.c
+++ b/drivers/mtd/spi-nor/spi-nor.c
@@ -193,6 +193,8 @@ static inline int set_4byte(struct spi_nor *nor, const 
struct flash_info *info,
write_disable(nor);
 
return status;
+   case CFI_MFR_AMD:
+   return 0;
default:
/* Spansion style */
nor->cmd_buf[0] = enable << 7;
@@ -945,7 +947,7 @@ static int spansion_quad_enable(struct spi_nor *nor)
}
 
/* set read/write protocols */
-   nor->read_proto = SPI_PROTO_1_1_4;
+   nor->read_proto = SPI_PROTO_1_4_4;
nor->write_proto = SPI_PROTO_1_1_4;
 
return 0;
@@ -1059,7 +1061,7 @@ static int set_dual_mode(struct spi_nor *nor, const 
struct flash_info *info)
return status;
case CFI_MFR_MACRONIX:
case CFI_MFR_AMD:
-   nor->read_proto = SPI_PROTO_1_1_2;
+   nor->read_proto = SPI_PROTO_1_2_2;
break;
default:
break;
@@ -1068,6 +1070,130 @@ static int set_dual_mode(struct spi_nor *nor, const 
struct flash_info *info)
return 0;
 }
 
+static void macronix_set_commands(struct spi_nor *nor)
+{
+   switch (nor->flash_read) {
+   case SPI_NOR_QUAD: /* QPI mode */
+   nor->read_opcode = SPINOR_OP_READ_1_4_4;
+   break;
+
+   case SPI_NOR_DUAL:
+   nor->read_opcode = SPINOR_OP_READ_1_2_2;
+   break;
+
+   case SPI_NOR_FAST:
+   nor->read_opcode = SPINOR_OP_READ_FAST;
+   break;
+
+   case SPI_NOR_NORMAL:
+   default:
+   nor->read_opcode = SPINOR_OP_READ;
+   break;
+   }
+
+   nor->program_opcode = SPINOR_OP_PP;
+}
+
+static void micron_set_commands(struct spi_nor *nor)
+{
+   switch (nor->flash_read) {
+   case SPI_NOR_QUAD: /* Quad I/O operations */
+   nor->read_opcode = SPINOR_OP_READ_1_4_4;
+   break;
+
+   case SPI_NOR_DUAL: /* Dual I/O operations */
+   nor->read_opcode = SPINOR_OP_READ_1_2_2;
+   break;
+
+   case SPI_NOR_FAST:
+   nor->read_opcode = SPINOR_OP_READ_FAST;
+   break;
+
+   case SPI_NOR_NORMAL:
+   default:
+   nor->read_opcode = SPINOR_OP_READ;
+   break;
+   }
+
+   nor->program_opcode = SPINOR_OP_PP;
+}
+
+static void spansion_set_commands(struct spi_nor *nor,
+ const struct flash_info *info)
+{
+   bool addr_4byte = (nor->addr_width == 4);
+   struct mtd_info *mtd = nor->mtd;
+
+   switch (nor->flash_read) {
+   case SPI_NOR_QUAD:
+   if (addr_4byte) {
+   nor->read_opcode = SPINOR_OP_READ4_1_4_4;
+   nor->program_opcode = SPINOR_OP_PP_4B_1_1_4;
+   } else {
+   nor->read_opcode = SPINOR_OP_READ_1_4_4;
+   nor->program_opcode = SPINOR_OP_PP_1_1_4;
+   }
+   break;
+
+   case SPI_NOR_DUAL:
+   if (addr_4byte) {
+   nor->read_opcode = SPINOR_OP_READ4_1_2_2;
+   nor->program_opcode = SPINOR_OP_PP_4B;
+   } else {
+   nor->read_opcode = SPINOR_OP_READ_1_2_2;
+   nor->program_opcode = SPINOR_OP_PP;
+   }
+   break;
+
+   case SPI_NOR_FAST:
+   if (addr_4byte) {
+   nor->read_opcode = SPINOR_OP_READ4_FAST;
+   nor->program_opcode = SPINOR_OP_PP_4B;
+   } else {
+   nor->read_opcode = SPINOR_OP_READ_FAST;
+   nor->program_opcode = SPINOR_OP_PP;
+   }
+   break;
+
+   case SPI_NOR_NORMAL:
+   default:
+   if (addr_4byte) {
+   nor->read_opcode = SPINOR_OP_READ4;
+   nor->program_opcode = SPINOR_OP_PP_4B;
+   } else {
+   nor->read_opcode = SPINOR_OP_READ;
+   nor->program_opcode = SPINOR_OP_PP;
+   }
+   break;
+   }
+
+   if (addr_4byte) {
+   nor->erase_opcode = SPINOR_OP_SE_4B;
+   mtd->erasesize = info->sector_size;
+   }
+}
+
+static void tune_manufacturer_commands(struct spi_nor *nor,
+  const struct flash_info *info)
+{
+   switch (JEDEC_MFR(info)) {
+  

[PATCH v12 03/21] x86/asm: Add C versions of frame pointer macros

[Josh Poimboeuf]

Add C versions of the frame pointer macros which can be used to create a
stack frame in inline assembly.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/include/asm/frame.h | 20 ++--
 1 file changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/frame.h b/arch/x86/include/asm/frame.h
index 8a6cd26..9a30ec7 100644
--- a/arch/x86/include/asm/frame.h
+++ b/arch/x86/include/asm/frame.h
@@ -1,10 +1,10 @@
 #ifndef _ASM_X86_FRAME_H
 #define _ASM_X86_FRAME_H
 
-#ifdef __ASSEMBLY__
-
 #include 
 
+#ifdef __ASSEMBLY__
+
 /*
  * These are stack frame creation macros.  They should be used by every
  * callable non-leaf asm function to make kernel stack traces more reliable.
@@ -22,5 +22,21 @@
 #endif
 .endm
 
+#else /* !__ASSEMBLY__ */
+
+#ifdef CONFIG_FRAME_POINTER
+
+#define FRAME_BEGIN\
+   "push %" _ASM_BP "\n"   \
+   _ASM_MOV "%" _ASM_SP ", %" _ASM_BP "\n"
+
+#define FRAME_END "pop %" _ASM_BP "\n"
+
+#else /* !CONFIG_FRAME_POINTER */
+
+#define FRAME_BEGIN ""
+#define FRAME_END ""
+
+#endif /* CONFIG_FRAME_POINTER */
 #endif  /*  __ASSEMBLY__  */
 #endif /* _ASM_X86_FRAME_H */
-- 
2.4.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/

[GIT PULL] pwm: Changes for v4.3-rc1

[Thierry Reding]

Hi Linus,

The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754:

  Linux 4.2-rc1 (2015-07-05 11:01:52 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git 
tags/pwm/for-4.3-rc1

for you to fetch changes up to 7a5938201834a9c25155176d0f5942d48336b244:

  ARM: at91: pwm: atmel-hlcdc: Add at91sam9n12 errata (2015-09-09 15:16:01 
+0200)

Thanks,
Thierry


pwm: Changes for v4.3-rc1

This set of changes introduces the beginnings of a new API that's based
around the concept of states that can be atomically applied. Drivers go
to various lengths to implement something similar, which indicates that
the core should really be providing the necessary framework.

On top of that, there is a bit of cleanup as well as improved kerneldoc
and integration into the device-drivers DocBook.

Regarding drivers there is a new one for the NXP LPC18xx family of SoCs
and a couple of fixes for existing drivers (pca9685, Broadcom Kona and
Atmel HLCDC).


Ariel D'Alessandro (2):
  pwm: NXP LPC18xx PWM/SCT driver
  pwm: Add NXP LPC18xx PWM/SCT DT binding documentation

Boris Brezillon (4):
  pwm: Add the pwm_is_enabled() helper
  pwm: Constify PWM device where possible
  pwm: Add pwm_get_polarity() helper function
  pwm: Make use of pwm_get_xxx() helpers where appropriate

Clemens Gruber (2):
  pwm-pca9685: Fix several driver bugs
  pwm-pca9685: Support changing the output frequency

Jonathan Richardson (1):
  pwm: kona: Modify settings application sequence

Josh Wu (1):
  ARM: at91: pwm: atmel-hlcdc: Add at91sam9n12 errata

Krzysztof Kozlowski (1):
  pwm: pca9685: Drop owner assignment

Thierry Reding (5):
  pwm: sysfs: Properly convert from enum to string
  pwm: sysfs: Remove unnecessary padding
  pwm: Remove useless whitespace
  pwm: Clean up kerneldoc
  pwm: Add to device-drivers documentation

 Documentation/DocBook/device-drivers.tmpl  |  27 ++
 .../devicetree/bindings/pwm/lpc1850-sct-pwm.txt|  20 +
 drivers/pwm/Kconfig|  12 +
 drivers/pwm/Makefile   |   1 +
 drivers/pwm/core.c |  49 ++-
 drivers/pwm/pwm-atmel-hlcdc.c  |   5 +
 drivers/pwm/pwm-atmel-tcb.c|   2 +-
 drivers/pwm/pwm-atmel.c|   6 +-
 drivers/pwm/pwm-bcm-kona.c |  54 ++-
 drivers/pwm/pwm-ep93xx.c   |   4 +-
 drivers/pwm/pwm-imx.c  |   5 +-
 drivers/pwm/pwm-lpc18xx-sct.c  | 465 +
 drivers/pwm/pwm-mxs.c  |   4 +-
 drivers/pwm/pwm-pca9685.c  |  90 +++-
 drivers/pwm/pwm-renesas-tpu.c  |   2 +-
 drivers/pwm/pwm-rockchip.c |   2 +-
 drivers/pwm/pwm-tegra.c|   6 +-
 drivers/pwm/pwm-tiecap.c   |  10 +-
 drivers/pwm/pwm-tiehrpwm.c |   6 +-
 drivers/pwm/sysfs.c|  29 +-
 include/linux/pwm.h|  99 +++--
 21 files changed, 802 insertions(+), 96 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/pwm/lpc1850-sct-pwm.txt
 create mode 100644 drivers/pwm/pwm-lpc18xx-sct.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/page_alloc: add a helper function to check page before alloc/free

[Vlastimil Babka]

On 09/08/2015 09:19 PM, Vlastimil Babka wrote:

bloat-o-meter looks favorably with my gcc, although there shouldn't be a real
reason for it, as the inlining didn't change:

add/remove: 1/1 grow/shrink: 1/1 up/down: 285/-336 (-51)
function old new   delta
bad_page   - 276+276
get_page_from_freelist  25212530  +9
free_pages_prepare   745 667 -78
bad_page.part258   --258

With that,

Acked-by: Vlastimil Babka 


BTW, why do we do all these checks in non-DEBUG_VM builds? Are they so 
often hit nowadays? Shouldn't we check just for hwpoison in the 
non-debug case?


Alternatively, I've considered creating a fast inline pre-check that 
calls a non-inline check-with-report:


diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 0c9c82a..cff92f8 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -707,7 +707,20 @@ static inline void __free_one_page(struct page *page,
zone->free_area[order].nr_free++;
 }

-static inline int check_one_page(struct page *page, unsigned long 
bad_flags)

+static inline int check_one_page_fast(struct page *page, unsigned long
+   bad_flags)
+{
+   return (page_mapcount(page)
+   || page->mapping != NULL
+   || atomic_read(>_count) != 0
+   || page->flags & bad_flags
+#ifdef CONFIG_MEMCG
+   || page->mem_cgroup
+#endif
+   );
+}
+
+static noinline int check_one_page(struct page *page, unsigned long 
bad_flags)

 {
const char *bad_reason = NULL;

@@ -743,9 +756,12 @@ static inline int free_pages_check(struct page *page)
 {
int ret = 0;

-   ret = check_one_page(page, PAGE_FLAGS_CHECK_AT_FREE);
-   if (ret)
-   return ret;
+   ret = check_one_page_fast(page, PAGE_FLAGS_CHECK_AT_FREE);
+   if (ret) {
+   ret = check_one_page(page, PAGE_FLAGS_CHECK_AT_FREE);
+   if (ret)
+   return ret;
+   }

page_cpupid_reset_last(page);
if (page->flags & PAGE_FLAGS_CHECK_AT_PREP)
@@ -1304,7 +1320,9 @@ static inline void expand(struct zone *zone, 
struct page *page,

  */
 static inline int check_new_page(struct page *page)
 {
-   return check_one_page(page, PAGE_FLAGS_CHECK_AT_PREP);
+   if (check_one_page_fast(page, PAGE_FLAGS_CHECK_AT_PREP | __PG_HWPOISON))
+   return check_one_page(page, PAGE_FLAGS_CHECK_AT_PREP);
+   return 0;
 }

 static int prep_new_page(struct page *page, unsigned int order, gfp_t 
gfp_flags,


---

That shrinks the fast paths nicely:

add/remove: 1/1 grow/shrink: 0/2 up/down: 480/-498 (-18)
function old new   delta
check_one_page - 480+480
get_page_from_freelist  25302458 -72
free_pages_prepare   667 517-150
bad_page 276   --276

On top of that, the number of branches in the fast paths can be reduced 
if we use arithmetic OR to avoid the short-circuit boolean evaluation:


diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cff92f8..e8b42ba 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -710,12 +710,12 @@ static inline void __free_one_page(struct page *page,
 static inline int check_one_page_fast(struct page *page, unsigned long
bad_flags)
 {
-   return (page_mapcount(page)
-   || page->mapping != NULL
-   || atomic_read(>_count) != 0
-   || page->flags & bad_flags
+   return ((unsigned long) page_mapcount(page)
+   | (unsigned long) page->mapping
+   | (unsigned long) atomic_read(>_count)
+   | (page->flags & bad_flags)
 #ifdef CONFIG_MEMCG
-   || page->mem_cgroup
+   | (unsigned long) page->mem_cgroup
 #endif
);
 }

That further reduces the fast paths, not much in bytes, but importantly 
in branches:


add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-51 (-51)
function old new   delta
get_page_from_freelist  24582443 -15
free_pages_prepare   517 481 -36

But I can understand it's rather hackish, and maybe some architectures 
won't be happy with the extra unsigned long arithmetics. Thoughts?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v12 12/21] x86/xen: Add xen_cpuid() and xen_setup_gdt() to stacktool whitelists

[David Vrabel]

On 09/09/15 14:21, Josh Poimboeuf wrote:
> stacktool reports the following false positive warnings:
> 
>   stacktool: arch/x86/xen/enlighten.o: xen_cpuid()+0x41: can't find jump dest 
> instruction at .text+0x108
>   stacktool: arch/x86/xen/enlighten.o: xen_setup_gdt.constprop.23()+0x2e: 
> kernel entry/exit from callable instruction
> 
> The first warning is due to xen_cpuid()'s use of XEN_EMULATE_PREFIX to
> insert some fake instructions which stacktool doesn't know how to
> decode.
> 
> The second warning is due to xen_setup_gdt()'s use of an lret
> instruction, which stacktool normally doesn't allow in callable
> functions.  But this seems to be a valid use of the instruction.
> 
> Add both functions to the stacktool whitelist.

Reviewed-by: David Vrabel 

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

Re: [PATCH] powerpc: define empty enable_kernel_vsx() when CONFIG_VSX=n

[Tim Gardner]

On 09/08/2015 08:13 PM, Michael Ellerman wrote:

On Tue, 2015-09-08 at 17:19 -0600, Tim Gardner wrote:

On 09/08/2015 04:47 PM, Paul Mackerras wrote:

On Tue, Sep 08, 2015 at 12:13:11PM -0600, tim.gard...@canonical.com wrote:

From: Tim Gardner 

commit 72cd7b44bc99 ("powerpc: Uncomment and make enable_kernel_vsx()
routine available") neglected to define an empty inline replacement for
enable_kernel_vsx() when CONFIG_VSX=n.


If code that wants to call enable_kernel_vsx() is getting compiled in
when CONFIG_VSX=n, that's a worry.  Is this patch motivated by an
actual compile failure?  If so what was the failure?


I was having link failures after backporting 'crypto: nx' patches to a
4.2 based kernel. You may have a point in that the upstream Kconfig will
not allow those files to be compiled if CONFIG_VSX=n. I will check in my
morning if to see if I can reproduce the same link error in mainline.


I suspect the problem is the "vmx" crypto actually.

$ git grep enable_kernel_vsx drivers/
drivers/crypto/vmx/aes.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_cbc.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/aes_ctr.c:   enable_kernel_vsx();
drivers/crypto/vmx/ghash.c: enable_kernel_vsx();
drivers/crypto/vmx/ghash.c: enable_kernel_vsx();
drivers/crypto/vmx/ghash.c: enable_kernel_vsx();
drivers/crypto/vmx/ghash.c: enable_kernel_vsx();


That appears to all be controlled by CONFIG_CRYPTO_DEV_VMX_ENCRYPT, which
depends on CONFIG_CRYPTO_DEV_VMX, which depends on PPC64.

So that looks like it will break terribly if VSX is turned off.

We do have an automated test build with VSX turned off, but it doesn't have
CONFIG_CRYPTO_DEV_VMX enabled :/


Having said all that, why are you building a ppc64 kernel with VSX turned off?

cheers




I'm pretty sure my problem is that I'm building a 32bit powerpc with 
CONFIG_CRYPTO_DEV_VMX_ENCRYPT=y, though it is hard to tell for sure with 
the interleaved build output from 4 parallel builds (powerpc-smp 
powerpc64-smp powerpc-e500mc powerpc64-emb). Your proposed patch 
("[PATCH v2] crypto: vmx - VMX crypto should depend on CONFIG_VSX") 
fixes my problems (and makes more sense then my patch), so I suddenly 
don't care as much.


rtg
--
Tim Gardner tim.gard...@canonical.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/

[PATCH v12 18/21] x86/asm/acpi: Create a stack frame in do_suspend_lowlevel()

[Josh Poimboeuf]

do_suspend_lowlevel() is a callable non-leaf function which doesn't
honor CONFIG_FRAME_POINTER, which can result in bad stack traces.

Create a stack frame for it when CONFIG_FRAME_POINTER is enabled.

Signed-off-by: Josh Poimboeuf 
Acked-by: Pavel Machek 
Cc: "Rafael J. Wysocki" 
Cc: Len Brown 
---
 arch/x86/kernel/acpi/wakeup_64.S | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/x86/kernel/acpi/wakeup_64.S b/arch/x86/kernel/acpi/wakeup_64.S
index 8c35df4..169963f 100644
--- a/arch/x86/kernel/acpi/wakeup_64.S
+++ b/arch/x86/kernel/acpi/wakeup_64.S
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 # Copyright 2003 Pavel Machek , distribute under GPLv2
 
@@ -39,6 +40,7 @@ bogus_64_magic:
jmp bogus_64_magic
 
 ENTRY(do_suspend_lowlevel)
+   FRAME_BEGIN
subq$8, %rsp
xorl%eax, %eax
callsave_processor_state
@@ -109,6 +111,7 @@ ENTRY(do_suspend_lowlevel)
 
xorl%eax, %eax
addq$8, %rsp
+   FRAME_END
jmp restore_processor_state
 ENDPROC(do_suspend_lowlevel)
 
-- 
2.4.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 v3] mm/page_alloc: add a helper function to check page before alloc/free

[Yaowei Bai]

On Tue, Sep 08, 2015 at 09:19:07PM +0200, Vlastimil Babka wrote:
> On 08/27/2015 02:51 PM, Yaowei Bai wrote:
> > The major portion of check_new_page() and free_pages_check() are same,
> > introduce a helper function check_one_page() for simplification.
> > 
> > Change in v3:
> > - add the missed __PG_HWPOISON check per Michal Hocko
> > Change in v2:
> > - use bad_flags as parameter directly per Michal Hocko
> > 
> > Signed-off-by: Yaowei Bai 
> > ---
> >  mm/page_alloc.c | 54 +++---
> >  1 file changed, 23 insertions(+), 31 deletions(-)
> > 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 5b5240b..0c9c82a 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -707,10 +707,9 @@ out:
> > zone->free_area[order].nr_free++;
> >  }
> >  
> > -static inline int free_pages_check(struct page *page)
> > +static inline int check_one_page(struct page *page, unsigned long 
> > bad_flags)
> >  {
> > const char *bad_reason = NULL;
> > -   unsigned long bad_flags = 0;
> >  
> > if (unlikely(page_mapcount(page)))
> > bad_reason = "nonzero mapcount";
> > @@ -718,9 +717,16 @@ static inline int free_pages_check(struct page *page)
> > bad_reason = "non-NULL mapping";
> > if (unlikely(atomic_read(>_count) != 0))
> > bad_reason = "nonzero _count";
> > -   if (unlikely(page->flags & PAGE_FLAGS_CHECK_AT_FREE)) {
> > -   bad_reason = "PAGE_FLAGS_CHECK_AT_FREE flag(s) set";
> > -   bad_flags = PAGE_FLAGS_CHECK_AT_FREE;
> > +   if (bad_flags == PAGE_FLAGS_CHECK_AT_PREP) {
> > +   if (unlikely(page->flags & bad_flags))
> > +   bad_reason = "PAGE_FLAGS_CHECK_AT_PREP flag set";
> > +   if (unlikely(page->flags & __PG_HWPOISON)) {
> > +   bad_reason = "HWPoisoned (hardware-corrupted)";
> > +   bad_flags = __PG_HWPOISON;
> > +   }
> 
> Before, HWPOISON was checked first, which means that it had lower priority 
> than
> PAGE_FLAGS_CHECK_AT_PREP (counter-intuitively). I can see why you switched 
> that
> though. You could fix that by changing the second nested "if" to "else if", 
> but
> I guess it doesn't matter. The "priorities" don't seem to be carefuly sorted 
> anyway.

OK, so let's leave as it is and see other guys' ideas. If there is any 
objection i will
resend with fixing the priority.

> 
> bloat-o-meter looks favorably with my gcc, although there shouldn't be a real
> reason for it, as the inlining didn't change:
> 
> add/remove: 1/1 grow/shrink: 1/1 up/down: 285/-336 (-51)
> function old new   delta
> bad_page   - 276+276
> get_page_from_freelist  25212530  +9
> free_pages_prepare   745 667 -78
> bad_page.part258   --258
> 
> With that,
> 
> Acked-by: Vlastimil Babka 

Thanks.

> 
> > +   } else if (bad_flags == PAGE_FLAGS_CHECK_AT_FREE) {
> > +   if (unlikely(page->flags & bad_flags))
> > +   bad_reason = "PAGE_FLAGS_CHECK_AT_FREE flag set";
> > }
> >  #ifdef CONFIG_MEMCG
> > if (unlikely(page->mem_cgroup))
> > @@ -730,6 +736,17 @@ static inline int free_pages_check(struct page *page)
> > bad_page(page, bad_reason, bad_flags);
> > return 1;
> > }
> > +   return 0;
> > +}
> > +
> > +static inline int free_pages_check(struct page *page)
> > +{
> > +   int ret = 0;
> > +
> > +   ret = check_one_page(page, PAGE_FLAGS_CHECK_AT_FREE);
> > +   if (ret)
> > +   return ret;
> > +
> > page_cpupid_reset_last(page);
> > if (page->flags & PAGE_FLAGS_CHECK_AT_PREP)
> > page->flags &= ~PAGE_FLAGS_CHECK_AT_PREP;
> > @@ -1287,32 +1304,7 @@ static inline void expand(struct zone *zone, struct 
> > page *page,
> >   */
> >  static inline int check_new_page(struct page *page)
> >  {
> > -   const char *bad_reason = NULL;
> > -   unsigned long bad_flags = 0;
> > -
> > -   if (unlikely(page_mapcount(page)))
> > -   bad_reason = "nonzero mapcount";
> > -   if (unlikely(page->mapping != NULL))
> > -   bad_reason = "non-NULL mapping";
> > -   if (unlikely(atomic_read(>_count) != 0))
> > -   bad_reason = "nonzero _count";
> > -   if (unlikely(page->flags & __PG_HWPOISON)) {
> > -   bad_reason = "HWPoisoned (hardware-corrupted)";
> > -   bad_flags = __PG_HWPOISON;
> > -   }
> > -   if (unlikely(page->flags & PAGE_FLAGS_CHECK_AT_PREP)) {
> > -   bad_reason = "PAGE_FLAGS_CHECK_AT_PREP flag set";
> > -   bad_flags = PAGE_FLAGS_CHECK_AT_PREP;
> > -   }
> > -#ifdef CONFIG_MEMCG
> > -   if (unlikely(page->mem_cgroup))
> > -   bad_reason = "page still charged to cgroup";
> > -#endif
> > -   if (unlikely(bad_reason)) {
> > -   bad_page(page, bad_reason, bad_flags);
> > -

Re: [PATCH] ahci: qoriq: fixed using uninitialized variable warnings

[Tejun Heo]

On Wed, Sep 09, 2015 at 05:16:22PM +0800, yuantian.t...@freescale.com wrote:
> From: Tang Yuantian 
> 
> kbuild test robot reports the warnings:
> drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
> >> include/asm-generic/io.h:163:2: warning: 'px_is' may be used
> >> uninitialized in this function [-Wuninitialized]
> drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here
> >> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
> >> uninitialized in this function [-Wuninitialized]
> drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here
> 
> This patch fixed it by assigning 0 to px_is and px_cmd variables.
> This patch also remove line 'struct ccsr_ahci *reg_base' which is
> not referred by any other codes and thus a dead one.

Hmm... I think the problem here is that the complier can't know
whether qoriq_priv->type would change across intervening function
calls.  Maybe a better solution is caching the type in a local
variable so that the compiler can tell that those two tests will
always move together?  It generally isn't a good idea to clear
variables unnecessarily as that can hide actual bugs that compiler can
detect.

Thanks.

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

Re: [PATCH] soc: mediatek: Move the initial setting of pmic wrap interrupt before requesting irq.

[Henry Chen]

Hi Sascha,

On Mon, 2015-09-07 at 07:39 +0200, Sascha Hauer wrote:
> On Fri, Sep 04, 2015 at 12:05:12PM +0800, Henry Chen wrote:
> > Seperate the initialization of pmic wrap interrupt from pmic wrap init to 
> > make sure setting is correct before requesting irq.
> 
> It seems the problem this patch solves is the missing watchdog
> initialization when the pwrap is already initialized but the watchdog is
> not, so how about a commit log like:
> 
> "The watchdog may not be initialized by the bootloader, even if the rest
> of the pwrap is. Move the watchdog initialization out of pwrap_init()
> to make sure the watchdog is always initialized and not only when the
> pwrap is uninitialized."
> 
> Also please add linebreaks to the commit log.
> 

Yes, thanks for explanation, I will add this on commit log make it more
clearly to understand.

Henry

> > 
> > Signed-off-by: Henry Chen 
> > ---
> >  drivers/soc/mediatek/mtk-pmic-wrap.c | 14 ++
> >  1 file changed, 10 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pmic-wrap.c 
> > b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > index f432291..c91d629 100644
> > --- a/drivers/soc/mediatek/mtk-pmic-wrap.c
> > +++ b/drivers/soc/mediatek/mtk-pmic-wrap.c
> > @@ -725,10 +725,6 @@ static int pwrap_init(struct pmic_wrapper *wrp)
> > pwrap_writel(wrp, 0x1, PWRAP_WACS2_EN);
> > pwrap_writel(wrp, 0x5, PWRAP_STAUPD_PRD);
> > pwrap_writel(wrp, 0xff, PWRAP_STAUPD_GRPEN);
> > -   pwrap_writel(wrp, 0xf, PWRAP_WDT_UNIT);
> > -   pwrap_writel(wrp, 0x, PWRAP_WDT_SRC_EN);
> > -   pwrap_writel(wrp, 0x1, PWRAP_TIMER_EN);
> > -   pwrap_writel(wrp, ~((1 << 31) | (1 << 1)), PWRAP_INT_EN);
> >  
> > if (pwrap_is_mt8135(wrp)) {
> > /* enable pwrap events and pwrap bridge in AP side */
> > @@ -896,6 +892,16 @@ static int pwrap_probe(struct platform_device *pdev)
> > return -ENODEV;
> > }
> >  
> > +   /*
> > +* watch dog@pwrap,
> > +* The bootloader may not initial the wdt/interrupt setting of pwrap,
> > +* set it before reguesting the irq.
> > +*/
> 
> /* initialize watchdog, may not be done by the bootloader */
> 
> Sascha
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ethtool: changes of emac_regs structure accordingly within driver emac_regs structure.

[Ivan Mikhaylov]

On Wed, 9 Aug 2015 15:10:00 +0400
Ivan Mikhaylov  wrote:

>On Wed, 2015-08-05 at 15:01 +0400, Ivan Mikhaylov wrote:
>> * do the redefinition of emac_regs struct from driver structure
>> perspective and passing size from actual struct size, not from memory
>> area variable which set in dts file.
>> 
>> * passing variable from dts option may cause a problem with output
>> below MII's section which we're fixing with this and 5369c71 commit
>> in kernel.
>[...]
>
>But you still aren't handling the case where only one of the driver and
>ethtool is upgraded, even by reporting an error.
>
>I'm never going to apply patches to ethtool that obviously break binary
>compatibility, so you are wasting your time sending me new versions
>that do that.
>
>At this point you should probably just bump the dump version numbers in
>both places.
>
>Ben.
>
>-- 
>Ben Hutchings
>friends: People who know you well, but like you anyway.
>
>[unhandled content-type:application/pgp-signature]

Ben, thanks for looking to that. 

I decided to divide patches for 
1 - structure change which fixing problem
2 - add EMAC4SYNC
May be it wasn't clear from first patch...

There as a note to you with questions without answer:
https://lkml.org/lkml/2015/6/23/466

Also I said in that thread I can prove with table of 
 1. old ethtool old driver
 2. patched ethtool old driver
 3. patched ethtool patched driver
 4. old ethtool patched driver

if you want to see difference in output on machine what I've.
 
Can we talk on some irc channel to resolve that situation,
it will be much faster, where I can find you on irc.debian.org?

Thanks in advance.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rcu: Show the real fqs_state

[Petr Mladek]

On Tue 2015-09-08 12:59:15, Paul E. McKenney wrote:
> On Mon, Sep 07, 2015 at 04:58:27PM +0200, Petr Mladek wrote:
> > On Fri 2015-09-04 16:24:22, Paul E. McKenney wrote:
> > > On Fri, Sep 04, 2015 at 02:11:29PM +0200, Petr Mladek wrote:
[...]

> > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > > index 69ab7ce2cf7b..04234936d897 100644
> > > --- a/kernel/rcu/tree.c
> > > +++ b/kernel/rcu/tree.c
> > > @@ -1949,16 +1949,15 @@ static bool rcu_gp_fqs_check_wake(struct 
> > > rcu_state *rsp, int *gfp)
> > >  /*
> > >   * Do one round of quiescent-state forcing.
> > >   */
> > > -static int rcu_gp_fqs(struct rcu_state *rsp, int fqs_state_in)
> > > +static void rcu_gp_fqs(struct rcu_state *rsp)
> > >  {
> > > - int fqs_state = fqs_state_in;
> > >   bool isidle = false;
> > >   unsigned long maxj;
> > >   struct rcu_node *rnp = rcu_get_root(rsp);
> > >  
> > >   WRITE_ONCE(rsp->gp_activity, jiffies);
> > >   rsp->n_force_qs++;
> > > - if (fqs_state == RCU_SAVE_DYNTICK) {
> > > + if (rsp->gp_state == RCU_SAVE_DYNTICK) {
> > 
> > This will never happen because rcu_gp_kthread() modifies rsp->gp_state
> > many times. The last value before calling rcu_gp_fqs() is
> > RCU_GP_DOING_FQS.
> > 
> > I think about passing this information via a separate bool.
> > 
> > [...]
> > 
> > > diff --git a/kernel/rcu/tree.h b/kernel/rcu/tree.h
> > > index d5f58e717c8b..9faad70a8246 100644
> > > --- a/kernel/rcu/tree.h
> > > +++ b/kernel/rcu/tree.h
> > > @@ -417,12 +417,11 @@ struct rcu_data {
> > >   struct rcu_state *rsp;
> > >  };
> > >  
> > > -/* Values for fqs_state field in struct rcu_state. */
> > > +/* Values for gp_state field in struct rcu_state. */
> > >  #define RCU_GP_IDLE  0   /* No grace period in progress. 
> > > */
> > 
> > This value seems to be used instead of the new RCU_GP_WAIT_INIT.
> > 
> > >  #define RCU_GP_INIT  1   /* Grace period being
> > >  #initialized. */
> > 
> > This value is unused.
> > 
> > >  #define RCU_SAVE_DYNTICK 2   /* Need to scan dyntick
> > >  #state. */
> > 
> > This one is not longer preserved when merged with the other state.
> > 
> > >  #define RCU_FORCE_QS 3   /* Need to force quiescent
> > >  #state. */
> > 
> > The meaning of this one is strange. If I get it correctly,
> > it is set after the state was forced. But the comment suggests
> > that it is before.
> > 
> > By other words, these states seems to get obsoleted by
> > 
> > /* Values for rcu_state structure's gp_flags field. */
> > #define RCU_GP_WAIT_INIT 0  /* Initial state. */
> > #define RCU_GP_WAIT_GPS  1  /* Wait for grace-period start. */
> > #define RCU_GP_DONE_GPS  2  /* Wait done for grace-period start. */
> > #define RCU_GP_WAIT_FQS  3  /* Wait for force-quiescent-state time. */
> > #define RCU_GP_DOING_FQS 4  /* Wait done for force-quiescent-state time. */
> > #define RCU_GP_CLEANUP   5  /* Grace-period cleanup started. */
> > #define RCU_GP_CLEANED   6  /* Grace-period cleanup complete. */
> > 
> > 
> > Please, find below your commit updated with my ideas:
> > 
> > + used bool save_dyntick instead of RCU_SAVE_DYNTICK
> >   and RCU_FORCE_QS states
> > + rename RCU_GP_WAIT_INIT -> RCU_GP_IDLE
> > + remove all the obsolete states
> > 
> > I am sorry if I handled "Signed-off-by" flags a wrong way. It is
> > basically your patch with few small updates from me. I am not sure
> > what is the right process in this case. Feel free to use Reviewed-by
> > instead of Signed-off-by with my name.
> > 
> > Well, I guess that this is not the final state ;-)
> 
> Good points, but perhaps an easier solution would be to have a
> "firsttime" argument to rcu_gp_fqs() that said whether or not this
> was the first call to rcu_gp_fqs() during the current grace period.
> If this is the first call, then take the "if" branch that passes
> dyntick_save_progress_counter() to force_qs_rnp(), otherwise take the
> other branch.

This seems to be the most elegant solution at the moment.

> But I am not generating the patch today, just flew across the Pacific
> yesterday.  ;-)

Please, find below the updated patch where I used the first_time
parameter.

Again, I am not sure about the commit person and Signed-off-by
tags. Many parts of the patch are yours. Feel free to update
them.


>From 7d7f2ee97a451f5cb055901a3bf22fec23a53bff Mon Sep 17 00:00:00 2001
From: "Paul E. McKenney" 
Date: Fri, 4 Sep 2015 16:24:22 -0700
Subject: [PATCH] rcu: Finish folding ->fqs_state into ->gp_state

Commit commit 4cdfc175c25c89ee ("rcu: Move quiescent-state forcing
into kthread") started the process of folding the old ->fqs_state
into ->gp_state, but did not complete it.  This situation does not
cause any malfunction, but can result in extremely confusing trace
output.  This commit completes this task of eliminating ->fqs_state
in favor of ->gp_state.

The old fqs_state had one side effect.  It was used to decide whether
to collect dyntick-idle snapshots.  For this 

Almost certainly confirmed, sun7i-a20 does not support 8 bit mmc.

[Olliver Schinagl]

Hey all,

After experimenting with a Micron eMMC chip, I made some interesting 
finds I wanted to share with you all.


For a while now, some had hopes or guessed that the A20 could have 
support for 8 bit wide bused on the SDC2. Reason for thinking this was, 
because the sun7i uses the same IP as the sun5i which does support 8 bit 
wide eMMC. The usermanual does mention 1/4/8 bit data buses and jedec 
4.3 support of the MMC spec. Unfortunately so far, it appears that the 
extra data pins have not been muxed out to the PC pads.


I used the following code to enable the extra pins on the A20:
mmc2_pins_a: mmc2@0 {
-   allwinner,pins = "PC6", "PC7", "PC8",
-"PC9", "PC10", "PC11";
+   allwinner,pins = "PC6", "PC7",
+"PC8", "PC9", "PC10", 
"PC11",
+"PC12", "PC13", "PC14", 
"PC15";


and
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand0")),/* NDQ4 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ4 */
+ SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand0")),/* NDQ5 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ5 */
+ SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand0")),/* NDQ6 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ6 */
+ SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand0")),/* NDQ7 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ7 */
+ SUNXI_FUNCTION(0x3, "mmc2")), /* D7 */

which I think should be enough? Unfortunatly after booting i get the 
following:


[0.971642] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[0.981346] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[0.987873] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[0.988704] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[0.989531] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[1.020574] mmc1: MAN_BKOPS_EN bit is not set
(This I always get for some reason btw, so if somebody has a thought 
that'd be appreciated)


[1.024234] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RD EBE !!
[1.024265] sunxi-mmc 1c11000.mmc: data error, sending stop command
[1.024276] sunxi-mmc 1c11000.mmc: send stop command failed
[1.024295] mmc1: switch to bus width 2 failed
[1.028642] mmc1: new high speed MMC card at address 0001
[1.029133] mmcblk1: mmc1:0001 P1 3.60 GiB
[1.031071] mmcblk1boot0: mmc1:0001 P1 partition 1 16.0 MiB
[1.031207] mmcblk1boot1: mmc1:0001 P1 partition 2 16.0 MiB
[1.032305]  mmcblk1: p1 p2 p3

Hence, the controller fails to enable 8 bit mode. mmc1's ios confirms 
this afterwards:

/sys/kernel/debug/mmc1# cat ios
clock:  5000 Hz
vdd:21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:1 (mmc high-speed)
signal voltage: 0 (3.30 V)

On the upside, performance is pretty good however. Using a sequential dd 
test on the whole 4GB of storage to /dev/null and reading to a 3GB file 
from /dev/zero, I'm hitting 22 MB/s read and 13 MB/s write. The 
datasheet of the eMMC chip obviously has exotic values in the 75MB/s 
range, but compared to ~12 MB/s read/write from a regular 8gb 'class 10' 
SD card, and 4-6 MB/s read/write from the regular onboard NAND flash, 
this is pretty decent.


A photograph of the soldering handy work (not by me) can be seen at the 
linux-sunxi wiki [0].


Olliver

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

[PATCH 4/4] stmmac: Fix simple style problem

[LABBE Corentin]

This patch fix the following warnings:
- braces {} should be used on all arms of this statement
- Prefer seq_puts to seq_printf
- No space is necessary after a cast
- Missing a blank line after declarations
- Please don't use multiple blank lines
- Comparison to NULL could be written
- networking block comments don't use an empty /* line
- Do not include the paragraph about writing to the Free Software

Signed-off-by: LABBE Corentin 
---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 74 +++
 1 file changed, 35 insertions(+), 39 deletions(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 5335bad..3ba95a7 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -13,10 +13,6 @@
   FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
   more details.
 
-  You should have received a copy of the GNU General Public License along with
-  this program; if not, write to the Free Software Foundation, Inc.,
-  51 Franklin St - Fifth Floor, Boston, MA 02110-1301 USA.
-
   The full GNU General Public License is included in this distribution in
   the file called "COPYING".
 
@@ -197,7 +193,7 @@ static void print_pkt(unsigned char *buf, int len)
 }
 
 /* minimum number of free TX descriptors required to wake up TX process */
-#define STMMAC_TX_THRESH(x)(x->dma_tx_size/4)
+#define STMMAC_TX_THRESH(x)(x->dma_tx_size / 4)
 
 static inline u32 stmmac_tx_avail(struct stmmac_priv *priv)
 {
@@ -207,7 +203,7 @@ static inline u32 stmmac_tx_avail(struct stmmac_priv *priv)
 /**
  * stmmac_hw_fix_mac_speed - callback for speed selection
  * @priv: driver private structure
- * Description: on some platforms (e.g. ST), some HW system configuraton
+ * Description: on some platforms (e.g. ST), some HW system configuration
  * registers have to be set according to the link speed negotiated.
  */
 static inline void stmmac_hw_fix_mac_speed(struct stmmac_priv *priv)
@@ -371,8 +367,6 @@ static void stmmac_get_tx_hwtstamp(struct stmmac_priv *priv,
shhwtstamp.hwtstamp = ns_to_ktime(ns);
/* pass tstamp to stack */
skb_tstamp_tx(skb, );
-
-   return;
 }
 
 /* stmmac_get_rx_hwtstamp - get HW RX timestamps
@@ -615,7 +609,7 @@ static int stmmac_hwtstamp_ioctl(struct net_device *dev, 
struct ifreq *ifr)
 * 2^x * y == (y << x), hence
 * 2^32 * 5000 ==> (5000 << 32)
 */
-   temp = (u64) (5000ULL << 32);
+   temp = (u64)(5000ULL << 32);
priv->default_addend = div_u64(temp, priv->clk_ptp_rate);
priv->hw->ptp->config_addend(priv->ioaddr,
 priv->default_addend);
@@ -693,7 +687,7 @@ static void stmmac_adjust_link(struct net_device *dev)
int new_state = 0;
unsigned int fc = priv->flow_ctrl, pause_time = priv->pause;
 
-   if (phydev == NULL)
+   if (!phydev)
return;
 
spin_lock_irqsave(>lock, flags);
@@ -702,7 +696,8 @@ static void stmmac_adjust_link(struct net_device *dev)
u32 ctrl = readl(priv->ioaddr + MAC_CTRL_REG);
 
/* Now we make sure that we can be in full duplex mode.
-* If not, we operate in half-duplex mode. */
+* If not, we operate in half-duplex mode.
+*/
if (phydev->duplex != priv->oldduplex) {
new_state = 1;
if (!(phydev->duplex))
@@ -728,11 +723,10 @@ static void stmmac_adjust_link(struct net_device *dev)
case 10:
if (priv->plat->has_gmac) {
ctrl |= priv->hw->link.port;
-   if (phydev->speed == SPEED_100) {
+   if (phydev->speed == SPEED_100)
ctrl |= priv->hw->link.speed;
-   } else {
+   else
ctrl &= ~(priv->hw->link.speed);
-   }
} else {
ctrl &= ~priv->hw->link.port;
}
@@ -814,6 +808,7 @@ static int stmmac_init_phy(struct net_device *dev)
char bus_id[MII_BUS_ID_SIZE];
int interface = priv->plat->interface;
int max_speed = priv->plat->max_speed;
+
priv->oldlink = 0;
priv->speed = 0;
priv->oldduplex = -1;
@@ -851,8 +846,7 @@ static int stmmac_init_phy(struct net_device *dev)
phydev->advertising &= ~(SUPPORTED_1000baseT_Half |
 SUPPORTED_1000baseT_Full);
 
-   /*
-

Re: [PATCH] arm64: kernel: Use a separate stack for irq interrupts.

[Jungseok Lee]

On Sep 9, 2015, at 1:47 AM, James Morse wrote:
> On 08/09/15 15:54, Jungseok Lee wrote:
>> On Sep 7, 2015, at 11:36 PM, James Morse wrote:
>> 
>> Hi James,
>> 
>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>> index e16351819fed..d42371f3f5a1 100644
>>> --- a/arch/arm64/kernel/entry.S
>>> +++ b/arch/arm64/kernel/entry.S
>>> @@ -190,10 +190,37 @@ tsk   .reqx28 // current thread_info
>>> * Interrupt handling.
>>> */
>>> .macro  irq_handler
>>> -   adrpx1, handle_arch_irq
>>> -   ldr x1, [x1, #:lo12:handle_arch_irq]
>>> -   mov x0, sp
>>> +   mrs x21, tpidr_el1
>>> +   adr_l   x20, irq_sp
>>> +   add x20, x20, x21
>>> +
>>> +   ldr x21, [x20]
>>> +   mov x20, sp
>>> +
>>> +   mov x0, x21
>>> +   mov x1, x20
>>> +   bl  irq_copy_thread_info
>>> +
>>> +   /* test for recursive use of irq_sp */
>>> +   cbz w0, 1f
>>> +   mrs x30, elr_el1
>>> +   mov sp, x21
>>> +
>>> +   /*
>>> +* Create a fake stack frame to bump unwind_frame() onto the original
>>> +* stack. This relies on x29 not being clobbered by kernel_entry().
>>> +*/
>>> +   pushx29, x30
>> 
>> It is the most challenging item to handle a frame pointer in this context.
>> 
>> As I mentioned previously, a stack tracer on ftrace is not supported yet.
>> How about decoupling "IRQ Stack feature" from "Stack Tracer Fix"?
> 
> Yes - I discovered today this was more complicated than I thought. I will
> need to do some more reading.
> 
> 
>>> +
>>> +1: ldr_l   x1, handle_arch_irq
>>> +   mov x0, x20
>>> blr x1
>>> +
>>> +   mov x0, x20
>>> +   mov x1, x21
>>> +   bl  irq_copy_thread_info
>>> +   mov sp, x20
>>> +
>>> .endm
>>> 
>>> .text
>>> diff --git a/arch/arm64/kernel/irq.c b/arch/arm64/kernel/irq.c
>>> index 463fa2e7e34c..10b57a006da8 100644
>>> --- a/arch/arm64/kernel/irq.c
>>> +++ b/arch/arm64/kernel/irq.c
>>> @@ -26,11 +26,14 @@
>>> #include 
>>> #include 
>>> #include 
>>> +#include 
>>> #include 
>>> #include 
>>> 
>>> unsigned long irq_err_count;
>>> 
>>> +DEFINE_PER_CPU(unsigned long, irq_sp) = 0;
>>> +
>>> int arch_show_interrupts(struct seq_file *p, int prec)
>>> {
>>> #ifdef CONFIG_SMP
>>> @@ -55,6 +58,10 @@ void __init init_IRQ(void)
>>> irqchip_init();
>>> if (!handle_arch_irq)
>>> panic("No interrupt controller found.");
>>> +
>>> +   /* Allocate an irq stack for the boot cpu */
>>> +   if (alloc_irq_stack(smp_processor_id()))
>>> +   panic("Failed to allocate irq stack for boot cpu.");
>>> }
>>> 
>>> #ifdef CONFIG_HOTPLUG_CPU
>>> @@ -117,3 +124,48 @@ void migrate_irqs(void)
>>> local_irq_restore(flags);
>>> }
>>> #endif /* CONFIG_HOTPLUG_CPU */
>>> +
>>> +/* Allocate an irq_stack for a cpu that is about to be brought up. */
>>> +int alloc_irq_stack(unsigned int cpu)
>>> +{
>>> +   struct page *irq_stack_page;
>>> +   union thread_union *irq_stack;
>>> +
>>> +   /* reuse stack allocated previously */
>>> +   if (per_cpu(irq_sp, cpu))
>>> +   return 0;
>> 
>> I'd like to avoid even this simple check since CPU hotplug could be heavily
>> used for power management.
> 
> I don't think its a problem:
> __cpu_up() contains a call to wait_for_completion_timeout() (which could
> eventually end up in the scheduler), so I don't think it could ever be on a
> 'really hot' path.
> 
> For really frequent hotplug-like power management, cpu_suspend() makes use
> of firmware support to power-off cores - from what I can see it doesn't use
> __cpu_up().

In case of some platforms, CPU hotplug is triggered via sysfs for power 
management
based on user data. What is advantage of putting stack allocation into this 
path?

IRQ stack allocation is an critical one-shot operation. So, there would be no 
issue
to give this work to a booting core. 

>>> +
>>> +   irq_stack_page = alloc_kmem_pages(THREADINFO_GFP, THREAD_SIZE_ORDER);
>>> +   if (!irq_stack_page) {
>>> +   pr_crit("CPU%u: failed to allocate irq stack for cpu %u\n",
>>> +   smp_processor_id(), cpu);
>>> +   return -ENOMEM;
>>> +   }
>>> +   irq_stack = page_address(irq_stack_page);

I forgot leaving a comment here. How about using __get_free_pages? It returns an
address instead of page. 

>>> +
>>> +   per_cpu(irq_sp, cpu) = (unsigned long)irq_stack->stack
>>> +  + THREAD_START_SP;
>>> +
>>> +   return 0;
>>> +}
>>> +
>>> +/*
>>> + * Copy struct thread_info between two stacks, and update current->stack.
>>> + * This is used when moving to the irq exception stack.
>>> + * Changing current->stack is necessary so that non-arch thread_info 
>>> writers
>>> + * don't use the new thread_info->task->stack to find the old thread_info 
>>> when
>>> + * setting flags like TIF_NEED_RESCHED...
>>> + */
>>> +asmlinkage int irq_copy_thread_info(unsigned long dst_sp, unsigned long 
>>> src_sp)
>>> +{
>>> +   struct thread_info *src = get_thread_info(src_sp);
>>> +   struct 

Re: [PATCH v2 2/3] efi: Change abbreviation of EFI_MEMORY_RUNTIME from "RUN" to "RT"

[Matt Fleming]

On Thu, 27 Aug, at 02:11:29AM, Taku Izumi wrote:
> Now efi_md_typeattr_format() outputs "RUN" if passed EFI memory
> descriptor has EFI_MEMORY_RUNTIME attribute. But "RT" is preferer
> because it is shorter and clearer.
> 
> This patch changes abbreviation of EFI_MEMORY_RUNTIME from "RUN"
> to "RT".
> 
> Suggested-by: Ard Biesheuvel 
> Signed-off-by: Taku Izumi 
> ---
>  drivers/firmware/efi/efi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
> index 8124078..25b6477 100644
> --- a/drivers/firmware/efi/efi.c
> +++ b/drivers/firmware/efi/efi.c
> @@ -594,8 +594,8 @@ char * __init efi_md_typeattr_format(char *buf, size_t 
> size,
>   snprintf(pos, size, "|attr=0x%016llx]",
>(unsigned long long)attr);
>   else
> - snprintf(pos, size, "|%3s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
> -  attr & EFI_MEMORY_RUNTIME ? "RUN" : "",
> + snprintf(pos, size, "|%2s|%2s|%2s|%2s|%2s|%3s|%2s|%2s|%2s|%2s]",
> +  attr & EFI_MEMORY_RUNTIME ? "RT" : "",
>attr & EFI_MEMORY_MORE_RELIABLE ? "MR" : "",
>attr & EFI_MEMORY_XP  ? "XP"  : "",
>attr & EFI_MEMORY_RP  ? "RP"  : "",

I know that Ard suggested this change but I don't think I should apply
this and the reason is that developers, particularly distro
developers, come to rely on the output we print for debugging
purposes.

They don't necessarily monitor all the patches getting merged upstream
closely enough to realise that it impacts their debugging strategy. So
when they notice that the output has gone from "RUN" to "RT" they're
naturally going to ask what the difference is... and the answer is "it
looks prettier". That's not a good enough reason.

Obviously if we're printing something that's completely incorrect, or
we can improve the message considerably, then yes, it makes sense to
change it - but that's not the case here.

Thanks for the patch, but sorry, I'm not going to apply this one.

-- 
Matt Fleming, 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/

[PATCH v12 10/21] x86/amd: Set ELF function type for vide()

[Josh Poimboeuf]

vide() is a callable function, but is missing the ELF function type,
which confuses tools like stacktool.

Properly annotate it to be a callable function.  The generated code is
unchanged.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/kernel/cpu/amd.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 4a70fc6..c010de5 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -75,7 +75,10 @@ static inline int wrmsrl_amd_safe(unsigned msr, unsigned 
long long val)
  */
 
 extern __visible void vide(void);
-__asm__(".globl vide\n\t.align 4\nvide: ret");
+__asm__(".globl vide\n"
+   ".type vide, @function\n"
+   ".align 4\n"
+   "vide: ret\n");
 
 static void init_amd_k5(struct cpuinfo_x86 *c)
 {
-- 
2.4.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 linux-next v6 5/8] Documentation: mtd: add a DT property to set the number of dummy cycles

[Cyrille Pitchen]

Depending on the SPI clock frequency, the Fast Read op code and the
Single/Dual Data Rate mode, the number of dummy cycles can be tuned to
improve transfer speed.
The actual number of dummy cycles is specific for each memory model and is
provided by the manufacturer thanks to the memory datasheet.

Signed-off-by: Cyrille Pitchen 
---
 Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt 
b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
index 2bee68103b01..4387567d8024 100644
--- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
+++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
@@ -19,6 +19,11 @@ Optional properties:
all chips and support for it can not be detected at runtime.
Refer to your chips' datasheet to check if this is supported
by your chip.
+- m25p,num-dummy-cycles : Set the number of dummy cycles for Fast Read 
commands.
+  Depending on the manufacturer additional dedicated
+  commands are sent to the flash memory so the
+  controller and the memory can agree on the number of
+  dummy cycles to use.
 
 Example:
 
@@ -29,4 +34,5 @@ Example:
reg = <0>;
spi-max-frequency = <4000>;
m25p,fast-read;
+   m25p,num-dummy-cycles = <8>;
};
-- 
1.8.2.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 v12 14/21] x86/asm/crypto: Move .Lbswap_mask data to .rodata section

[Josh Poimboeuf]

stacktool reports the following warning:

  stacktool: arch/x86/crypto/aesni-intel_asm.o: _aesni_inc_init(): can't find 
starting instruction

stacktool gets confused when it tries to disassemble the following data
in the .text section:

  .Lbswap_mask:
  .byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0

Move it to .rodata which is a more appropriate section for read-only
data.

Signed-off-by: Josh Poimboeuf 
Cc: Herbert Xu 
Cc: "David S. Miller" 
---
 arch/x86/crypto/aesni-intel_asm.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 289ef12..18f0ced 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -2553,9 +2553,11 @@ ENTRY(aesni_cbc_dec)
 ENDPROC(aesni_cbc_dec)
 
 #ifdef __x86_64__
+.pushsection .rodata
 .align 16
 .Lbswap_mask:
.byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
+.popsection
 
 /*
  * _aesni_inc_init:internal ABI
-- 
2.4.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 v12 06/21] x86/stacktool: Add ignore macros

[Josh Poimboeuf]

Add new stacktool ignore macros: STACKTOOL_IGNORE_INSN and
STACKTOOL_IGNORE_FUNC.  These can be used to tell stacktool to skip
validation of an instruction or a function, respectively.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/include/asm/stacktool.h | 45 
 arch/x86/kernel/vmlinux.lds.S|  5 -
 include/linux/stacktool.h| 29 ++
 3 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/include/asm/stacktool.h
 create mode 100644 include/linux/stacktool.h

diff --git a/arch/x86/include/asm/stacktool.h b/arch/x86/include/asm/stacktool.h
new file mode 100644
index 000..250a37e
--- /dev/null
+++ b/arch/x86/include/asm/stacktool.h
@@ -0,0 +1,45 @@
+#ifndef _ASM_X86_STACKTOOL_H
+#define _ASM_X86_STACKTOOL_H
+
+#include 
+
+#ifdef __ASSEMBLY__
+
+/*
+ * This asm macro tells stacktool to ignore the instruction immediately after
+ * the macro when doing stack metadata validation.  It should only be used in
+ * special cases where you're 100% sure it won't affect the reliability of
+ * frame pointers and kernel stack traces.
+ *
+ * For more information, see 
tools/stacktool/Documentation/stack-validation.txt.
+ */
+.macro STACKTOOL_IGNORE_INSN
+#ifdef CONFIG_STACK_VALIDATION
+   .Lstacktool_ignore_\@:
+   .pushsection __stacktool_ignore_insn, "a"
+   _ASM_ALIGN
+   .long .Lstacktool_ignore_\@ - .
+   .popsection
+#endif
+.endm
+
+#else /* !__ASSEMBLY__ */
+
+#ifdef CONFIG_STACK_VALIDATION
+
+#define STACKTOOL_IGNORE_INSN  \
+   "1:\n"  \
+   ".pushsection __stacktool_ignore_insn, \"a\"\n" \
+   _ASM_ALIGN "\n" \
+   ".long 1b - .\n"\
+   ".popsection\n"
+
+#else /* !CONFIG_STACK_VALIDATION */
+
+#define STACKTOOL_IGNORE_INSN ""
+
+#endif /* CONFIG_STACK_VALIDATION */
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* _ASM_X86_STACKTOOL_H */
diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 00bf300..4891aeb 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -332,7 +332,10 @@ SECTIONS
 
/* Sections to be discarded */
DISCARDS
-   /DISCARD/ : { *(.eh_frame) }
+   /DISCARD/ : {
+   *(.eh_frame)
+   *(__stacktool_ignore_*)
+   }
 }
 
 
diff --git a/include/linux/stacktool.h b/include/linux/stacktool.h
new file mode 100644
index 000..c1e151b
--- /dev/null
+++ b/include/linux/stacktool.h
@@ -0,0 +1,29 @@
+#ifndef _LINUX_STACKTOOL_H
+#define _LINUX_STACKTOOL_H
+
+#include 
+
+#ifndef __ASSEMBLY__
+
+#ifdef CONFIG_STACK_VALIDATION
+/*
+ * This C macro tells stacktool to ignore the function when doing stack
+ * metadata validation.  It should only be used in special cases where you're
+ * 100% sure it won't affect the reliability of frame pointers and kernel stack
+ * traces.
+ *
+ * For more information, see 
tools/stacktool/Documentation/stack-validation.txt.
+ */
+#define STACKTOOL_IGNORE_FUNC(_func) \
+   static void __used __section(__stacktool_ignore_func) \
+   *__stacktool_ignore_func_##_func = _func
+
+#else /* !CONFIG_STACK_VALIDATION */
+
+#define STACKTOOL_IGNORE_FUNC(_func)
+
+#endif /* CONFIG_STACK_VALIDATION */
+
+#endif /* !__ASSEMBLY__ */
+
+#endif /* _LINUX_STACKTOOL_H */
-- 
2.4.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 v12 08/21] x86/paravirt: Add stack frame dependency to PVOP inline asm calls

[Josh Poimboeuf]

If a PVOP call macro is inlined at the beginning of a function, gcc can
insert the call instruction before setting up a stack frame, which
breaks frame pointer convention if CONFIG_FRAME_POINTER is enabled and
can result in a bad stack trace.

Force a stack frame to be created if CONFIG_FRAME_POINTER is enabled by
listing the stack pointer as an output operand for the PVOP inline asm
statements.

Signed-off-by: Josh Poimboeuf 
Cc: Jeremy Fitzhardinge 
Cc: Chris Wright 
Cc: Alok Kataria 
Cc: Rusty Russell 
---
 arch/x86/include/asm/paravirt_types.h | 18 ++
 1 file changed, 10 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index ce029e4..1812294 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -497,8 +497,9 @@ int paravirt_disable_iospace(void);
  * makes sure the incoming and outgoing types are always correct.
  */
 #ifdef CONFIG_X86_32
-#define PVOP_VCALL_ARGS\
-   unsigned long __eax = __eax, __edx = __edx, __ecx = __ecx
+#define PVOP_VCALL_ARGS
\
+   unsigned long __eax = __eax, __edx = __edx, __ecx = __ecx;  \
+   register void *__sp asm("esp")
 #define PVOP_CALL_ARGS PVOP_VCALL_ARGS
 
 #define PVOP_CALL_ARG1(x)  "a" ((unsigned long)(x))
@@ -516,9 +517,10 @@ int paravirt_disable_iospace(void);
 #define VEXTRA_CLOBBERS
 #else  /* CONFIG_X86_64 */
 /* [re]ax isn't an arg, but the return val */
-#define PVOP_VCALL_ARGS\
-   unsigned long __edi = __edi, __esi = __esi, \
-   __edx = __edx, __ecx = __ecx, __eax = __eax
+#define PVOP_VCALL_ARGS\
+   unsigned long __edi = __edi, __esi = __esi, \
+   __edx = __edx, __ecx = __ecx, __eax = __eax;\
+   register void *__sp asm("rsp")
 #define PVOP_CALL_ARGS PVOP_VCALL_ARGS
 
 #define PVOP_CALL_ARG1(x)  "D" ((unsigned long)(x))
@@ -557,7 +559,7 @@ int paravirt_disable_iospace(void);
asm volatile(pre\
 paravirt_alt(PARAVIRT_CALL)\
 post   \
-: call_clbr\
+: "+r" (__sp), call_clbr   \
 : paravirt_type(op),   \
   paravirt_clobber(clbr),  \
   ##__VA_ARGS__\
@@ -567,7 +569,7 @@ int paravirt_disable_iospace(void);
asm volatile(pre\
 paravirt_alt(PARAVIRT_CALL)\
 post   \
-: call_clbr\
+: "+r" (__sp), call_clbr   \
 : paravirt_type(op),   \
   paravirt_clobber(clbr),  \
   ##__VA_ARGS__\
@@ -594,7 +596,7 @@ int paravirt_disable_iospace(void);
asm volatile(pre\
 paravirt_alt(PARAVIRT_CALL)\
 post   \
-: call_clbr\
+: "+r" (__sp), call_clbr   \
 : paravirt_type(op),   \
   paravirt_clobber(clbr),  \
   ##__VA_ARGS__\
-- 
2.4.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 v12 13/21] x86/asm/crypto: Create stack frames in aesni-intel_asm.S

[Josh Poimboeuf]

aesni-intel_asm.S has several callable non-leaf functions which don't
honor CONFIG_FRAME_POINTER, which can result in bad stack traces.

Create stack frames for them when CONFIG_FRAME_POINTER is enabled.

Signed-off-by: Josh Poimboeuf 
Cc: Herbert Xu 
Cc: "David S. Miller" 
---
 arch/x86/crypto/aesni-intel_asm.S | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/x86/crypto/aesni-intel_asm.S 
b/arch/x86/crypto/aesni-intel_asm.S
index 6bd2c6c..289ef12 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -31,6 +31,7 @@
 
 #include 
 #include 
+#include 
 
 /*
  * The following macros are used to move an (un)aligned 16 byte value to/from
@@ -1800,6 +1801,7 @@ ENDPROC(_key_expansion_256b)
  *   unsigned int key_len)
  */
 ENTRY(aesni_set_key)
+   FRAME_BEGIN
 #ifndef __x86_64__
pushl KEYP
movl 8(%esp), KEYP  # ctx
@@ -1905,6 +1907,7 @@ ENTRY(aesni_set_key)
 #ifndef __x86_64__
popl KEYP
 #endif
+   FRAME_END
ret
 ENDPROC(aesni_set_key)
 
@@ -1912,6 +1915,7 @@ ENDPROC(aesni_set_key)
  * void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
  */
 ENTRY(aesni_enc)
+   FRAME_BEGIN
 #ifndef __x86_64__
pushl KEYP
pushl KLEN
@@ -1927,6 +1931,7 @@ ENTRY(aesni_enc)
popl KLEN
popl KEYP
 #endif
+   FRAME_END
ret
 ENDPROC(aesni_enc)
 
@@ -2101,6 +2106,7 @@ ENDPROC(_aesni_enc4)
  * void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
  */
 ENTRY(aesni_dec)
+   FRAME_BEGIN
 #ifndef __x86_64__
pushl KEYP
pushl KLEN
@@ -2117,6 +2123,7 @@ ENTRY(aesni_dec)
popl KLEN
popl KEYP
 #endif
+   FRAME_END
ret
 ENDPROC(aesni_dec)
 
@@ -2292,6 +2299,7 @@ ENDPROC(_aesni_dec4)
  *   size_t len)
  */
 ENTRY(aesni_ecb_enc)
+   FRAME_BEGIN
 #ifndef __x86_64__
pushl LEN
pushl KEYP
@@ -2342,6 +2350,7 @@ ENTRY(aesni_ecb_enc)
popl KEYP
popl LEN
 #endif
+   FRAME_END
ret
 ENDPROC(aesni_ecb_enc)
 
@@ -2350,6 +2359,7 @@ ENDPROC(aesni_ecb_enc)
  *   size_t len);
  */
 ENTRY(aesni_ecb_dec)
+   FRAME_BEGIN
 #ifndef __x86_64__
pushl LEN
pushl KEYP
@@ -2401,6 +2411,7 @@ ENTRY(aesni_ecb_dec)
popl KEYP
popl LEN
 #endif
+   FRAME_END
ret
 ENDPROC(aesni_ecb_dec)
 
@@ -2409,6 +2420,7 @@ ENDPROC(aesni_ecb_dec)
  *   size_t len, u8 *iv)
  */
 ENTRY(aesni_cbc_enc)
+   FRAME_BEGIN
 #ifndef __x86_64__
pushl IVP
pushl LEN
@@ -2443,6 +2455,7 @@ ENTRY(aesni_cbc_enc)
popl LEN
popl IVP
 #endif
+   FRAME_END
ret
 ENDPROC(aesni_cbc_enc)
 
@@ -2451,6 +2464,7 @@ ENDPROC(aesni_cbc_enc)
  *   size_t len, u8 *iv)
  */
 ENTRY(aesni_cbc_dec)
+   FRAME_BEGIN
 #ifndef __x86_64__
pushl IVP
pushl LEN
@@ -2534,6 +2548,7 @@ ENTRY(aesni_cbc_dec)
popl LEN
popl IVP
 #endif
+   FRAME_END
ret
 ENDPROC(aesni_cbc_dec)
 
@@ -2598,6 +2613,7 @@ ENDPROC(_aesni_inc)
  *   size_t len, u8 *iv)
  */
 ENTRY(aesni_ctr_enc)
+   FRAME_BEGIN
cmp $16, LEN
jb .Lctr_enc_just_ret
mov 480(KEYP), KLEN
@@ -2651,6 +2667,7 @@ ENTRY(aesni_ctr_enc)
 .Lctr_enc_ret:
movups IV, (IVP)
 .Lctr_enc_just_ret:
+   FRAME_END
ret
 ENDPROC(aesni_ctr_enc)
 
@@ -2677,6 +2694,7 @@ ENDPROC(aesni_ctr_enc)
  *  bool enc, u8 *iv)
  */
 ENTRY(aesni_xts_crypt8)
+   FRAME_BEGIN
cmpb $0, %cl
movl $0, %ecx
movl $240, %r10d
@@ -2777,6 +2795,7 @@ ENTRY(aesni_xts_crypt8)
pxor INC, STATE4
movdqu STATE4, 0x70(OUTP)
 
+   FRAME_END
ret
 ENDPROC(aesni_xts_crypt8)
 
-- 
2.4.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 v12 12/21] x86/xen: Add xen_cpuid() and xen_setup_gdt() to stacktool whitelists

[Josh Poimboeuf]

stacktool reports the following false positive warnings:

  stacktool: arch/x86/xen/enlighten.o: xen_cpuid()+0x41: can't find jump dest 
instruction at .text+0x108
  stacktool: arch/x86/xen/enlighten.o: xen_setup_gdt.constprop.23()+0x2e: 
kernel entry/exit from callable instruction

The first warning is due to xen_cpuid()'s use of XEN_EMULATE_PREFIX to
insert some fake instructions which stacktool doesn't know how to
decode.

The second warning is due to xen_setup_gdt()'s use of an lret
instruction, which stacktool normally doesn't allow in callable
functions.  But this seems to be a valid use of the instruction.

Add both functions to the stacktool whitelist.

Signed-off-by: Josh Poimboeuf 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
---
 arch/x86/xen/enlighten.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index d9cfa45..6cc682d 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -345,8 +346,8 @@ static void xen_cpuid(unsigned int *ax, unsigned int *bx,
*cx &= maskecx;
*cx |= setecx;
*dx &= maskedx;
-
 }
+STACKTOOL_IGNORE_FUNC(xen_cpuid);
 
 static bool __init xen_check_mwait(void)
 {
@@ -1443,6 +1444,7 @@ static void __ref xen_setup_gdt(int cpu)
pv_cpu_ops.write_gdt_entry = xen_write_gdt_entry;
pv_cpu_ops.load_gdt = xen_load_gdt;
 }
+STACKTOOL_IGNORE_FUNC(xen_setup_gdt);
 
 #ifdef CONFIG_XEN_PVH
 /*
-- 
2.4.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 v12 09/21] x86/paravirt: Create a stack frame in PV_CALLEE_SAVE_REGS_THUNK

[Josh Poimboeuf]

A function created with the PV_CALLEE_SAVE_REGS_THUNK macro doesn't set
up a new stack frame before the call instruction, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace.  Also, the thunk functions aren't annotated as ELF
callable functions.

Create a stack frame when CONFIG_FRAME_POINTER is enabled and add the
ELF function type.

Signed-off-by: Josh Poimboeuf 
Cc: Jeremy Fitzhardinge 
Cc: Chris Wright 
Cc: Alok Kataria 
Cc: Rusty Russell 
---
 arch/x86/include/asm/paravirt.h | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/paravirt.h b/arch/x86/include/asm/paravirt.h
index 10d0596..23a382b 100644
--- a/arch/x86/include/asm/paravirt.h
+++ b/arch/x86/include/asm/paravirt.h
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static inline int paravirt_enabled(void)
 {
@@ -776,15 +777,19 @@ static __always_inline void __ticket_unlock_kick(struct 
arch_spinlock *lock,
  * call. The return value in rax/eax will not be saved, even for void
  * functions.
  */
+#define PV_THUNK_NAME(func) "__raw_callee_save_" #func
 #define PV_CALLEE_SAVE_REGS_THUNK(func)
\
extern typeof(func) __raw_callee_save_##func;   \
\
asm(".pushsection .text;"   \
-   ".globl __raw_callee_save_" #func " ; " \
-   "__raw_callee_save_" #func ": " \
+   ".globl " PV_THUNK_NAME(func) ";"   \
+   ".type " PV_THUNK_NAME(func) ", @function;" \
+   PV_THUNK_NAME(func) ":" \
+   FRAME_BEGIN \
PV_SAVE_ALL_CALLER_REGS \
"call " #func ";"   \
PV_RESTORE_ALL_CALLER_REGS  \
+   FRAME_END   \
"ret;"  \
".popsection")
 
-- 
2.4.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 v12 07/21] x86/xen: Add stack frame dependency to hypercall inline asm calls

[Josh Poimboeuf]

If a hypercall is inlined at the beginning of a function, gcc can insert
the call instruction before setting up a stack frame, which breaks frame
pointer convention if CONFIG_FRAME_POINTER is enabled and can result in
a bad stack trace.

Force a stack frame to be created if CONFIG_FRAME_POINTER is enabled by
listing the stack pointer as an output operand for the hypercall inline
asm statements.

Signed-off-by: Josh Poimboeuf 
Cc: Konrad Rzeszutek Wilk 
Cc: Boris Ostrovsky 
Cc: David Vrabel 
---
 arch/x86/include/asm/xen/hypercall.h | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/xen/hypercall.h 
b/arch/x86/include/asm/xen/hypercall.h
index ca08a27..4488fbc 100644
--- a/arch/x86/include/asm/xen/hypercall.h
+++ b/arch/x86/include/asm/xen/hypercall.h
@@ -110,9 +110,10 @@ extern struct { char _entry[32]; } hypercall_page[];
register unsigned long __arg2 asm(__HYPERCALL_ARG2REG) = __arg2; \
register unsigned long __arg3 asm(__HYPERCALL_ARG3REG) = __arg3; \
register unsigned long __arg4 asm(__HYPERCALL_ARG4REG) = __arg4; \
-   register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5;
+   register unsigned long __arg5 asm(__HYPERCALL_ARG5REG) = __arg5; \
+   register void *__sp asm(_ASM_SP);
 
-#define __HYPERCALL_0PARAM "=r" (__res)
+#define __HYPERCALL_0PARAM "=r" (__res), "+r" (__sp)
 #define __HYPERCALL_1PARAM __HYPERCALL_0PARAM, "+r" (__arg1)
 #define __HYPERCALL_2PARAM __HYPERCALL_1PARAM, "+r" (__arg2)
 #define __HYPERCALL_3PARAM __HYPERCALL_2PARAM, "+r" (__arg3)
-- 
2.4.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 v12 11/21] x86/reboot: Add ljmp instructions to stacktool whitelist

[Josh Poimboeuf]

stacktool reports a false positive warning for the ljmp instruction in
machine_real_restart().  Normally, ljmp isn't allowed in a function, but
this is a special case where it's jumping into real mode.

Add the jumps to a whitelist which tells stacktool to ignore them.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/kernel/reboot.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 86db4bc..320219d 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -9,6 +9,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -97,11 +98,13 @@ void __noreturn machine_real_restart(unsigned int type)
 
/* Jump to the identity-mapped low memory code */
 #ifdef CONFIG_X86_32
-   asm volatile("jmpl *%0" : :
+   asm volatile(STACKTOOL_IGNORE_INSN
+"jmpl *%0;" : :
 "rm" (real_mode_header->machine_real_restart_asm),
 "a" (type));
 #else
-   asm volatile("ljmpl *%0" : :
+   asm volatile(STACKTOOL_IGNORE_INSN
+"ljmpl *%0" : :
 "m" (real_mode_header->machine_real_restart_asm),
 "D" (type));
 #endif
-- 
2.4.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 v12 05/21] x86/stacktool: Add file and directory ignores

[Josh Poimboeuf]

Tell stacktool to skip validation of the following code:

- boot image
- vdso image
- kexec purgatory
- realmode
- efi libstub
- scripts/mod

They all run outside the kernel's normal mode of operation and they
don't affect runtime kernel stack traces, so they're free to skirt the
stacktool rules.

Signed-off-by: Josh Poimboeuf 
---
 arch/x86/boot/Makefile| 3 ++-
 arch/x86/boot/compressed/Makefile | 3 ++-
 arch/x86/entry/vdso/Makefile  | 5 -
 arch/x86/purgatory/Makefile   | 2 ++
 arch/x86/realmode/Makefile| 4 +++-
 arch/x86/realmode/rm/Makefile | 3 ++-
 drivers/firmware/efi/libstub/Makefile | 1 +
 scripts/mod/Makefile  | 2 ++
 8 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/arch/x86/boot/Makefile b/arch/x86/boot/Makefile
index 0d553e5..fe96b2f 100644
--- a/arch/x86/boot/Makefile
+++ b/arch/x86/boot/Makefile
@@ -14,7 +14,8 @@
 # Set it to -DSVGA_MODE=NORMAL_VGA if you just want the EGA/VGA mode.
 # The number is the same as you would ordinarily press at bootup.
 
-KASAN_SANITIZE := n
+KASAN_SANITIZE := n
+STACKTOOL  := n
 
 SVGA_MODE  := -DSVGA_MODE=NORMAL_VGA
 
diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 0a291cd..8cea814 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -16,7 +16,8 @@
 #  (see scripts/Makefile.lib size_append)
 #  compressed vmlinux.bin.all + u32 size of vmlinux.bin.all
 
-KASAN_SANITIZE := n
+KASAN_SANITIZE := n
+STACKTOOL  := n
 
 targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma 
\
vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index a3d0767..8095694 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -3,7 +3,9 @@
 #
 
 KBUILD_CFLAGS += $(DISABLE_LTO)
-KASAN_SANITIZE := n
+
+KASAN_SANITIZE := n
+STACKTOOL  := n
 
 VDSO64-$(CONFIG_X86_64):= y
 VDSOX32-$(CONFIG_X86_X32_ABI)  := y
@@ -15,6 +17,7 @@ vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o
 
 # files to link into kernel
 obj-y  += vma.o
+STACKTOOL_vma.o:= y
 
 # vDSO images to build
 vdso_img-$(VDSO64-y)   += 64
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 2c835e3..30d7d58 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -1,3 +1,5 @@
+STACKTOOL := n
+
 purgatory-y := purgatory.o stack.o setup-x86_$(BITS).o sha256.o entry64.o 
string.o
 
 targets += $(purgatory-y)
diff --git a/arch/x86/realmode/Makefile b/arch/x86/realmode/Makefile
index e02c2c6..0c24689 100644
--- a/arch/x86/realmode/Makefile
+++ b/arch/x86/realmode/Makefile
@@ -6,7 +6,9 @@
 # for more details.
 #
 #
-KASAN_SANITIZE := n
+KASAN_SANITIZE := n
+STACKTOOL  := n
+
 subdir- := rm
 
 obj-y += init.o
diff --git a/arch/x86/realmode/rm/Makefile b/arch/x86/realmode/rm/Makefile
index 2730d77..1da2e5b 100644
--- a/arch/x86/realmode/rm/Makefile
+++ b/arch/x86/realmode/rm/Makefile
@@ -6,7 +6,8 @@
 # for more details.
 #
 #
-KASAN_SANITIZE := n
+KASAN_SANITIZE := n
+STACKTOOL  := n
 
 always := realmode.bin realmode.relocs
 
diff --git a/drivers/firmware/efi/libstub/Makefile 
b/drivers/firmware/efi/libstub/Makefile
index 816dbe9..a612cdb 100644
--- a/drivers/firmware/efi/libstub/Makefile
+++ b/drivers/firmware/efi/libstub/Makefile
@@ -20,6 +20,7 @@ KBUILD_CFLAGS := $(cflags-y) \
 
 GCOV_PROFILE   := n
 KASAN_SANITIZE := n
+STACKTOOL  := n
 
 lib-y  := efi-stub-helper.o
 lib-$(CONFIG_EFI_ARMSTUB)  += arm-stub.o fdt.o
diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile
index c11212f..496184d 100644
--- a/scripts/mod/Makefile
+++ b/scripts/mod/Makefile
@@ -1,3 +1,5 @@
+STACKTOOL  := n
+
 hostprogs-y:= modpost mk_elfconfig
 always := $(hostprogs-y) empty.o
 
-- 
2.4.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 v12 15/21] x86/asm/crypto: Move jump_table to .rodata section

[Josh Poimboeuf]

stacktool reports the following warning:

  stacktool: arch/x86/crypto/crc32c-pcl-intel-asm_64.o: crc_pcl()+0x11dd: can't 
decode instruction

It gets confused when trying to decode jump_table data.  Move jump_table
to the .rodata section which is a more appropriate home for read-only
data.

Signed-off-by: Josh Poimboeuf 
Cc: Herbert Xu 
Cc: "David S. Miller" 
---
 arch/x86/crypto/crc32c-pcl-intel-asm_64.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S 
b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S
index 225be06..dc05f01 100644
--- a/arch/x86/crypto/crc32c-pcl-intel-asm_64.S
+++ b/arch/x86/crypto/crc32c-pcl-intel-asm_64.S
@@ -170,8 +170,8 @@ continue_block:
## branch into array
lea jump_table(%rip), bufp
movzxw  (bufp, %rax, 2), len
-   offset=crc_array-jump_table
-   lea offset(bufp, len, 1), bufp
+   lea crc_array(%rip), bufp
+   lea (bufp, len, 1), bufp
jmp *bufp
 

@@ -310,7 +310,9 @@ do_return:
popq%rdi
popq%rbx
 ret
+ENDPROC(crc_pcl)
 
+.section   .rodata, "a", %progbits
 
 ## jump tableTable is 129 entries x 2 bytes each
 
@@ -324,13 +326,11 @@ JMPTBL_ENTRY %i
i=i+1
 .endr
 
-ENDPROC(crc_pcl)
 

## PCLMULQDQ tables
## Table is 128 entries x 2 words (8 bytes) each

-.section   .rotata, "a", %progbits
 .align 8
 K_table:
.long 0x493c7d27, 0x0001
-- 
2.4.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 v4 2/2] dt: power: st: Provide bindings for ST's OPPs

[Lee Jones]

On Wed, 09 Sep 2015, Viresh Kumar wrote:
> On 09-09-15, 08:59, Lee Jones wrote:
> > Thanks for doing this Viresh.  I appreciate your efforts.
> 
> I wanted to get this sorted out, before we meet face to face :)
> 
> > > -8<-
> > > From: Viresh Kumar 
> > > Date: Wed, 9 Sep 2015 11:47:37 +0530
> > > Subject: [PATCH] PM / OPP: Add "opp-cuts" and "opp-supply-version" 
> > > bindings
> > > 
> > > For many platforms it is unknown until runtime, about which OPPs should
> > > be used or if used what should be voltage range for the supplies for a
> > > particular frequency. And this mostly depends on the version of the
> > > device or hardware, for which the OPPs are getting used.
> > > 
> > > This patch adds two new OPP bindings to get this solved.
> > > 
> > > 1. "opp-cuts": The purpose of this binding is to allow the platform to
> > >identify the valid OPPs based on the different levels of versions
> > >with which the hardware is identified.
> > 
> > "cuts" is a very specific name for such a generic property.
> 
> I agree... I wasn't concerned much about naming on the first try and
> so just wrote it quickly enough to get an overall idea ..
> 
> > You are using the format I suggested weeks ago, which I like.
> 
> I must have missed that :(
> 
> > So how about:
> > 
> > opp-hw-version:
> > User defined array containing a hierarchy of version numbers.
> > 
> > E.g: Taking kernel version v2.6.19 for instance:
> > <2, 6, 19>;
> > 
> > E.g: Representing Major 2 Minor 0, Cuts ALL and Substrate 5:
> > <2, 0, 0x, 5>;
> 
> At least what I suggested in my attempt here is a bit different than
> what you might be thinking. For example, consider a case with single
> level of hierarchy, say cuts. And that the SoC has got 10 different
> cuts, and we name them 0-9. So, the values I was looking to fill to
> the opp-hw-version field is like: (1 << version_num). So, if an OPP
> supports version 2, 5 and 7, the value will be 0x00A4. i.e. with
> the respective bit positions set. And by this way only 0x can
> mean all versions ..

Okay, I see what you mean.  Sound fine, although only allows up to 31
versions.  Not an issue for us I don't think, but could be for other
vendors.  Taking a recent example, the kernel recently went up to
v2.6.39 and some of the stable releases have gone up to v3.4.108.
Depends what you wish to support.

> > > 2. "opp-supply-name": The purpose of this binding is to allow the
> > >platform to select the voltage range of the power supplies, for a
> > >valid OPP.
> > 
> > Did you mean 'opp-supply-version', like in the example below?
> 
> Urg. Yeah.
> 
> > I suggest '-name' would be better than '-version'.
> 
> So, its not name of the supply really, but a virtual name given to the
> voltage-range which we need to pick based on the hardware version.

We usually call these 'names'; reg-names, clock-names, pinctrl-names,
phy-names, dma-names, etc.

> > I guess this is a Qcom specific feature.  I'll let Stephen comment.
> 
> No. So, my plan was to use this instead of the st,avs & pcode thing
> you have got in your bindings. So, instead of 'slow' and 'fast' from
> my example, it will have the corresponding strings for pcode numbers.
> And at runtime the platform will pass a string to the OPP library, to
> activate/add OPPs only for a specific opp-supply-version.

So you're using it to index into a 2 dimensional array of opp-hz's.

Eek!

> Maybe we can name it 'opp-supply-range-name'..
> 
> > > Both of these can be used together, as well as independently.
> > > 
> > > Signed-off-by: Viresh Kumar 
> > > ---
> > >  Documentation/devicetree/bindings/opp/opp.txt | 90 
> > > +++
> > >  1 file changed, 90 insertions(+)
> > > 
> > > diff --git a/Documentation/devicetree/bindings/opp/opp.txt 
> > > b/Documentation/devicetree/bindings/opp/opp.txt
> > > index c56a6b1a44ef..def75f7a3614 100644
> > > --- a/Documentation/devicetree/bindings/opp/opp.txt
> > > +++ b/Documentation/devicetree/bindings/opp/opp.txt
> > > @@ -98,6 +98,13 @@ This describes the OPPs belonging to a device. This 
> > > node can have following
> > >information. But for multiple power-supplies, this must be set to pass
> > >triplet style values.
> > >  
> > > +- opp-supply-version: One or more strings describing version of the 
> > > supplies on
> > 
> > What kind of supplies?  Supplies to me means regulator supplies, which
> > I fear would be too easily confused with the regulator '*-supply'
> > property.
> 
> Yeah, its more like opp-supply-range-names ..
> 
> > > +  the platform. This is useful for the cases, where the platform wants 
> > > to select
> > > +  the voltage range for supplies at runtime, based on the specific 
> > > version of
> > > +  the hardware. There should be one entry in opp-microvolt array, for 
> > > each
> > > +  string present here. OPPs for the device 

Re: [PATCH v7 0/3] KVM: Dynamic Halt-Polling

[Christian Borntraeger]

Am 03.09.2015 um 16:07 schrieb Wanpeng Li:
> v6 -> v7:
>  * explicit signal (set a bool)
>  * fix the tracepoint 
> 
> v5 -> v6:
>  * fix wait_ns and poll_ns 
> 
> v4 -> v5:
>  * set base case 10us and max poll time 500us
>  * handle short/long halt, idea from David, many thanks David 
> 
> v3 -> v4:
>  * bring back grow vcpu->halt_poll_ns when interrupt arrives and shrinks
>when idle VCPU is detected 
> 
> v2 -> v3:
>  * grow/shrink vcpu->halt_poll_ns by *halt_poll_ns_grow or 
> /halt_poll_ns_shrink
>  * drop the macros and hard coding the numbers in the param definitions
>  * update the comments "5-7 us"
>  * remove halt_poll_ns_max and use halt_poll_ns as the max halt_poll_ns time,
>vcpu->halt_poll_ns start at zero
>  * drop the wrappers 
>  * move the grow/shrink logic before "out:" w/ "if (waited)"
> 
> v1 -> v2:
>  * change kvm_vcpu_block to read halt_poll_ns from the vcpu instead of 
>the module parameter
>  * use the shrink/grow matrix which is suggested by David
>  * set halt_poll_ns_max to 2ms
> 
> There is a downside of always-poll since poll is still happened for idle 
> vCPUs which can waste cpu usage. This patchset add the ability to adjust 
> halt_poll_ns dynamically, to grow halt_poll_ns when shot halt is detected,  
> and to shrink halt_poll_ns when long halt is detected.
> 
> There are two new kernel parameters for changing the halt_poll_ns:
> halt_poll_ns_grow and halt_poll_ns_shrink. 
> 
> no-poll  always-polldynamic-poll
> ---
> Idle (nohz) vCPU %c0 0.15%0.3%0.2%  
> Idle (250HZ) vCPU %c01.1% 4.6%~14%1.2%
> TCP_RR latency   34us 27us26.7us
> 
> "Idle (X) vCPU %c0" is the percent of time the physical cpu spent in
> c0 over 60 seconds (each vCPU is pinned to a pCPU). (nohz) means the
> guest was tickless. (250HZ) means the guest was ticking at 250HZ.
> 
> The big win is with ticking operating systems. Running the linux guest
> with nohz=off (and HZ=250), we save 3.4%~12.8% CPUs/second and get close 
> to no-polling overhead levels by using the dynamic-poll. The savings
> should be even higher for higher frequency ticks.
> 
> Wanpeng Li (3):
>   KVM: make halt_poll_ns per-vCPU
>   KVM: dynamic halt-polling
>   KVM: trace kvm_halt_poll_ns grow/shrink
> 
>  include/linux/kvm_host.h   |  1 +
>  include/trace/events/kvm.h | 30 +++
>  virt/kvm/kvm_main.c| 72 
> ++
>  3 files changed, 97 insertions(+), 6 deletions(-)
> 

I get some nice improvements for uperf between 2 guests, but there is one "bug":
If there is already some polling ongoing, its impossible to disable the polling,
even a
 echo 0 >  /sys/module/kvm/parameters/halt_poll_ns
is ignored. (as vcpu->halt_poll_ns is used to check)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] lib/vsprintf.c: increase the size of the field_width variable

[Tejun Heo]

On Wed, Sep 09, 2015 at 12:13:10PM +0200, Maurizio Lombardi wrote:
> When printing a bitmap using the "%*pb[l]" printk format
> a 16 bit variable (field_width) is used to store the size of the bitmap.
> In some cases 16 bits are not sufficient, the variable overflows and
> printk does not work as expected.
> 
> This patch fixes the problem by changing the type of field_width to s32.
> 
> How to reproduce the bug:
> 
> 1.load scsi_debug
> # modprobe scsi-debug dev_size_mb=256 lbpu=1 lbpws10=1
> 
> 2.create VG
> # vgcreate tsvg /dev/sdb
>   Physical volume "/dev/sdb" successfully created
>   Volume group "tsvg" successfully created
> 
> 3. Bitmap should be set, but still empty
> # cat /sys/bus/pseudo/drivers/scsi_debug/map
> 
> Expected results:
> # cat /sys/bus/pseudo/drivers/scsi_debug/map
> 0-15
> 
> Signed-off-by: Maurizio Lombardi 

Acked-by: Tejun Heo 

Thanks.

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

Re: [PATCH 0/4] xtensa: fix build failure

[Sudip Mukherjee]

On Wed, Sep 09, 2015 at 03:52:11PM +0300, Max Filippov wrote:
> On Wed, Sep 9, 2015 at 10:11 AM, Sudip Mukherjee
> <sudipm.mukher...@gmail.com> wrote:
> > On Tue, Sep 08, 2015 at 08:34:56PM +0300, Max Filippov wrote:
> >> Sudip,
> >>
> >> On Tue, Sep 8, 2015 at 4:18 PM, Sudip Mukherjee
> >> <sudipm.mukher...@gmail.com> wrote:
> >> > While building with allmodconfig the build failed with different dma
> >> > related errors. It turned out that the dma functions were moved to
> >> > asm-generic/dma-mapping-common.h() and as a result we were getting the
> >> > errors of "redefinition".
> >> > This patch series will move the functions as required and at the end of
> >> > the series, allmodconfig builds.
> >>
> >> I believe it's fixed in the -mm tree and will be merged soon,
> >> see the thread at https://lkml.org/lkml/2015/8/26/118
> >
> > I guess its already merged in Linus tree now. I tested in the morning
> > with Linus tree and allmodconfig worked. But next-20150909 still failed.
> 
> AFAICS it's not merged yet: arch/xtensa/include/dma-mapping.h still
> has all functions deleted by patch in the mentioned thread.
Ohhh.. I didn't notice it in the morning. I saw Linus tree is building
and I thought it may have been merged. Now on checking I see that the
series by Christoph Hellwig which removes the arch specific functions is
still not in Linus tree and thats why I didnot get any error.


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

Re: [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order

[Lorenzo Pieralisi]

On Wed, Sep 09, 2015 at 10:30:18AM +0100, Lukasz Anaczkowski wrote:
> ACPI specifies the following rules when listing APIC IDs:
> (1) Boot processor is listed first
> (2) For multi-threaded processors, BIOS should list the first logical
> processor of each of the individual multi-threaded processors in MADT
> before listing any of the second logical processors.
> (3) APIC IDs < 0xFF should be listed in APIC subtable, APIC IDs >= 0xFF
> should be listed in X2APIC subtable
> 
> Because of above, when there's more than 0xFF logical CPUs, BIOS
> interleaves APIC/X2APIC subtables.
> 
> Assuming, there's 72 cores, 72 hyper-threads each, 288 CPUs total,
> listing is like this:
> 
> APIC (0,4,8, .., 252)
> X2APIC (258,260,264, .. 284)
> APIC (1,5,9,...,253)
> X2APIC (259,261,265,...,285)
> APIC (2,6,10,...,254)
> X2APIC (260,262,266,..,286)
> APIC (3,7,11,...,251)
> X2APIC (255,261,262,266,..,287)
> 
> Now, before this patch, due to how ACPI MADT subtables were parsed (BSP
> then X2APIC then APIC), kernel enumerated CPUs in reverted order (i.e.
> high APIC IDs were getting low logical IDs, and low APIC IDs were
> getting high logical IDs).
> This is wrong for the following reasons:
> () it's hard to predict how cores and threads are enumerated

So ? Why would the logical cpus order matters at all ? I guessed
there are probeable properties that allows the kernel to build
the affinity (ie topology list, shared caches, smt siblings, etc).
Please explain, since I am confused, to me all you need is a list
of existing physical ids, in whatever order they come, that's at least
what we need on ARM.

> () when it's hard to predict, s/w threads cannot be properly affinitized
>causing significant performance impact due to e.g. inproper cache
>sharing

See above. Why cpus logical ordering would matter here ?

> () enumeration is inconsistent with how threads are enumerated on
>other Intel Xeon processors

And why does that matter ? Is it because userspace is making assumptions
on the logical cpu enumeration scheme ? I am just asking, I would
like to understand.

> So, order in which MADT APIC/X2APIC handlers are passed is
> reverse and both handlers are passed to be called during same MADT
> table to walk to achieve correct CPU enumeration.

Define "correct" please, you define the logical ordering you
want to achieve, you do not define why that's more "correct"
than the current implementation.

Thank you,
Lorenzo

> In scenario when someone boots kernel with options 'maxcpus=72 nox2apic',
> in result less cores may be booted, since some of the CPUs the kernel
> will try to use will have APIC ID >= 0xFF. In such case, one
> should not pass 'nox2apic'.
> 
> Disclimer: code parsing MADT APIC/X2APIC has not been touched since 2009,
> when X2APIC support was initially added. I do not know why MADT parsing
> code was added in the reversed order in the first place.
> I guess it didn't matter at that time since nobody cared about cores
> with APIC IDs >= 0xFF, right?
> 
> This patch is based on work of "Yinghai Lu "
> previously published at https://lkml.org/lkml/2013/1/21/563
> 
> Here's the explanation why parsing interface needs to be changed
> and why simpler approach will not work https://lkml.org/lkml/2015/9/7/285
> 
> Signed-off-by: Lukasz Anaczkowski 
> Acked-by: Thomas Gleixner  (commit message)
> ---
>  arch/x86/kernel/acpi/boot.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index e49ee24..116e911 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -981,6 +981,8 @@ static int __init acpi_parse_madt_lapic_entries(void)
>  {
>   int count;
>   int x2count = 0;
> + int ret;
> + struct acpi_subtable_proc madt_proc[2];
>  
>   if (!cpu_has_apic)
>   return -ENODEV;
> @@ -1004,10 +1006,22 @@ static int __init acpi_parse_madt_lapic_entries(void)
> acpi_parse_sapic, MAX_LOCAL_APIC);
>  
>   if (!count) {
> - x2count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC,
> - acpi_parse_x2apic, MAX_LOCAL_APIC);
> - count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC,
> - acpi_parse_lapic, MAX_LOCAL_APIC);
> + memset(madt_proc, 0, sizeof(madt_proc));
> + madt_proc[0].id = ACPI_MADT_TYPE_LOCAL_APIC;
> + madt_proc[0].handler = acpi_parse_lapic;
> + madt_proc[1].id = ACPI_MADT_TYPE_LOCAL_X2APIC;
> + madt_proc[1].handler = acpi_parse_x2apic;
> + ret = acpi_table_parse_entries_array(ACPI_SIG_MADT,
> + sizeof(struct acpi_table_madt),
> + madt_proc, ARRAY_SIZE(madt_proc), 
> MAX_LOCAL_APIC);
> + if 

Re: [RFC PATCH] mmc: block: Add new ioctl to send combo commands

[Jon Hunter]

Hi Ulf,

On 09/09/15 13:42, Ulf Hansson wrote:
> On 3 September 2015 at 17:08, Jon Hunter  wrote:
>> Hi Olof,
>>
>> On 02/09/15 19:28, Olof Johansson wrote:
>>> Hi,
>>>
>>> On Wed, Sep 2, 2015 at 7:21 AM, Jon Hunter  wrote:
 From: Seshagiri Holi 

 Certain eMMC devices allow vendor specific device information to be read
 via a sequence of vendor commands. These vendor commands must be issued
 in sequence and an atomic fashion. One way to support this would be to
 add an ioctl function for sending a sequence of commands to the device
 atomically as proposed here. These combo commands are simple array of
 the existing mmc_ioc_cmd structure.
>>>
>>> This seems reasonable to me, being able to do a sequence of
>>> back-to-back operations without system read/writes slipping through.
> 
> I agree, this change seems reasonable!
> 
> Perhaps, from clarification point of view, we should change from
> naming it "combo" commands to *sequence* of commands. Both in the code
> and in the change log, please.

No problem. Sorry to bike-shed, but do you prefer sequence or multi? I
was thinking multi could be shorter for the code.

>>>
 diff --git a/include/uapi/linux/mmc/ioctl.h 
 b/include/uapi/linux/mmc/ioctl.h
 index 1f5e68923929..5943e51f22b3 100644
 --- a/include/uapi/linux/mmc/ioctl.h
 +++ b/include/uapi/linux/mmc/ioctl.h
 @@ -45,8 +45,23 @@ struct mmc_ioc_cmd {
  };
  #define mmc_ioc_cmd_set_data(ic, ptr) ic.data_ptr = (__u64)(unsigned 
 long) ptr

 -#define MMC_IOC_CMD _IOWR(MMC_BLOCK_MAJOR, 0, struct mmc_ioc_cmd)
 +/**
 + * struct mmc_ioc_combo_cmd - combo command information
 + * @num_of_cmds: number of commands to send
 + * @mmc_ioc_cmd_list: pointer to list of commands
 + */
 +struct mmc_ioc_combo_cmd {
 +   uint8_t num_of_cmds;
 +   struct mmc_ioc_cmd *mmc_ioc_cmd_list;
 +};
>>>
>>> The size of this struct will depend on the pointer size of userspace.
>>>
>>> It might be better to use a u64 for the pointer instead. Otherwise
>>> you'd need a compat ioctl wrapper to copy a 32-bit pointer over on a
>>> 64-bit kernel.
>>
>> Oh, good point. I have made this change today. I have also tested
>> this now with a hacked version of mmc-utils to send a couple status
>> commands back-to-back. I have tested on -next with ARM32 and on
>> ARM64 with an older 3.18 kernel (due to lack of mmc support in the
>> mainline for my ARM64 board) and seems to be working fine. Here is
>> an updated version ...
>>
>> Jon
>>
>> From fe5849a0d91ebbcfd092c74696f3fa7d7de3a156 Mon Sep 17 00:00:00 2001
>> From: Seshagiri Holi 
>> Date: Mon, 4 Nov 2013 17:27:43 +0530
>> Subject: [PATCH] mmc: block: Add new ioctl to send combo commands
>>
>> Certain eMMC devices allow vendor specific device information to be read
>> via a sequence of vendor commands. These vendor commands must be issued
>> in sequence and an atomic fashion. One way to support this would be to
>> add an ioctl function for sending a sequence of commands to the device
>> atomically as proposed here. These combo commands are simple array of
>> the existing mmc_ioc_cmd structure.
>>
>> Signed-off-by: Seshagiri Holi 
>> [ jonath...@nvidia.com: Rebased on linux-next from v3.18. Changed
>>   userspace pointer type for combo command to be a u64. Updated
>>   commit message ]
>> Signed-off-by: Jon Hunter 
>> ---
>>  drivers/mmc/card/block.c   | 199 
>> -
>>  include/uapi/linux/mmc/ioctl.h |  17 +++-
>>  2 files changed, 171 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
>> index c742cfd7674e..0423d95ea020 100644
>> --- a/drivers/mmc/card/block.c
>> +++ b/drivers/mmc/card/block.c
>> @@ -387,6 +387,22 @@ out:
>> return ERR_PTR(err);
>>  }
>>
>> +static int mmc_blk_ioctl_copy_to_user(struct mmc_ioc_cmd __user *ic_ptr,
>> + struct mmc_blk_ioc_data *idata)
>> +{
>> +   if (copy_to_user(&(ic_ptr->response), idata->ic.response,
>> +sizeof(idata->ic.response)))
>> +   return -EFAULT;
>> +
>> +   if (!idata->ic.write_flag) {
>> +   if (copy_to_user((void __user *)(unsigned 
>> long)idata->ic.data_ptr,
>> +idata->buf, idata->buf_bytes))
>> +   return -EFAULT;
>> +   }
>> +
>> +   return 0;
>> +}
>> +
>>  static int ioctl_rpmb_card_status_poll(struct mmc_card *card, u32 *status,
>>u32 retries_max)
>>  {
>> @@ -447,12 +463,9 @@ out:
>> return err;
>>  }
>>
>> -static int mmc_blk_ioctl_cmd(struct block_device *bdev,
>> -   struct mmc_ioc_cmd __user *ic_ptr)
>> +static int __mmc_blk_ioctl_cmd(struct mmc_card *card, struct mmc_blk_data 
>> *md,
>> +   

Re: [PATCH 0/4] MIPS: ath79: Add USB support on the TL-WR1043ND

[Alban]

On Mon, 07 Sep 2015 15:20:42 +0200
Arnd Bergmann  wrote:

> On Tuesday 01 September 2015 17:23:10 Alban Bedel wrote:
> > 
> > this serie add a driver for the USB phy on the ATH79 SoCs and enable the
> > USB port on the TL-WR1043ND. The phy controller is really trivial as it
> > only use reset lines.
> > 
> 
> Is this a common thing to have? If other PHY devices are like this, we
> could instead add a simple generic PHY driver that just asserts all
> its reset lines in the order as provided, rather than making this a
> hardware specific driver that ends up getting copied several times.

I don't know how common it is. However I agree that a simple driver that
can start a clock and toggle a few GPIO and/or reset would make sense.

However in the case of the ATH79 SoC some models have a reset line that
is misused to force the PHY in sleep mode. Sadly this extra reset must
be asserted for the PHY to work, so it wouldn't fit in such a generic
design.

Still we could have such a generic driver and let the ATH79 driver
build on top of it. Honestly that's what I wanted to do, but getting
generic drivers with DT support accepted is not easy. That's why I went
with this driver, it is technically inferior but much easier to get
considered for merging.

Alban
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next v6 1/8] mtd: spi-nor: read JEDEC ID with multiple I/O protocols

[Marek Vasut]

On Wednesday, September 09, 2015 at 03:24:11 PM, Cyrille Pitchen wrote:
> When their quad or dual I/O mode is enabled, Micron and Macronix spi-nor
> memories don't reply to the regular Read ID (0x9f) command. Instead they
> reply to a new dedicated command Read ID Multiple I/O (0xaf).
> 
> If the Read ID (0x9f) command fails (the read ID is all 1's or all 0's),
> then the Read ID Multiple I/O (0xaf) is used, first with SPI 4-4-4 protocol
> (supported by both Micron and Macronix memories), lately with SPI-2-2-2
> protocol (supported only by Micron memories).
> 
> Signed-off-by: Cyrille Pitchen 
> ---
>  drivers/mtd/spi-nor/spi-nor.c | 28 +++-
>  include/linux/mtd/spi-nor.h   | 23 +--
>  2 files changed, 48 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index f59aedfe1462..80a0db078aaa 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -703,8 +703,9 @@ static const struct flash_info spi_nor_ids[] = {
> 
>  static const struct flash_info *spi_nor_read_id(struct spi_nor *nor)
>  {
> - int tmp;
> + int i, tmp;
>   u8  id[SPI_NOR_MAX_ID_LEN];
> + enum spi_protocol   proto[2] = {SPI_PROTO_4_4_4, SPI_PROTO_2_2_2};
>   const struct flash_info *info;
> 
>   tmp = nor->read_reg(nor, SPINOR_OP_RDID, id, SPI_NOR_MAX_ID_LEN);
> @@ -713,6 +714,25 @@ static const struct flash_info *spi_nor_read_id(struct
> spi_nor *nor) return ERR_PTR(tmp);
>   }
> 
> + /* Special case for Micron/Macronix qspi nor. */
> + for (i = 0; i < ARRAY_SIZE(proto); ++i) {
> + if (!((id[0] == 0xff && id[1] == 0xff && id[2] == 0xff) ||
> +   (id[0] == 0x00 && id[1] == 0x00 && id[2] == 0x00)))
> + break;
> +
> + nor->erase_proto = proto[i];
> + nor->read_proto = proto[i];
> + nor->write_proto = proto[i];
> + nor->reg_proto = proto[i];
> + tmp = nor->read_reg(nor, SPINOR_OP_MIO_RDID,
> + id, SPI_NOR_MAX_ID_LEN);
> + if (tmp < 0) {
> + dev_dbg(nor->dev,
> + " error %d reading JEDEC ID (MULTI IO)\n", tmp);

Don't you have one space too much in front of the " error" ?

> + return ERR_PTR(tmp);
> + }
> + }
> +
>   for (tmp = 0; tmp < ARRAY_SIZE(spi_nor_ids) - 1; tmp++) {
>   info = _nor_ids[tmp];
>   if (info->id_len) {

[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 V9 6/6] perf,tools: Show freq/CPU%/CORE_BUSY% in perf report by --freq-perf

[Jiri Olsa]

On Tue, Sep 08, 2015 at 03:32:49PM -0400, kan.li...@intel.com wrote:
> From: Kan Liang 
> 
> Show frequency, CPU Utilization and percent performance for each symbol
> in perf report by --freq-perf
> 
> In sampling group, only group leader do sampling. So only need to print
> group leader's freq in --group.
> 
> --freq-perf option also implies --group.
> 
> Here is an example.
> 
> $ perf report --stdio --freq-perf
> 
>  Overhead   FREQ MHz   CPU%  CORE_BUSY%
> Command  Shared Object Symbol
>    .  .  ..
> ...    ..
> 
> 99.54%  99.54%  99.53%  99.53%  99.53%   2301 96 99
> tchain_edit  tchain_edit   [.] f3
>  0.20%   0.20%   0.20%   0.20%   0.20%   2301 98 99
> tchain_edit  tchain_edit   [.] f2
>  0.05%   0.05%   0.05%   0.05%   0.05%   2300 98 99
> tchain_edit  [kernel.vmlinux]  [k] read_tsc
> 
> Signed-off-by: Kan Liang 

it seems ok to me, though I think it could be split
into HPP__SINGLE_PRINT_FNS support and the rest..

but I prefer if Arnaldo or Namhyung could review this one

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

Re: When would be preempt_rt patchet available for 4.2 kernel

[Thomas Gleixner]

B1;2802;0cOn Wed, 9 Sep 2015, Manish Jaggi wrote:
> I am working on linux 4.2 kernel for our ARM64 platform.

That's lame. I'm working on linux 5.0 kernel for my new arch/zilchcore
platform.

> Can someone please tell when would be the preempt_rt patchset be
> available for 4.2

Once the 5.0 RT support for zilchcore is finished.

Thanks,

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

RE: [PATCH v2 1/4] iio: bmc150: Use i2c regmap

[Tirdea, Irina]

> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 20 August, 2015 15:50
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen; 
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v2 1/4] iio: bmc150: Use i2c regmap
> 
> This replaces all usage of direct i2c accesses with regmap accesses.
> 
> Signed-off-by: Markus Pargmann 
> ---

This patch works, but I would wait for the rebased version and check again.
One minor comment below.

>  drivers/iio/accel/Kconfig|   2 +
>  drivers/iio/accel/bmc150-accel.c | 219 
> +--
>  2 files changed, 95 insertions(+), 126 deletions(-)
> 
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 00e7bcbdbe24..01dd03d194d1 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -22,6 +22,8 @@ config BMC150_ACCEL
>   depends on I2C
>   select IIO_BUFFER
>   select IIO_TRIGGERED_BUFFER
> + select REGMAP
> + select REGMAP_I2C
>   help
> Say yes here to build support for the following Bosch accelerometers:
> BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
> diff --git a/drivers/iio/accel/bmc150-accel.c 
> b/drivers/iio/accel/bmc150-accel.c
> index 55751d9e1ade..c5c773e75173 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
> 
>  #define BMC150_ACCEL_DRV_NAME"bmc150_accel"
>  #define BMC150_ACCEL_IRQ_NAME"bmc150_accel_event"
> @@ -185,6 +186,8 @@ enum bmc150_accel_trigger_id {
> 
>  struct bmc150_accel_data {
>   struct i2c_client *client;
> + struct regmap *regmap;
> + struct device *dev;
>   struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
>   atomic_t active_intr;
>   struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
> @@ -241,6 +244,11 @@ static const struct {
>  {50, BMC150_ACCEL_SLEEP_500_MS},
>  {100, BMC150_ACCEL_SLEEP_1_SEC} };
> 
> +static const struct regmap_config bmc150_i2c_regmap_conf = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = 0x3f,
> +};
> 
>  static int bmc150_accel_set_mode(struct bmc150_accel_data *data,
>enum bmc150_power_modes mode,
> @@ -270,8 +278,7 @@ static int bmc150_accel_set_mode(struct bmc150_accel_data 
> *data,
> 
>   dev_dbg(>client->dev, "Set Mode bits %x\n", lpw_bits);
> 
> - ret = i2c_smbus_write_byte_data(data->client,
> - BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
> + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
>   if (ret < 0) {
>   dev_err(>client->dev, "Error writing reg_pmu_lpw\n");
>   return ret;
> @@ -289,8 +296,7 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data 
> *data, int val,
>   for (i = 0; i < ARRAY_SIZE(bmc150_accel_samp_freq_table); ++i) {
>   if (bmc150_accel_samp_freq_table[i].val == val &&
>   bmc150_accel_samp_freq_table[i].val2 == val2) {
> - ret = i2c_smbus_write_byte_data(
> - data->client,
> + ret = regmap_write(data->regmap,
>   BMC150_ACCEL_REG_PMU_BW,
>   bmc150_accel_samp_freq_table[i].bw_bits);
>   if (ret < 0)
> @@ -307,26 +313,19 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data 
> *data, int val,
> 
>  static int bmc150_accel_update_slope(struct bmc150_accel_data *data)
>  {
> - int ret, val;
> + int ret;
> 
> - ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_INT_6,
> + ret = regmap_write(data->regmap, BMC150_ACCEL_REG_INT_6,
>   data->slope_thres);
>   if (ret < 0) {
>   dev_err(>client->dev, "Error writing reg_int_6\n");
>   return ret;
>   }
> 
> - ret = i2c_smbus_read_byte_data(data->client, BMC150_ACCEL_REG_INT_5);
> + ret = regmap_update_bits(data->regmap, BMC150_ACCEL_REG_INT_5,
> +  BMC150_ACCEL_SLOPE_DUR_MASK, data->slope_dur);
>   if (ret < 0) {
> - dev_err(>client->dev, "Error reading reg_int_5\n");
> - return ret;
> - }
> -
> - val = (ret & ~BMC150_ACCEL_SLOPE_DUR_MASK) | data->slope_dur;
> - ret = i2c_smbus_write_byte_data(data->client, BMC150_ACCEL_REG_INT_5,
> - val);
> - if (ret < 0) {
> - dev_err(>client->dev, "Error write reg_int_5\n");
> + dev_err(>client->dev, "Error updating reg_int_5\n");
>   return ret;
>   }
> 

RE: [PATCH v2 3/4] iio: bmc150: Split the driver into core and i2c

[Tirdea, Irina]

> -Original Message-
> From: Markus Pargmann [mailto:m...@pengutronix.de]
> Sent: 20 August, 2015 15:50
> To: Jonathan Cameron
> Cc: Srinivas Pandruvada; Tirdea, Irina; Lars-Peter Clausen; 
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ker...@pengutronix.de; Markus Pargmann
> Subject: [PATCH v2 3/4] iio: bmc150: Split the driver into core and i2c
> 
> Signed-off-by: Markus Pargmann 
> ---
>  drivers/iio/accel/Kconfig  |  9 +-
>  drivers/iio/accel/Makefile |  3 +-
>  .../accel/{bmc150-accel.c => bmc150-accel-core.c}  | 95 -
>  drivers/iio/accel/bmc150-accel-i2c.c   | 99 
> ++
>  drivers/iio/accel/bmc150-accel.h   | 21 +
>  5 files changed, 144 insertions(+), 83 deletions(-)
>  rename drivers/iio/accel/{bmc150-accel.c => bmc150-accel-core.c} (95%)
>  create mode 100644 drivers/iio/accel/bmc150-accel-i2c.c
>  create mode 100644 drivers/iio/accel/bmc150-accel.h
> 
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 01dd03d194d1..6da4eb0db57b 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -19,21 +19,22 @@ config BMA180
> 
>  config BMC150_ACCEL
>   tristate "Bosch BMC150 Accelerometer Driver"
> - depends on I2C
>   select IIO_BUFFER
>   select IIO_TRIGGERED_BUFFER
>   select REGMAP
> - select REGMAP_I2C
> + select BMC150_ACCEL_I2C if I2C
>   help
> Say yes here to build support for the following Bosch accelerometers:
> BMC150, BMI055, BMA250E, BMA222E, BMA255, BMA280.
> 
> -   Currently this only supports the device via an i2c interface.
> -
> This is a combo module with both accelerometer and magnetometer.
> This driver is only implementing accelerometer part, which has
> its own address and register map.
> 
> +config BMC150_ACCEL_I2C
> + tristate
> + select REGMAP_I2C
> +
>  config HID_SENSOR_ACCEL_3D
>   depends on HID_SENSOR_HUB
>   select IIO_BUFFER
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index ebd2675b2a02..5ef8bdbad092 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -4,7 +4,8 @@
> 
>  # When adding new entries keep the list in alphabetical order
>  obj-$(CONFIG_BMA180) += bma180.o
> -obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel.o
> +obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> +obj-$(CONFIG_BMC150_ACCEL_I2C) += bmc150-accel-i2c.o
>  obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>  obj-$(CONFIG_KXCJK1013) += kxcjk-1013.o
>  obj-$(CONFIG_KXSD9)  += kxsd9.o
> diff --git a/drivers/iio/accel/bmc150-accel.c 
> b/drivers/iio/accel/bmc150-accel-core.c
> similarity index 95%
> rename from drivers/iio/accel/bmc150-accel.c
> rename to drivers/iio/accel/bmc150-accel-core.c
> index e4a0691d9b88..614cf61f0110 100644
> --- a/drivers/iio/accel/bmc150-accel.c
> +++ b/drivers/iio/accel/bmc150-accel-core.c
> @@ -37,6 +37,8 @@
>  #include 
>  #include 
> 
> +#include "bmc150-accel.h"
> +
>  #define BMC150_ACCEL_DRV_NAME"bmc150_accel"
>  #define BMC150_ACCEL_IRQ_NAME"bmc150_accel_event"
>  #define BMC150_ACCEL_GPIO_NAME   "bmc150_accel_int"
> @@ -187,7 +189,6 @@ enum bmc150_accel_trigger_id {
>  struct bmc150_accel_data {
>   struct regmap *regmap;
>   struct device *dev;
> - int irq;
>   struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
>   atomic_t active_intr;
>   struct bmc150_accel_trigger triggers[BMC150_ACCEL_TRIGGERS];
> @@ -201,6 +202,7 @@ struct bmc150_accel_data {
>   int ev_enable_state;
>   int64_t timestamp, old_timestamp; /* Only used in hw fifo mode. */
>   const struct bmc150_accel_chip_info *chip_info;
> + int irq;
>  };
> 
>  static const struct {
> @@ -1070,15 +1072,6 @@ static const struct iio_chan_spec 
> bmc150_accel_channels[] =
>  static const struct iio_chan_spec bma280_accel_channels[] =
>   BMC150_ACCEL_CHANNELS(14);
> 
> -enum {
> - bmc150,
> - bmi055,
> - bma255,
> - bma250e,
> - bma222e,
> - bma280,
> -};
> -
>  static const struct bmc150_accel_chip_info bmc150_accel_chip_info_tbl[] = {
>   [bmc150] = {
>   .chip_id = 0xFA,
> @@ -1567,36 +1560,22 @@ static const struct iio_buffer_setup_ops 
> bmc150_accel_buffer_ops = {
>   .postdisable = bmc150_accel_buffer_postdisable,
>  };
> 
> -static int bmc150_accel_probe(struct i2c_client *client,
> -   const struct i2c_device_id *id)
> +int bmc150_accel_core_probe(struct device *dev, struct regmap *regmap, int 
> irq,
> + const char *name, int chip_id, bool block_supported)
>  {
>   struct bmc150_accel_data *data;
>   struct iio_dev *indio_dev;
>   int ret;
> - const char *name = NULL;
> - int chip_id = 0;
> - struct 

Re: [Patch v5 1/6] ACPI/PCI: Enhance ACPI core to support sparse IO space

[Bjorn Helgaas]

On Wed, Sep 9, 2015 at 1:38 AM, Jiang Liu  wrote:
> On 2015/7/30 4:37, Bjorn Helgaas wrote:
>> On Tue, Jun 09, 2015 at 12:20:43AM +0800, Jiang Liu wrote:
>>> Enhance ACPI resource parsing interfaces to support sparse IO space,
>>> which will be used to share common code between x86 and IA64 later.
>>>
>>> Tested-by: Tony Luck 
>>> Signed-off-by: Jiang Liu 
>>> Reviewed-by: Hanjun Guo 
>>> ---
>>>  drivers/acpi/resource.c |9 ++---
>>>  include/linux/ioport.h  |1 +
>>>  2 files changed, 7 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
>>> index 8244f013f210..fdcc73dad2c1 100644
>>> --- a/drivers/acpi/resource.c
>>> +++ b/drivers/acpi/resource.c
>>> @@ -123,7 +123,7 @@ bool acpi_dev_resource_memory(struct acpi_resource 
>>> *ares, struct resource *res)
>>>  EXPORT_SYMBOL_GPL(acpi_dev_resource_memory);
>>>
>>>  static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
>>> -  u8 io_decode)
>>> +  u8 io_decode, u8 translation_type)
>>>  {
>>>  res->flags = IORESOURCE_IO;
>>>
>>> @@ -135,6 +135,8 @@ static void acpi_dev_ioresource_flags(struct resource 
>>> *res, u64 len,
>>>
>>>  if (io_decode == ACPI_DECODE_16)
>>>  res->flags |= IORESOURCE_IO_16BIT_ADDR;
>>> +if (translation_type == ACPI_SPARSE_TRANSLATION)
>>> +res->flags |= IORESOURCE_IO_SPARSE;
>>>  }
>>>
>>>  static void acpi_dev_get_ioresource(struct resource *res, u64 start, u64 
>>> len,
>>> @@ -142,7 +144,7 @@ static void acpi_dev_get_ioresource(struct resource 
>>> *res, u64 start, u64 len,
>>>  {
>>>  res->start = start;
>>>  res->end = start + len - 1;
>>> -acpi_dev_ioresource_flags(res, len, io_decode);
>>> +acpi_dev_ioresource_flags(res, len, io_decode, 0);
>>>  }
>>>
>>>  /**
>>> @@ -227,7 +229,8 @@ static bool acpi_decode_space(struct resource_win *win,
>>>  acpi_dev_memresource_flags(res, len, wp);
>>>  break;
>>>  case ACPI_IO_RANGE:
>>> -acpi_dev_ioresource_flags(res, len, iodec);
>>> +acpi_dev_ioresource_flags(res, len, iodec,
>>> +  addr->info.io.translation_type);
>>>  break;
>>>  case ACPI_BUS_NUMBER_RANGE:
>>>  res->flags = IORESOURCE_BUS;
>>> diff --git a/include/linux/ioport.h b/include/linux/ioport.h
>>> index 388e3ae94f7a..24bea087e7af 100644
>>> --- a/include/linux/ioport.h
>>> +++ b/include/linux/ioport.h
>>> @@ -94,6 +94,7 @@ struct resource {
>>>  /* PnP I/O specific bits (IORESOURCE_BITS) */
>>>  #define IORESOURCE_IO_16BIT_ADDR(1<<0)
>>>  #define IORESOURCE_IO_FIXED (1<<1)
>>> +#define IORESOURCE_IO_SPARSE(1<<2)
>>
>> I don't really like this bit.  We adding a new generic IORESOURCE_* bit
>> just for a special case, and it's only used in one place, for one arch,
>> during enumeration.
> Hi Bjorn,
> Instead of defining a formal flag IORESOURCE_IO_SPARSE, we may
> reuse other field in struct resource to pass back the SPARSE flag,
> but that's a little dirty. For example, we may reuse res->name field
> to carry the SPARSE flag for the IA64 special case.
> Is that OK?

No, I think that's even worse.  Adding IORESOURCE_IO_SPARSE looks
positively glorious now.

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

Re: [PATCH v2 0/1] Corsair Vengeance K90 driver

[Clément Vuchener]

On Mon, Sep 07, 2015 at 05:58:36PM +0200, Clément Vuchener wrote:
> I removed the k90_profile class completely. I cannot write a good enough ABI 
> with what I know of the keyboard so I am leaving that part out of the kernel. 
> If I change my mind in the future, it will be done in another patch.
> 
> I also fixed a bug I had when unregistering the led device. Work was being 
> scheduled after the led device was unregistered.
> 
> On the name change, I kept a lot of K90 references. As far as I know, the 
> only similar keyboard is the K60 that shares the same firmware but does not 
> have all the special keys and backlight, and for which the hid-generic driver 
> should be enough. The more recent RGB keyboard series uses a different 
> protocol from what I have seen from the unofficial userspace driver (CKB from 
> MSC).
Actually, I may have been wrong, other keyboard may share at least the 
incorrect HID usage code part. I will investigate more and send a new patch. I 
am still interested in comments on this one, especially on the choice of key 
codes for the programmable keys.
> 
> changes in v2:
>  - Removed the k90_profile class and devices
>  - Renamed driver for a more generic name ("corsair" driver in hid-corsair.c)
>  - Fixed led devices clean up (hang when unplugging and led state reset)
>  - Added dependency on USB and LEDS_CLASS in Kconfig
> 
> Clément Vuchener (1):
>   Add Corsair Vengeance K90 driver
> 
>  Documentation/ABI/testing/sysfs-driver-hid-corsair |  15 +
>  drivers/hid/Kconfig|  10 +
>  drivers/hid/Makefile   |   1 +
>  drivers/hid/hid-core.c |   1 +
>  drivers/hid/hid-corsair.c  | 555 
> +
>  drivers/hid/hid-ids.h  |   3 +
>  6 files changed, 585 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-driver-hid-corsair
>  create mode 100644 drivers/hid/hid-corsair.c
> 
> -- 
> 2.4.3
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 5/6] seccomp: add a way to attach a filter via eBPF fd

[Alexei Starovoitov]

On Wed, Sep 09, 2015 at 08:47:24AM -0600, Tycho Andersen wrote:
> On Tue, Sep 08, 2015 at 05:07:03PM -0700, Kees Cook wrote:
> >
> > Yeah, bpf's union looks good. Let's add a "command" flag, though:
> > 
> > seccomp(SECCOMP_MODE_FILTER_EBPF, int cmd, union, size);
> > 
> > And this cmd could be ADD_FD or something?
> > 
> > How's that look?
> 
> I think we can drop the size (using the same strategy as bpf() and
> checking for zeroes at the end), and keep the same signature for
> seccomp(); so:
> 
> seccomp(SECCOMP_MODE_FILTER_EBPF, SECCOMP_ADD_BPF_FD, )
> 
> Yes, I'll use this in the next version.

actually bpf() has size as the last argument:
SYSCALL_DEFINE3(bpf, int, cmd, union bpf_attr __user *, uattr, unsigned int, 
size)
perf_event_open() doesn't and size is embedded as one of the fields.
Both approaches are equivally powerfull from extensitiblity
point of view. My preference was to keep size as an explicit
argument.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 linux-next v9 2/3] mfd: devicetree: add bindings for Atmel Flexcom

[Cyrille Pitchen]

Hi Rob,

Le 09/09/2015 01:40, Rob Herring a écrit :
> On 09/01/2015 09:46 AM, Cyrille Pitchen wrote:
>> This patch documents the DT bindings for the Atmel Flexcom which will be
>> introduced by sama5d2x SoCs. These bindings will be used by the actual
>> Flexcom driver to be sent in another patch.
>>
>> Signed-off-by: Cyrille Pitchen 
>> Acked-by: Boris Brezillon 
>> Acked-by: Alexandre Belloni 
> 
> A few comments, but in general looks fine.
> 
>> ---
>>  .../devicetree/bindings/mfd/atmel-flexcom.txt  | 67 
>> ++
>>  1 file changed, 67 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
>> b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>> new file mode 100644
>> index ..fc3511e41542
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
>> @@ -0,0 +1,67 @@
>> +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication 
>> Unit)
>> +
>> +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
>> +controller and an USART. Only one function can be used at a time and is 
>> chosen
>> +at boot time according to the device tree.
> 
> Doesn't the board design choose (unless pins go to a header)?
> 

The function may be chosen once for all by the board design but if we take the
sama5d2 xplained board as an example, most Flexcoms output their pins to
headers.

>> +
>> +Required properties:
>> +- compatible:   Should be "atmel,sama5d2-flexcom"
>> +- reg:  Should be the offset/length value for Flexcom 
>> dedicated
>> +I/O registers (without USART, TWI or SPI registers).
>> +- clocks:   Should be the Flexcom peripheral clock from PMC.
>> +- #address-cells:   Should be <1>
>> +- #size-cells:  Should be <1>
>> +- ranges:   Should be one range for the full I/O register region
>> +(including USART, TWI and SPI registers).
>> +- atmel,flexcom-mode:   Should be one of the 3 following macros as 
>> defined in
>> +include/dt-bindings/mfd/atmel-flexcom.h:
>> +- ATMEL_FLEXCOM_MODE_USART for USART
>> +- ATMEL_FLEXCOM_MODE_SPI for SPI
>> +- ATMEL_FLEXCOM_MODE_TWI for I2C
>> +
>> +Required child:
>> +a single child device of type matching the "atmel,flexcom-mode" property.
> 
> Okay, but why not allow all children and use "status"?
> 

That is exactly what was proposed in v6 of this series: allow more than one
child so possibly all children but only one "available" child (status = 
"okay").

The Flexocm driver still needs to find out the type of device of this
available child to know which function is to be enabled (USART, I2C or SPI).
So the "compatible" attribute was parsed using strstr() to search on of the
patterns "usart", "spi" or "i2c".

However the use of strstr() was discussed to know whether the driver should
looks for a partial or an exact match of the "compatible" string.
An exact match would require to keep the Flexcom driver synchonized with the
3 other drivers every time one of them introduces a new compatibility string,
which whould have made every driver more difficult to maintain by creating a
useless dependency.
So this implementation relying on the "compatible" attribute was abandoned.

To sum up, no other reliable (and simple) means to guess/extact the device
type from its DT node was found so we got back to the "atmel,flexcom-mode"
property.

>> +
>> +The reg property of this child should be:
>> +- <0x200 0x200> for USART
>> +- <0x400 0x200> for SPI
>> +- <0x600 0x200> for I2C
>> +
>> +The phandle provided by the clocks property of the child is the same as one 
>> for
>> +the Flexcom parent.
>> +
>> +Other properties remain unchanged. See documentation of the respective 
>> device:
>> +- ../serial/atmel-usart.txt
>> +- ../spi/spi_atmel.txt
>> +- ../i2c/i2c-at91.txt
>> +
>> +Example:
>> +
>> +flexcom@f8034000 {
>> +compatible = "atmel,sama5d2-flexcom";
>> +reg = <0xf8034000 0x200>;
>> +clocks = <_clk>;
>> +#address-cells = <1>;
>> +#size-cells = <1>;
>> +ranges = <0x0 0xf8034000 0x800>;
>> +atmel,flexcom-mode = ;
>> +
>> +spi@400 {
>> +compatible = "atmel,at91rm9200-spi";
>> +reg = <0x400 0x200>;
>> +interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
>> +pinctrl-names = "default";
>> +pinctrl-0 = <_flx0_default>;
>> +#address-cells = <1>;
>> +#size-cells = <0>;
>> +clocks = <_clk>;
>> +clock-names = "spi_clk";
>> +atmel,fifo-size = <32>;
>> +
>> +mtd_dataflash@0 {
>> +compatible = "atmel,at25f512b";
>> +reg = <0>;
>> +   

Re: [linux-sunxi] Re: Almost certainly confirmed, sun7i-a20 does not support 8 bit mmc.

[Olliver Schinagl]

Hey,

On 09-09-15 17:32, Hans de Goede wrote:

Hi,

On 09-09-15 16:30, Maxime Ripard wrote:

On Wed, Sep 09, 2015 at 03:04:11PM +0200, Olliver Schinagl wrote:

Hey all,

After experimenting with a Micron eMMC chip, I made some interesting 
finds I

wanted to share with you all.

For a while now, some had hopes or guessed that the A20 could have 
support
for 8 bit wide bused on the SDC2. Reason for thinking this was, 
because the
sun7i uses the same IP as the sun5i which does support 8 bit wide 
eMMC. The
usermanual does mention 1/4/8 bit data buses and jedec 4.3 support 
of the
MMC spec. Unfortunately so far, it appears that the extra data pins 
have not

been muxed out to the PC pads.

I used the following code to enable the extra pins on the A20:
 mmc2_pins_a: mmc2@0 {
-   allwinner,pins = "PC6", "PC7", "PC8",
-"PC9", "PC10", "PC11";
+   allwinner,pins = "PC6", "PC7",
+"PC8", "PC9", "PC10",
"PC11",
+"PC12", "PC13", 
"PC14",

"PC15";

and
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand0")),/* NDQ4 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ4 */
+ SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand0")),/* NDQ5 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ5 */
+ SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand0")),/* NDQ6 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ6 */
+ SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),
- SUNXI_FUNCTION(0x2, "nand0")),/* NDQ7 */
+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ7 */
+ SUNXI_FUNCTION(0x3, "mmc2")), /* D7 */


Where did you get that info from ? Those pins have never been reported
as having the mmc2 function, which would explain why it doesn't work.


Right, but the A20 has the same mmc controller as the A13, which does
do 8 bit mmc on PORTC, and the datasheet advertises 8 bit bus width
support in its feature list. So this was worth a shot.
Yeah Hans and I where discussing it a bit off list, and where hoping 
that it could be available. Also the H3 for example exposes the mux.


Hopefully the A40 or whatever the A10 pin compatible upgrade will be 
have these MUXes out. Pin-wise it makes sense as it's the same pins as 
the 8 NAND data pins.


Anyway, I'll go home now to find my Olimex A20-micro, as I may actually 
have one, and run some tests on it for Maxime ;)


Olliver


Regards,

Hans



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

Re: [PATCH] mmc: block: Add new ioctl to send multi commands

[Arnd Bergmann]

On Wednesday 09 September 2015 16:06:01 Jon Hunter wrote:
> +
> +   idata = kcalloc(mcci.num_of_cmds, sizeof(*idata), GFP_KERNEL);
> +   if (!idata) {
> +   err = -ENOMEM;
> +   goto cmd_err;
> +   }
> +
> +   cmds = (struct mmc_ioc_cmd __user *)(unsigned long)mcci.cmds_ptr;
> +   for (n_cmds = 0; n_cmds < mcci.num_of_cmds; n_cmds++) {
> +   idata[n_cmds] = mmc_blk_ioctl_copy_from_user([n_cmds]);
> +   if (IS_ERR(idata[n_cmds])) {
> +   err = PTR_ERR(idata[n_cmds]);
> +   goto cmd_err;
> +   }
> +   }
> +

You have no upper bound on the number of commands, which means you end
up catching overly large arguments only through -ENOMEM. Can you come
up with an upper bound that is guaranteed to succeed with the allocation?

Or would it be possible to process the user data one at a time while
going through the commands?

> +struct mmc_ioc_multi_cmd {
> +   __u64 cmds_ptr;
> +   uint8_t num_of_cmds;
> +};
 
complex commands are always nasty in one way or another. Can you describe
in the patch description why you picked an indirect pointer over something
like

struct mmc_ioc_multi_cmd {
__u64 num_of_cmds;
struct mmc_ioc_cmd cmds[0];
};

as I said, both are ugly. My first choice would have been the other one,
but I'm sure you have some reasons yourself.

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

Re: [PATCH 3/4] net: mv643xx_eth: use kzalloc

[Joe Perches]

On Wed, 2015-09-09 at 10:38 +0200, Rasmus Villemoes wrote:
> The double memset is a little ugly; using kzalloc avoids it altogether.
[]
> diff --git a/drivers/net/ethernet/marvell/mv643xx_eth.c 
> b/drivers/net/ethernet/marvell/mv643xx_eth.c
[]
> @@ -1859,14 +1859,11 @@ oom:
>   return;
>   }
>  
> - mc_spec = kmalloc(0x200, GFP_ATOMIC);
> + mc_spec = kzalloc(0x200, GFP_ATOMIC);
>   if (mc_spec == NULL)
>   goto oom;
>   mc_other = mc_spec + (0x100 >> 2);

This sure looks wrong as it sets a pointer
to unallocated memory.

> - memset(mc_spec, 0, 0x100);
> - memset(mc_other, 0, 0x100);

So this does a memset of random memory.

for (i = 0; i < 0x100; i += 4) {
wrl(mp, SPECIAL_MCAST_TABLE(mp->port_num) + i, mc_spec[i >> 2]);
wrl(mp, OTHER_MCAST_TABLE(mp->port_num) + i, mc_other[i >> 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/

Re: randconfig build error with next-20150908, in drivers/md/dm-mpath.c

[Christoph Hellwig]

Does this fix the issue for you?  My Kconfig-fu isn't the best,
but the idea behind this is that dm-mpath will depend on SCSI
if SCSI_DH is set.  If SCSI_DH is not set it will use the stubs
and not care about SCSI.

diff --git a/drivers/md/Kconfig b/drivers/md/Kconfig
index b597273..e9ea681 100644
--- a/drivers/md/Kconfig
+++ b/drivers/md/Kconfig
@@ -393,7 +393,7 @@ config DM_MULTIPATH
# of SCSI_DH if the latter isn't defined but if
# it is, DM_MULTIPATH must depend on it.  We get a build
# error if SCSI_DH=m and DM_MULTIPATH=y
-   depends on SCSI_DH || !SCSI_DH
+   depends on !SCSI_DH || SCSI
---help---
  Allow volume managers to support multipath hardware.
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] ebpf: add a seccomp program type

[Daniel Borkmann]

On 09/04/2015 11:50 PM, Andy Lutomirski wrote:

On Fri, Sep 4, 2015 at 9:04 AM, Tycho Andersen

[...]

+static const struct bpf_func_proto *
+seccomp_func_proto(enum bpf_func_id func_id)
+{
+   /* Right now seccomp eBPF loading doesn't support maps; seccomp filters
+* are considered to be read-only after they're installed, so map fds
+* probably need to be invalidated when a seccomp filter with maps is
+* installed.
+*
+* The rest of these might be reasonable to call from seccomp, so we
+* export them.
+*/
+   switch (func_id) {
+   case BPF_FUNC_ktime_get_ns:
+   return _ktime_get_ns_proto;
+   case BPF_FUNC_trace_printk:
+   return bpf_get_trace_printk_proto();
+   case BPF_FUNC_get_prandom_u32:
+   return _get_prandom_u32_proto;


I don't think we should expose prandom to unprivileged userspace.
This may be an attack vector.


Agreed, it should not be exposed for unpriv'ed users.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] btrfs: fortification for GFP_NOFS allocations

[Vlastimil Babka]

On 08/19/2015 08:17 PM, Chris Mason wrote:

On Wed, Aug 19, 2015 at 02:17:39PM +0200, mho...@kernel.org wrote:

Hi,
these two patches were sent as a part of a larger RFC which aims at
allowing GFP_NOFS allocations to fail to help sort out memory reclaim
issues bound to the current behavior
(http://marc.info/?l=linux-mm=143876830616538=2).

It is clear that move to the GFP_NOFS behavior change is a long term
plan but these patches should be good enough even with that change in
place. It also seems that Chris wasn't opposed and would be willing to
take them http://marc.info/?l=linux-mm=143991792427165=2 so here we
come. I have rephrased the changeslogs to not refer to the patch which
changes the NOFS behavior.

Just to clarify. These two patches allowed my particular testcase
(mentioned in the cover referenced above) to survive it doesn't mean
that the failing GFP_NOFS are OK now. I have seen some other places
where GFP_NOFS allocation is followed by BUG_ON(ALLOC_FAILED). I have
not encountered them though.

Let me know if you would prefer other changes.


My plan is to start with these two and take more as required.


I've previously noticed in __set_extent_bit() things like:

if (!prealloc && (mask & __GFP_WAIT)) {
prealloc = alloc_extent_state(mask);
BUG_ON(!prealloc);
}

and later:

prealloc = alloc_extent_state_atomic(prealloc);
BUG_ON(!prealloc);

which internally does:

if (!prealloc)
prealloc = alloc_extent_state(GFP_ATOMIC);

The first one could be fixable by adding __GFP_NOFAIL. In fact we've got 
an internal bug report for that one already. Even without GFP_NOFS being 
allowed to fail, allocation can already fail when the thread is marked 
for oom kill, which is likely what happened in that case.


The second case is problematic though, because GFP_ATOMIC | __GFP_NOFAIL 
is not allowed. GFP_ATOMIC will give you access to memory reserves, 
which reduces the chance of hitting the BUG_ON(), but it's not a 
bulletproof solution.



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



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/mmap.c: Remove useless statement "vma = NULL" in find_vma()

[Oleg Nesterov]

On 09/08, Chen Gang wrote:
>
> I also want to consult: the comments of find_vma() says:

Sorry, I don't understand the question ;)

> "Look up the first VMA which satisfies addr < vm_end, ..."
>
> Is it OK?

Why not?

> (why not "vm_start <= addr < vm_end"),

Because this some callers actually want to find the 1st vma which
satisfies addr < vm_end? For example, shift_arg_pages().

OTOH, I think that another helper,

find_vma_xxx(mm, addr)
{
vma = find_vma(...)
if (vma && vma->vm_start > addr)
vma = NULL;
return vma;
}

makes sense. It can have a lot of users.

> need we let "vma = tmp"
> in "if (tmp->vm_start <= addr)"? -- it looks the comments is not match
> the implementation, precisely (maybe not 1st VMA).

This contradicts with above... I mean, it is not clear what exactly do
you blame, semantics or implementation.

The implementation looks correct. Why do you think it can be not 1st vma?

Oleg.

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

Re: [PATCH v3] stmmac: fix check for phydev being open

[Alexey Brodkin]

Hi Sergei,

On Tue, 2015-09-08 at 22:53 +0300, Sergei Shtylyov wrote:
> Hello.
> 
> On 09/08/2015 03:46 PM, Alexey Brodkin wrote:
> 
> > > > Current check of phydev with IS_ERR(phydev) may make not much sense
> > > > because of_phy_connect() returns NULL on failure instead of error value.
> > > > 
> > > > Still for checking result of phy_connect() IS_ERR() makes perfect sense.
> > > > 
> > > > So let's use combined check IS_ERR_OR_NULL() that covers both cases.
> > > > 
> > > > Cc: Sergei Shtylyov 
> > > > Cc: Giuseppe Cavallaro 
> > > > Cc: linux-kernel@vger.kernel.org
> > > > Cc: sta...@vger.kernel.org
> > > > Cc: David Miller 
> > > > Signed-off-by: Alexey Brodkin 
> > > > ---
> > > > 
> > > > Changes compared to v2:
> > > >* Updated commit message with mention of of_phy_connect() instead of
> > > >  of_phy_attach().
> > > >* Return ENODEV in case of of_phy_connect() failure
> > > > 
> > > > Changes compared to v1:
> > > >* Use IS_ERR_OR_NULL() instead of discrete checks for null and err
> > > > 
> > > >drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 7 +--
> > > >1 file changed, 5 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > index 864b476..e2c9c86 100644
> > > > --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> > > > @@ -837,9 +837,12 @@ static int stmmac_init_phy(struct net_device *dev)
> > > >  interface);
> > > > }
> > > > 
> > > > -   if (IS_ERR(phydev)) {
> > > > +   if (IS_ERR_OR_NULL(phydev)) {
> > > > pr_err("%s: Could not attach to PHY\n", dev->name);
> > > > -   return PTR_ERR(phydev);
> > > > +   if (!phydev)
> > > > +   return -ENODEV;
> > > > +   else
> > > > +   return PTR_ERR(phydev);
> > > 
> > >  Don't need *else* after *return* and scripts/checkpatch.pl should 
> > > have
> > > complained about that.
> > 
> > ./scripts/checkpatch.pl 0001-stmmac-fix-check-for-phydev-being-open.patch
> > total: 0 errors, 0 warnings, 0 checks, 14 lines checked
> 
> Hm... I bet I saw such warning from checkpatch.pl recently (it was a 
> false 
> positive though, so maybe the check was removed recently, not sure). Your 
> patch is clean indeed, however my comment is still valid.

Ok, let me send another respin then.

-Alexey--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mm/page_alloc: add a helper function to check page before alloc/free

[Yaowei Bai]

On Wed, Sep 09, 2015 at 03:39:54PM +0200, Vlastimil Babka wrote:
> On 09/08/2015 09:19 PM, Vlastimil Babka wrote:
> >bloat-o-meter looks favorably with my gcc, although there shouldn't be a real
> >reason for it, as the inlining didn't change:
> >
> >add/remove: 1/1 grow/shrink: 1/1 up/down: 285/-336 (-51)
> >function old new   delta
> >bad_page   - 276+276
> >get_page_from_freelist  25212530  +9
> >free_pages_prepare   745 667 -78
> >bad_page.part258   --258
> >
> >With that,
> >
> >Acked-by: Vlastimil Babka 
> 
> BTW, why do we do all these checks in non-DEBUG_VM builds? Are they
> so often hit nowadays? Shouldn't we check just for hwpoison in the
> non-debug case?

I personly think these checks are still needed in non-debug scenario so
we can still catch the bad page caused by a bug or other things in that
case.

> 
> Alternatively, I've considered creating a fast inline pre-check that
> calls a non-inline check-with-report:
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 0c9c82a..cff92f8 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -707,7 +707,20 @@ static inline void __free_one_page(struct page *page,
>   zone->free_area[order].nr_free++;
>  }
> 
> -static inline int check_one_page(struct page *page, unsigned long
> bad_flags)
> +static inline int check_one_page_fast(struct page *page, unsigned long
> + bad_flags)
> +{
> + return (page_mapcount(page)
> + || page->mapping != NULL
> + || atomic_read(>_count) != 0
> + || page->flags & bad_flags
> +#ifdef CONFIG_MEMCG
> + || page->mem_cgroup
> +#endif
> + );
> +}
> +
> +static noinline int check_one_page(struct page *page, unsigned long
> bad_flags)
>  {
>   const char *bad_reason = NULL;
> 
> @@ -743,9 +756,12 @@ static inline int free_pages_check(struct page *page)
>  {
>   int ret = 0;
> 
> - ret = check_one_page(page, PAGE_FLAGS_CHECK_AT_FREE);
> - if (ret)
> - return ret;
> + ret = check_one_page_fast(page, PAGE_FLAGS_CHECK_AT_FREE);
> + if (ret) {
> + ret = check_one_page(page, PAGE_FLAGS_CHECK_AT_FREE);
> + if (ret)
> + return ret;
> + }
> 
>   page_cpupid_reset_last(page);
>   if (page->flags & PAGE_FLAGS_CHECK_AT_PREP)
> @@ -1304,7 +1320,9 @@ static inline void expand(struct zone *zone,
> struct page *page,
>   */
>  static inline int check_new_page(struct page *page)
>  {
> - return check_one_page(page, PAGE_FLAGS_CHECK_AT_PREP);
> + if (check_one_page_fast(page, PAGE_FLAGS_CHECK_AT_PREP | __PG_HWPOISON))
> + return check_one_page(page, PAGE_FLAGS_CHECK_AT_PREP);
> + return 0;
>  }
> 
>  static int prep_new_page(struct page *page, unsigned int order,
> gfp_t gfp_flags,
> 
> ---

This looks good to me.

> 
> That shrinks the fast paths nicely:
> 
> add/remove: 1/1 grow/shrink: 0/2 up/down: 480/-498 (-18)
> function old new   delta
> check_one_page - 480+480
> get_page_from_freelist  25302458 -72
> free_pages_prepare   667 517-150
> bad_page 276   --276
> 
> On top of that, the number of branches in the fast paths can be
> reduced if we use arithmetic OR to avoid the short-circuit boolean
> evaluation:
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index cff92f8..e8b42ba 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -710,12 +710,12 @@ static inline void __free_one_page(struct page *page,
>  static inline int check_one_page_fast(struct page *page, unsigned long
>   bad_flags)
>  {
> - return (page_mapcount(page)
> - || page->mapping != NULL
> - || atomic_read(>_count) != 0
> - || page->flags & bad_flags
> + return ((unsigned long) page_mapcount(page)
> + | (unsigned long) page->mapping
> + | (unsigned long) atomic_read(>_count)
> + | (page->flags & bad_flags)
>  #ifdef CONFIG_MEMCG
> - || page->mem_cgroup
> + | (unsigned long) page->mem_cgroup
>  #endif
>   );
>  }
> 
> That further reduces the fast paths, not much in bytes, but
> importantly in branches:
> 
> add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-51 (-51)
> function old new   delta
> get_page_from_freelist  24582443 -15
> free_pages_prepare   517 481 -36
> 
> But I can understand it's rather hackish, and maybe some
> architectures won't be 

[PATCH] gpio/pca953x: Add TI TCA9539 support

[Thierry Reding]

From: Thierry Reding 

The TCA9539 is almost identical to the PCA9555 and software-compatible
with this driver. It exposes 16 general purpose I/O pins in two 8-bit
configurations.

Signed-off-by: Thierry Reding 
---
 drivers/gpio/gpio-pca953x.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c
index 50caeb1ee350..b28791279173 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -67,6 +67,7 @@ static const struct i2c_device_id pca953x_id[] = {
{ "tca6408", 8  | PCA953X_TYPE | PCA_INT, },
{ "tca6416", 16 | PCA953X_TYPE | PCA_INT, },
{ "tca6424", 24 | PCA953X_TYPE | PCA_INT, },
+   { "tca9539", 16 | PCA953X_TYPE | PCA_INT, },
{ "xra1202", 8  | PCA953X_TYPE },
{ }
 };
@@ -754,6 +755,7 @@ static const struct of_device_id pca953x_dt_ids[] = {
{ .compatible = "ti,tca6408", },
{ .compatible = "ti,tca6416", },
{ .compatible = "ti,tca6424", },
+   { .compatible = "ti,tca9539", },
 
{ .compatible = "exar,xra1202", },
{ }
-- 
2.5.0

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

Re: [PATCH] ibmvsci: make parameters max_id and max_channel read-only

[Brian King]

On 09/09/2015 10:21 AM, Laurent Vivier wrote:
> The value of the parameter is never re-read by the driver,
> so a new value is ignored. Let know the user he
> can't modify it by removing writable attribute.

Reviewed-by: Brian King 

-- 
Brian King
Power Linux I/O
IBM Linux 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 1/4] stmmac: replace all pr_xxx by their dev_xxx counterpart

[Joe Perches]

On Wed, 2015-09-09 at 15:14 +0200, LABBE Corentin wrote:
> The stmmac driver use lots of pr_xxx functions to print information.
> This is bad since we cannot know which device logs the information.
> (moreover if two stmmac device are present)
[]
> So this patch replace all pr_xxx by their dev_xxx counterpart.

Using
netdev_(priv->dev, ...
instead of
dev_(priv->device,

would be more consistent with other ethernet devices.

> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
[]
> @@ -298,7 +298,7 @@ bool stmmac_eee_init(struct stmmac_priv *priv)
>*/
>   spin_lock_irqsave(>lock, flags);
>   if (priv->eee_active) {
> - pr_debug("stmmac: disable EEE\n");
> + dev_dbg(priv->device, "disable EEE\n");

netdev_dbg(priv->dev, ...)

> @@ -657,10 +657,10 @@ static int stmmac_init_ptp(struct stmmac_priv *priv)
>   priv->adv_ts = 1;
>  
>   if (netif_msg_hw(priv) && priv->dma_cap.time_stamp)
> - pr_debug("IEEE 1588-2002 Time Stamp supported\n");
> + dev_dbg(priv->device, "IEEE 1588-2002 Time Stamp supported\n");

And these netif_msg_ could be

if (priv->dma_cap.timestamp)
netif_dbg(priv, hw, priv->dev, ...);


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] dax: update PMD fault handler with PMEM API

[Ross Zwisler]

As part of the v4.3 merge window the DAX code was updated by Matthew and
Kirill to handle PMD pages.  Also as part of the v4.3 merge window we
updated the DAX code to do proper PMEM flushing:

2765cfbb342c ("dax: update I/O path to do proper PMEM flushing")

The additional code added by the DAX PMD patches also needs to be
updated to properly use the PMEM API.  This ensures that after a PMD
fault is handled the zeros written to the newly allocated pages are
durable on the DIMMs.

linux/dax.h is included to get rid of a bunch of sparse warnings.

Signed-off-by: Ross Zwisler 
---
Linus, would you consider applying this to the v4.3 merge tree?
---
 fs/dax.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index e43389c..93bf2f9 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -527,7 +528,7 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned 
long address,
unsigned long pmd_addr = address & PMD_MASK;
bool write = flags & FAULT_FLAG_WRITE;
long length;
-   void *kaddr;
+   void __pmem *kaddr;
pgoff_t size, pgoff;
sector_t block, sector;
unsigned long pfn;
@@ -570,7 +571,8 @@ int __dax_pmd_fault(struct vm_area_struct *vma, unsigned 
long address,
if (buffer_unwritten() || buffer_new()) {
int i;
for (i = 0; i < PTRS_PER_PMD; i++)
-   clear_page(kaddr + i * PAGE_SIZE);
+   clear_pmem(kaddr + i * PAGE_SIZE, PAGE_SIZE);
+   wmb_pmem();
count_vm_event(PGMAJFAULT);
mem_cgroup_count_vm_event(vma->vm_mm, PGMAJFAULT);
result |= VM_FAULT_MAJOR;
-- 
2.1.0

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

Re: [PATCH V9 0/6] Freq/CPU%/CORE_BUSY% support

[Jiri Olsa]

On Tue, Sep 08, 2015 at 03:32:43PM -0400, kan.li...@intel.com wrote:
> From: Kan Liang 
> 
> This patch set supports per-sample freq/CPU%/CORE_BUSY% print in perf
> report.
> For printing these information, the perf.data file must have been obtained
> by group read and using special events cycles, ref-cycles, msr/tsc/,
> msr/aperf/ or msr/mperf/.
> 
>  - Freq (MHz): The frequency during the sample interval. Needs cycles
>ref-cycles event.
>  - CPU%: CPU utilization during the sample interval. Needs ref-cycles and
>msr/tsc/ events.
>  - CORE_BUSY%: actual percent performance (APERF/MPERF%) during the
>sample interval. Needs msr/aperf/ and msr/mperf/ events.
> 
> Here is an example:
> 
> $ perf record --freq-perf ~/tchain_edit
> 
> $ perf report --stdio --freq-perf
> 
>  Overhead   FREQ MHz   CPU%  CORE_BUSY%
> Command  Shared Object Symbol
>    .  .  ..
> ...    ..
> 
> 99.54%  99.54%  99.53%  99.53%  99.53%   2301 96 99
> tchain_edit  tchain_edit   [.] f3
>  0.20%   0.20%   0.20%   0.20%   0.20%   2301 98 99
> tchain_edit  tchain_edit   [.] f2
>  0.05%   0.05%   0.05%   0.05%   0.05%   2300 98 99
> tchain_edit  [kernel.vmlinux]  [k] read_tsc
> 
> Changes since V1:
>  - Save cpu max freq to header when recording
>  - Read cpu max freq and msr type from header when reporting
> 
> Changes since V2:
>  - Introduce generic FEAT for CPU related data stored
>  - Make cpu max freq and msr type part of perf_session_env
>  - rename cpu_u to cpu_util
>  - Don't save sample value in perf_sample and discards new iterator.
>Calculating the freq_perf_info in add_entry_cb callback
>  - Introduce symbol_conf.freq_perf_type for related hpp column visibility
> 
> Changes since V3:
>  - add a identifier 'tag' for CPU attributes, max frequency.
>  - add backpointers to evlist for env, and evsel for evlist.
>  - Use bitmask for freq_perf_type
>  - Replace macros by functions to caculate freq, cpu_util and core_busy
>  - Move all caculation codes under symbol_conf.show_freq_perf condition.
> 
> Changes since V4:
>  - Store cpu attributes id as tag and more readable cpu_attr
> 
> Changes since V5:
>  - Rename freq to max_freq and use it
>  - Add a loop in process_cpu_attributes to facility future extension
> 
> Changes since V6:
>  - Split rename perf_session_env and add backpointer to evlist patches
> 
> Changes since V7:
>  - Introduce --freq-perf option for perf record
>  - Factor out fix for dump_sample
> 
> Changes since V8:
>  - Rename --show-freq-perf to --freq-perf 
>  - --freq-perf option imply --group

I believe I just acked all of it but the last one,
otherwise I'm ok with it

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