[PATCH v3] qrtr: add MODULE_ALIAS macro to smd

[Ramon Fried]

Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.

Signed-off-by: Ramon Fried 

---
V2: Corrected subject line, this is not a part of a patchset.
V3: Placed the changelog under the ---.

 net/qrtr/smd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
 
 module_rpmsg_driver(qcom_smd_qrtr_driver);
 
+MODULE_ALIAS("rpmsg:IPCRTR");
 MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
 MODULE_LICENSE("GPL v2");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v3] qrtr: add MODULE_ALIAS macro to smd

[Ramon Fried]

Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.

Signed-off-by: Ramon Fried 

---
V2: Corrected subject line, this is not a part of a patchset.
V3: Placed the changelog under the ---.

 net/qrtr/smd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
 
 module_rpmsg_driver(qcom_smd_qrtr_driver);
 
+MODULE_ALIAS("rpmsg:IPCRTR");
 MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
 MODULE_LICENSE("GPL v2");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [BUG] lock_parent() breakage when used from shrink_dentry_list() (was Re: [PATCH v2 6/6] fs/dcache: Avoid remaining try_lock loop in shrink_dentry_list())

[Al Viro]

On Sat, Feb 24, 2018 at 12:22:48AM +, Al Viro wrote:
> On Fri, Feb 23, 2018 at 01:35:52PM -0800, Linus Torvalds wrote:
> 
> > This is too subtle, and your fix to check d_lockref.count < 0 sounds
> > wrong to me. If it's really gone, maybe it has been reused and the
> > refcount is positive again, but it's something else than a dentry
> > entirely?
> > 
> > Hmm.
> > 
> > No, you extended the rcu read section, so I guess your patch is fine.
> > And lock_parent already has that pattern, soiit's not new.
> > 
> > Ok, I agree, looks like lock_parent should just re-check that thing
> > that it already checked earler, but that now might be true again
> > because of we dropped d_lock.
> 
> IMO that's the right thing for backports; whether we keep it after
> the getting rid of trylock loops is a different question.  Note that
> the only case where we do not have __dentry_kill() prevention
> guaranteed by the caller (either by holding a reference, or by
> holding onto ->i_lock all along) is in shrink_dentry_list().
> And there we have more than enough of other subtle crap.
> 
> Moreover, there we have a good reason to treat "it had been moved"
> as "kick it off the shrink list and free if it's already dead",
> which might simplify the things.  Below is a stab at that:

FWIW, a variant of that series is in #work.dcache; it's
almost certainly not the final (I want to clean the things up
and probably reorder them as well) and it needs one hell of
profiling and review.  It seems to work, and I don't see any
obvious performance regressions (everything seems to be within
normal noise), but I'd like it beaten up a lot more.

Parts are from John's series, parts are rewritten as discussed
upthread.  As the result, trylock loops are gone and no new
retry loops had been added in their place - lock_parent() still
has one, but that's it.

I'll play with cleaning up and reordering tomorrow after I get
some sleep.  In the meanwhile, the current state of that set is at
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.dcache

Re: [BUG] lock_parent() breakage when used from shrink_dentry_list() (was Re: [PATCH v2 6/6] fs/dcache: Avoid remaining try_lock loop in shrink_dentry_list())

[Al Viro]

On Sat, Feb 24, 2018 at 12:22:48AM +, Al Viro wrote:
> On Fri, Feb 23, 2018 at 01:35:52PM -0800, Linus Torvalds wrote:
> 
> > This is too subtle, and your fix to check d_lockref.count < 0 sounds
> > wrong to me. If it's really gone, maybe it has been reused and the
> > refcount is positive again, but it's something else than a dentry
> > entirely?
> > 
> > Hmm.
> > 
> > No, you extended the rcu read section, so I guess your patch is fine.
> > And lock_parent already has that pattern, soiit's not new.
> > 
> > Ok, I agree, looks like lock_parent should just re-check that thing
> > that it already checked earler, but that now might be true again
> > because of we dropped d_lock.
> 
> IMO that's the right thing for backports; whether we keep it after
> the getting rid of trylock loops is a different question.  Note that
> the only case where we do not have __dentry_kill() prevention
> guaranteed by the caller (either by holding a reference, or by
> holding onto ->i_lock all along) is in shrink_dentry_list().
> And there we have more than enough of other subtle crap.
> 
> Moreover, there we have a good reason to treat "it had been moved"
> as "kick it off the shrink list and free if it's already dead",
> which might simplify the things.  Below is a stab at that:

FWIW, a variant of that series is in #work.dcache; it's
almost certainly not the final (I want to clean the things up
and probably reorder them as well) and it needs one hell of
profiling and review.  It seems to work, and I don't see any
obvious performance regressions (everything seems to be within
normal noise), but I'd like it beaten up a lot more.

Parts are from John's series, parts are rewritten as discussed
upthread.  As the result, trylock loops are gone and no new
retry loops had been added in their place - lock_parent() still
has one, but that's it.

I'll play with cleaning up and reordering tomorrow after I get
some sleep.  In the meanwhile, the current state of that set is at
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.dcache

[PATCH] MAINTAINERS: Add list, tree, and maintainer

[Tobin C. Harding]

MAINTAINERS is out of date for leaking_addresses.pl. There is now a tree on
kernel.org for development of this script.  We have a second maintainer now,
thanks Tycho.  Development of this scripts was started on kernel-hardening
mailing list so let's keep it there.

Update maintainer details; Add mailing list, kernel.org hosted tree, and second
maintainer.

Signed-off-by: Tobin C. Harding 
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3bdc260e36b7..e91b5ff1f5d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7905,8 +7905,11 @@ F:   drivers/scsi/53c700*
 
 LEAKING_ADDRESSES
 M: Tobin C. Harding 
+M: Tycho Andersen 
 S: Maintained
 F: scripts/leaking_addresses.pl
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tobin/leaks.git
+L: kernel-harden...@lists.openwall.com
 
 LED SUBSYSTEM
 M: Richard Purdie 
-- 
2.7.4

[PATCH] MAINTAINERS: Add list, tree, and maintainer

[Tobin C. Harding]

MAINTAINERS is out of date for leaking_addresses.pl. There is now a tree on
kernel.org for development of this script.  We have a second maintainer now,
thanks Tycho.  Development of this scripts was started on kernel-hardening
mailing list so let's keep it there.

Update maintainer details; Add mailing list, kernel.org hosted tree, and second
maintainer.

Signed-off-by: Tobin C. Harding 
---
 MAINTAINERS | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3bdc260e36b7..e91b5ff1f5d5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7905,8 +7905,11 @@ F:   drivers/scsi/53c700*
 
 LEAKING_ADDRESSES
 M: Tobin C. Harding 
+M: Tycho Andersen 
 S: Maintained
 F: scripts/leaking_addresses.pl
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tobin/leaks.git
+L: kernel-harden...@lists.openwall.com
 
 LED SUBSYSTEM
 M: Richard Purdie 
-- 
2.7.4

Re: [PATCH v2] qrtr: add MODULE_ALIAS macro to smd

[Kalle Valo]

Ramon Fried  writes:

> Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
> when IPCRTR channel is detected.
>
> Signed-off-by: Ramon Fried 
>
> V2: Corrected subject line, this is not a part of a patchset.
> ---
>  net/qrtr/smd.c | 1 +
>  1 file changed, 1 insertion(+)

The change log should be after "---" line so that git-am can discard it
automatically. Now the changelog would be part of git commit log and we
don't want that.

So please submit v3.

-- 
Kalle Valo

Re: [PATCH v2] qrtr: add MODULE_ALIAS macro to smd

[Kalle Valo]

Ramon Fried  writes:

> Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
> when IPCRTR channel is detected.
>
> Signed-off-by: Ramon Fried 
>
> V2: Corrected subject line, this is not a part of a patchset.
> ---
>  net/qrtr/smd.c | 1 +
>  1 file changed, 1 insertion(+)

The change log should be after "---" line so that git-am can discard it
automatically. Now the changelog would be part of git commit log and we
don't want that.

So please submit v3.

-- 
Kalle Valo

Consent Proposal

[Mr.zhang]

Important details to share with you, kindly email me for info: 
"zhang...@asia.com" Mr.zhang

Consent Proposal

[Mr.zhang]

Important details to share with you, kindly email me for info: 
"zhang...@asia.com" Mr.zhang

RE: [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU topology

[vkilari]

Hi,

> -Original Message-
> From: linux-arm-kernel
[mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Xiongfeng Wang
> Sent: Saturday, February 24, 2018 8:36 AM
> To: Lorenzo Pieralisi ; Jeremy Linton
> 
> Cc: mark.rutl...@arm.com; jonathan.zh...@cavium.com;
> jayachandran.n...@cavium.com; catalin.mari...@arm.com; Juri Lelli
> ; gre...@linuxfoundation.org; jh...@codeaurora.org;
> r...@rjwysocki.net; linux...@vger.kernel.org; will.dea...@arm.com; linux-
> ker...@vger.kernel.org; morten.rasmus...@arm.com; linux-
> a...@vger.kernel.org; viresh.ku...@linaro.org; hanjun@linaro.org;
> sudeep.ho...@arm.com; austi...@codeaurora.org; vkil...@codeaurora.org;
> a...@redhat.com; linux-arm-ker...@lists.infradead.org; l...@kernel.org
> Subject: Re: [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU
> topology
> 
> 
> Hi,
> On 2018/2/23 19:02, Lorenzo Pieralisi wrote:
> > On Thu, Jan 25, 2018 at 09:56:30AM -0600, Jeremy Linton wrote:
> >> Hi,
> >>
> >> On 01/25/2018 06:15 AM, Xiongfeng Wang wrote:
> >>> Hi Jeremy,
> >>>
> >>> I have tested the patch with the newest UEFI. It prints the below
error:
> >>>
> >>> [4.017371] BUG: arch topology borken
> >>> [4.021069] BUG: arch topology borken
> >>> [4.024764] BUG: arch topology borken
> >>> [4.028460] BUG: arch topology borken
> >>> [4.032153] BUG: arch topology borken
> >>> [4.035849] BUG: arch topology borken
> >>> [4.039543] BUG: arch topology borken
> >>> [4.043239] BUG: arch topology borken
> >>> [4.046932] BUG: arch topology borken
> >>> [4.050629] BUG: arch topology borken
> >>> [4.054322] BUG: arch topology borken
> >>>
> >>> I checked the code and found that the newest UEFI set PPTT
> >>> physical_package_flag on a physical package node and the NUMA domain
> (SRAT domains) starts from the layer of DIE. (The topology of our board is
core-
> >cluster->die->package).
> >>
> >> I commented about that on the EDK2 mailing list. While the current
> >> spec doesn't explicitly ban having the flag set multiple times
> >> between the leaf and the root I consider it a "bug" and there is an
> >> effort to clarify the spec and the use of that flag.
> >>>
> >>> When the kernel starts to build sched_domain, the multi-core
> >>> sched_domain contains all the cores within a package, and the lowest
> >>> NUMA sched_domain contains all the cores within a die. But the kernel
> requires that the multi-core sched_domain should be a subset of the lowest
> NUMA sched_domain, so the BUG info is printed.
> >>
> >> Right. I've mentioned this problem a couple of times.
> >>
> >> At at the moment, the spec isn't clear about how the proximity domain
> >> is detected/located within the PPTT topology (a node with a 1:1
> >> correspondence isn't even required). As you can see from this patch
> >> set, we are making the general assumption that the proximity domains
> >> are at the same level as the physical socket. This isn't ideal for
> >> NUMA topologies, like the D05, that don't align with the physical
socket.
> >>
> >> There are efforts underway to clarify and expand upon the
> >> specification to deal with this general problem. The simple solution
> >> is another flag (say PPTT_PROXIMITY_DOMAIN which would map to the D05
> >> die) which could be used to find nodes with 1:1 correspondence. At
> >> that point we could add a fairly trivial patch to correct just the
> >> scheduler topology without affecting the rest of the system topology
code.
> >
> > I think Morten asked already but isn't this the same end result we end
> > up having if we remove the DIE level if NUMA-within-package is
> > detected (instead of using the default_topology[]) and we create our
> > own ARM64 domain hierarchy (with DIE level removed) through
> > set_sched_topology() accordingly ?

To overcome this, on x86 as well the DIE level is removed when
NUMA-within-package is detected with this patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ar
ch/x86/kernel/smpboot.c?h=v4.16-rc2=8f37961cf22304fb286c7604d3a7f6104dcc1
283

Solving with PPTT would be clean approach instead of overriding
default_topology[]

> >
> > Put it differently: do we really need to rely on another PPTT flag to
> > collect this information ?
> >
> > I can't merge code that breaks a platform with legitimate firmware
> > bindings.
> 
> I think we really need another PPTT flag, from which we can get
information
> about how to build a multi-core sched_domain. I think only cache-sharing
> information is not enough to get information about how to build a
multi-core
> shced_domain.
> 
> How about this? We assume the upper layer of the lowest layer to be multi-
> core layer.
> After that flag is added into ACPI specs, we add another patch to adapt to
the
> change.
> 
> Thanks,
> Xiongfeng
> 
> >
> > Thanks,
> > Lorenzo
> >
> >>
> >>>
> >>> If we modify the UEFI to make NUMA 

RE: [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU topology

[vkilari]

Hi,

> -Original Message-
> From: linux-arm-kernel
[mailto:linux-arm-kernel-boun...@lists.infradead.org]
> On Behalf Of Xiongfeng Wang
> Sent: Saturday, February 24, 2018 8:36 AM
> To: Lorenzo Pieralisi ; Jeremy Linton
> 
> Cc: mark.rutl...@arm.com; jonathan.zh...@cavium.com;
> jayachandran.n...@cavium.com; catalin.mari...@arm.com; Juri Lelli
> ; gre...@linuxfoundation.org; jh...@codeaurora.org;
> r...@rjwysocki.net; linux...@vger.kernel.org; will.dea...@arm.com; linux-
> ker...@vger.kernel.org; morten.rasmus...@arm.com; linux-
> a...@vger.kernel.org; viresh.ku...@linaro.org; hanjun@linaro.org;
> sudeep.ho...@arm.com; austi...@codeaurora.org; vkil...@codeaurora.org;
> a...@redhat.com; linux-arm-ker...@lists.infradead.org; l...@kernel.org
> Subject: Re: [PATCH v6 11/12] arm64: topology: enable ACPI/PPTT based CPU
> topology
> 
> 
> Hi,
> On 2018/2/23 19:02, Lorenzo Pieralisi wrote:
> > On Thu, Jan 25, 2018 at 09:56:30AM -0600, Jeremy Linton wrote:
> >> Hi,
> >>
> >> On 01/25/2018 06:15 AM, Xiongfeng Wang wrote:
> >>> Hi Jeremy,
> >>>
> >>> I have tested the patch with the newest UEFI. It prints the below
error:
> >>>
> >>> [4.017371] BUG: arch topology borken
> >>> [4.021069] BUG: arch topology borken
> >>> [4.024764] BUG: arch topology borken
> >>> [4.028460] BUG: arch topology borken
> >>> [4.032153] BUG: arch topology borken
> >>> [4.035849] BUG: arch topology borken
> >>> [4.039543] BUG: arch topology borken
> >>> [4.043239] BUG: arch topology borken
> >>> [4.046932] BUG: arch topology borken
> >>> [4.050629] BUG: arch topology borken
> >>> [4.054322] BUG: arch topology borken
> >>>
> >>> I checked the code and found that the newest UEFI set PPTT
> >>> physical_package_flag on a physical package node and the NUMA domain
> (SRAT domains) starts from the layer of DIE. (The topology of our board is
core-
> >cluster->die->package).
> >>
> >> I commented about that on the EDK2 mailing list. While the current
> >> spec doesn't explicitly ban having the flag set multiple times
> >> between the leaf and the root I consider it a "bug" and there is an
> >> effort to clarify the spec and the use of that flag.
> >>>
> >>> When the kernel starts to build sched_domain, the multi-core
> >>> sched_domain contains all the cores within a package, and the lowest
> >>> NUMA sched_domain contains all the cores within a die. But the kernel
> requires that the multi-core sched_domain should be a subset of the lowest
> NUMA sched_domain, so the BUG info is printed.
> >>
> >> Right. I've mentioned this problem a couple of times.
> >>
> >> At at the moment, the spec isn't clear about how the proximity domain
> >> is detected/located within the PPTT topology (a node with a 1:1
> >> correspondence isn't even required). As you can see from this patch
> >> set, we are making the general assumption that the proximity domains
> >> are at the same level as the physical socket. This isn't ideal for
> >> NUMA topologies, like the D05, that don't align with the physical
socket.
> >>
> >> There are efforts underway to clarify and expand upon the
> >> specification to deal with this general problem. The simple solution
> >> is another flag (say PPTT_PROXIMITY_DOMAIN which would map to the D05
> >> die) which could be used to find nodes with 1:1 correspondence. At
> >> that point we could add a fairly trivial patch to correct just the
> >> scheduler topology without affecting the rest of the system topology
code.
> >
> > I think Morten asked already but isn't this the same end result we end
> > up having if we remove the DIE level if NUMA-within-package is
> > detected (instead of using the default_topology[]) and we create our
> > own ARM64 domain hierarchy (with DIE level removed) through
> > set_sched_topology() accordingly ?

To overcome this, on x86 as well the DIE level is removed when
NUMA-within-package is detected with this patch
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/ar
ch/x86/kernel/smpboot.c?h=v4.16-rc2=8f37961cf22304fb286c7604d3a7f6104dcc1
283

Solving with PPTT would be clean approach instead of overriding
default_topology[]

> >
> > Put it differently: do we really need to rely on another PPTT flag to
> > collect this information ?
> >
> > I can't merge code that breaks a platform with legitimate firmware
> > bindings.
> 
> I think we really need another PPTT flag, from which we can get
information
> about how to build a multi-core sched_domain. I think only cache-sharing
> information is not enough to get information about how to build a
multi-core
> shced_domain.
> 
> How about this? We assume the upper layer of the lowest layer to be multi-
> core layer.
> After that flag is added into ACPI specs, we add another patch to adapt to
the
> change.
> 
> Thanks,
> Xiongfeng
> 
> >
> > Thanks,
> > Lorenzo
> >
> >>
> >>>
> >>> If we modify the UEFI to make NUMA sched_domain start from the layer
> >>> of package, then all the topology 

[PATCH v2] qrtr: add MODULE_ALIAS macro to smd

[Ramon Fried]

Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.

Signed-off-by: Ramon Fried 

V2: Corrected subject line, this is not a part of a patchset.
---
 net/qrtr/smd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
 
 module_rpmsg_driver(qcom_smd_qrtr_driver);
 
+MODULE_ALIAS("rpmsg:IPCRTR");
 MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
 MODULE_LICENSE("GPL v2");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2] qrtr: add MODULE_ALIAS macro to smd

[Ramon Fried]

Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.

Signed-off-by: Ramon Fried 

V2: Corrected subject line, this is not a part of a patchset.
---
 net/qrtr/smd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
 
 module_rpmsg_driver(qcom_smd_qrtr_driver);
 
+MODULE_ALIAS("rpmsg:IPCRTR");
 MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
 MODULE_LICENSE("GPL v2");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/6] qrtr: add MODULE_ALIAS macro to smd

[Ramon Fried]

Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.

Signed-off-by: Ramon Fried 
---
 net/qrtr/smd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
 
 module_rpmsg_driver(qcom_smd_qrtr_driver);
 
+MODULE_ALIAS("rpmsg:IPCRTR");
 MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
 MODULE_LICENSE("GPL v2");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/6] qrtr: add MODULE_ALIAS macro to smd

[Ramon Fried]

Added MODULE_ALIAS("rpmsg:IPCRTR") to ensure qrtr-smd and qrtr will load
when IPCRTR channel is detected.

Signed-off-by: Ramon Fried 
---
 net/qrtr/smd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/qrtr/smd.c b/net/qrtr/smd.c
index 50615d5efac1..9cf089b9754e 100644
--- a/net/qrtr/smd.c
+++ b/net/qrtr/smd.c
@@ -114,5 +114,6 @@ static struct rpmsg_driver qcom_smd_qrtr_driver = {
 
 module_rpmsg_driver(qcom_smd_qrtr_driver);
 
+MODULE_ALIAS("rpmsg:IPCRTR");
 MODULE_DESCRIPTION("Qualcomm IPC-Router SMD interface driver");
 MODULE_LICENSE("GPL v2");
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] headers: linux/mutex.h: drop linkage.h

[Randy Dunlap]

From: Randy Dunlap 

 does not use nor need , so drop that
one header file from mutex.h.

 is currently #included in around 1250 C source files
(oops, I didn't count other header files that #include it), making it
the 27th most-used header file.

Build tested on i386 and x86_64 * (allnoconfig, tiny.config, defconfig,
allyesconfig, and allmodconfig) and x64_64 allmodconfig + SMP=disabled.

Signed-off-by: Randy Dunlap 
---
Ingo/Thomas, please include this in tip.git for more thorough testing.

 include/linux/mutex.h |1 -
 1 file changed, 1 deletion(-)

--- linux.orig/include/linux/mutex.h
+++ linux.next/include/linux/mutex.h
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

[PATCH] headers: linux/irq.h: drop 5 #included header files

[Randy Dunlap]

From: Randy Dunlap 

 does not use nor need several of its #included files,
so drop those header files from irq.h.

 is currently #included in around 1135 C source files
(oops, I didn't count other header files that #include it), making it
the 29th most-used header file.

Build tested on i386 and x86_64 * (allnoconfig, tiny.config, defconfig,
allyesconfig, and allmodconfig) and x64_64 allmodconfig + SMP=disabled.

Signed-off-by: Randy Dunlap 
---
Ingo/Thomas, please include this in tip.git for more thorough testing.
---
 include/linux/irq.h |5 -
 1 file changed, 5 deletions(-)

--- linux.orig/include/linux/irq.h
+++ linux.next/include/linux/irq.h
@@ -10,18 +10,13 @@
  * Thanks. --rmk
  */
 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 

[PATCH] headers: linux/mutex.h: drop linkage.h

[Randy Dunlap]

From: Randy Dunlap 

 does not use nor need , so drop that
one header file from mutex.h.

 is currently #included in around 1250 C source files
(oops, I didn't count other header files that #include it), making it
the 27th most-used header file.

Build tested on i386 and x86_64 * (allnoconfig, tiny.config, defconfig,
allyesconfig, and allmodconfig) and x64_64 allmodconfig + SMP=disabled.

Signed-off-by: Randy Dunlap 
---
Ingo/Thomas, please include this in tip.git for more thorough testing.

 include/linux/mutex.h |1 -
 1 file changed, 1 deletion(-)

--- linux.orig/include/linux/mutex.h
+++ linux.next/include/linux/mutex.h
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 

[PATCH] headers: linux/irq.h: drop 5 #included header files

[Randy Dunlap]

From: Randy Dunlap 

 does not use nor need several of its #included files,
so drop those header files from irq.h.

 is currently #included in around 1135 C source files
(oops, I didn't count other header files that #include it), making it
the 29th most-used header file.

Build tested on i386 and x86_64 * (allnoconfig, tiny.config, defconfig,
allyesconfig, and allmodconfig) and x64_64 allmodconfig + SMP=disabled.

Signed-off-by: Randy Dunlap 
---
Ingo/Thomas, please include this in tip.git for more thorough testing.
---
 include/linux/irq.h |5 -
 1 file changed, 5 deletions(-)

--- linux.orig/include/linux/irq.h
+++ linux.next/include/linux/irq.h
@@ -10,18 +10,13 @@
  * Thanks. --rmk
  */
 
-#include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 

Re: [BUG] arm64: Build error with gcc 6

[Baruch Siach]

Hi Masami Hiramatsu,

On Sun, Feb 25, 2018 at 11:50:37AM +0900, Masami Hiramatsu wrote:
> commit e1a50de37860 ("arm64: cputype: Silence Sparse warnings")
> introduces "UL" suffix to a hex number, but it causes a build error with 
> gcc-6 series.
> I've hit below error with 6.2.1 and 6.4.1. Of course this is resolved by the 
> latest
> stable gcc-7.2.1. But from the compatibility point of view, should we revert 
> it?
> 
>   AS  arch/arm64/kernel/head.o
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S: Assembler messages:
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
> expected: ')'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
> expected: ')'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
> expected: ')'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: junk at end of 
> line, first unrecognized character is `L'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: unexpected 
> characters following instruction at operand 2 -- `movz 
> x1,:abs_g1_s:0xff00ffUL'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: unexpected 
> characters following instruction at operand 2 -- `movk 
> x1,:abs_g0_nc:0xff00ffUL'
> make[2]: *** [/home/mhiramat/ksrc/linux/scripts/Makefile.build:425: 
> arch/arm64/kernel/head.o] error 1
> 
> I've checked with below 2 latest gccs.
> 
> http://releases.linaro.org/components/toolchain/binaries/latest-6/aarch64-linux-gnu/gcc-linaro-6.4.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz
> 
> http://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz

The fix is pending:

https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=fixes/core=04c4927359b1f09310bfee92e7187c9022be3e00

This is in Linus' tree now, so should be in -rc3.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [BUG] arm64: Build error with gcc 6

[Baruch Siach]

Hi Masami Hiramatsu,

On Sun, Feb 25, 2018 at 11:50:37AM +0900, Masami Hiramatsu wrote:
> commit e1a50de37860 ("arm64: cputype: Silence Sparse warnings")
> introduces "UL" suffix to a hex number, but it causes a build error with 
> gcc-6 series.
> I've hit below error with 6.2.1 and 6.4.1. Of course this is resolved by the 
> latest
> stable gcc-7.2.1. But from the compatibility point of view, should we revert 
> it?
> 
>   AS  arch/arm64/kernel/head.o
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S: Assembler messages:
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
> expected: ')'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
> expected: ')'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
> expected: ')'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: junk at end of 
> line, first unrecognized character is `L'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: unexpected 
> characters following instruction at operand 2 -- `movz 
> x1,:abs_g1_s:0xff00ffUL'
> /home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: unexpected 
> characters following instruction at operand 2 -- `movk 
> x1,:abs_g0_nc:0xff00ffUL'
> make[2]: *** [/home/mhiramat/ksrc/linux/scripts/Makefile.build:425: 
> arch/arm64/kernel/head.o] error 1
> 
> I've checked with below 2 latest gccs.
> 
> http://releases.linaro.org/components/toolchain/binaries/latest-6/aarch64-linux-gnu/gcc-linaro-6.4.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz
> 
> http://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz

The fix is pending:

https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/commit/?h=fixes/core=04c4927359b1f09310bfee92e7187c9022be3e00

This is in Linus' tree now, so should be in -rc3.

baruch

-- 
 http://baruch.siach.name/blog/  ~. .~   Tk Open Systems
=}ooO--U--Ooo{=
   - bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2]
[cannot apply to next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/genalloc-track-beginning-of-allocations/20180225-081601
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "pmalloc" [drivers/misc/lkdtm.ko] undefined!
>> ERROR: "pmalloc_create_pool" [drivers/misc/lkdtm.ko] undefined!
>> ERROR: "pmalloc_destroy_pool" [drivers/misc/lkdtm.ko] undefined!
>> ERROR: "pmalloc_protect_pool" [drivers/misc/lkdtm.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 6/7] lkdtm: crash on overwriting protected pmalloc var

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2]
[cannot apply to next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/genalloc-track-beginning-of-allocations/20180225-081601
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "pmalloc" [drivers/misc/lkdtm.ko] undefined!
>> ERROR: "pmalloc_create_pool" [drivers/misc/lkdtm.ko] undefined!
>> ERROR: "pmalloc_destroy_pool" [drivers/misc/lkdtm.ko] undefined!
>> ERROR: "pmalloc_protect_pool" [drivers/misc/lkdtm.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 3/7] struct page: add field for vm_struct

[Matthew Wilcox]

On Fri, Feb 23, 2018 at 04:48:03PM +0200, Igor Stoppa wrote:
> @@ -1769,6 +1771,9 @@ void *__vmalloc_node_range(unsigned long size, unsigned 
> long align,
>  
>   kmemleak_vmalloc(area, size, gfp_mask);
>  
> + for (i = 0; i < area->nr_pages; i++)
> + area->pages[i]->area = area;
> +
>   return addr;
>  
>  fail:

IMO, this is the wrong place to initialise the page->area.  It should be
done in __vmalloc_area_node() like so:

area->nr_pages = i;
goto fail;
}
+   page->area = area;
area->pages[i] = page;
if (gfpflags_allow_blocking(gfp_mask))
cond_resched();

Re: [PATCH 3/7] struct page: add field for vm_struct

[Matthew Wilcox]

On Fri, Feb 23, 2018 at 04:48:03PM +0200, Igor Stoppa wrote:
> @@ -1769,6 +1771,9 @@ void *__vmalloc_node_range(unsigned long size, unsigned 
> long align,
>  
>   kmemleak_vmalloc(area, size, gfp_mask);
>  
> + for (i = 0; i < area->nr_pages; i++)
> + area->pages[i]->area = area;
> +
>   return addr;
>  
>  fail:

IMO, this is the wrong place to initialise the page->area.  It should be
done in __vmalloc_area_node() like so:

area->nr_pages = i;
goto fail;
}
+   page->area = area;
area->pages[i] = page;
if (gfpflags_allow_blocking(gfp_mask))
cond_resched();

Re: [PATCH 4.15 00/45] 4.15.6-stable review

[Dan Rue]

On Fri, Feb 23, 2018 at 07:28:39PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.15.6 release.
> There are 45 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Feb 25 17:06:43 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.6-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.15.6-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: 82ca63fd5c3280300c175fd372b9049c196d5676
git describe: v4.15.5-46-g82ca63fd5c32
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.5-46-g82ca63fd5c32


No regressions (compared to build v4.15.5-42-gf40984b50e73)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 57, skip: 9
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 21,
* kselftest - pass: 56, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 6,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 53, skip: 12
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, skip: 18
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 71, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1


--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 1/7] genalloc: track beginning of allocations

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/genalloc-track-beginning-of-allocations/20180225-081601
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: the 
linux-review/Igor-Stoppa/genalloc-track-beginning-of-allocations/20180225-081601
 HEAD 9c42e8278ff35263f8381461592f6737e4b7b129 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> ERROR: "gen_pool_best_fit" [drivers/tee/tee.ko] undefined!
   ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined!
   ERROR: "ia64_delay_loop" [drivers/net/phy/mdio-cavium.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 4.15 00/45] 4.15.6-stable review

[Dan Rue]

On Fri, Feb 23, 2018 at 07:28:39PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.15.6 release.
> There are 45 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Feb 25 17:06:43 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.15.6-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.15.y
> and the diffstat can be found below.

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.15.6-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.15.y
git commit: 82ca63fd5c3280300c175fd372b9049c196d5676
git describe: v4.15.5-46-g82ca63fd5c32
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.15-oe/build/v4.15.5-46-g82ca63fd5c32


No regressions (compared to build v4.15.5-42-gf40984b50e73)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 57, skip: 9
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 21,
* kselftest - pass: 56, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 6,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 53, skip: 12
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 63, skip: 18
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 71, skip: 10
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1


--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 1/7] genalloc: track beginning of allocations

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2 next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/genalloc-track-beginning-of-allocations/20180225-081601
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

Note: the 
linux-review/Igor-Stoppa/genalloc-track-beginning-of-allocations/20180225-081601
 HEAD 9c42e8278ff35263f8381461592f6737e4b7b129 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> ERROR: "gen_pool_best_fit" [drivers/tee/tee.ko] undefined!
   ERROR: "ia64_delay_loop" [drivers/spi/spi-thunderx.ko] undefined!
   ERROR: "ia64_delay_loop" [drivers/net/phy/mdio-cavium.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 4.9 000/145] 4.9.84-stable review

[Dan Rue]

On Fri, Feb 23, 2018 at 07:25:06PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.84 release.
> There are 145 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Feb 25 17:06:27 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.84-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.84-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: e908a050f46f7e7a84e2f8ba03c7398df8120ab4
git describe: v4.9.83-146-ge908a050f46f
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.83-146-ge908a050f46f


No regressions (compared to build v4.9.83-88-g5623ac747984)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 40, skip: 24
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 42, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 39, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 54, skip: 27
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1


--
Linaro QA (beta)
https://qa-reports.linaro.org

Re: [PATCH 4.9 000/145] 4.9.84-stable review

[Dan Rue]

On Fri, Feb 23, 2018 at 07:25:06PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.84 release.
> There are 145 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
> 
> Responses should be made by Sun Feb 25 17:06:27 UTC 2018.
> Anything received after that time might be too late.
> 
> The whole patch series can be found in one patch at:
>   
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.84-rc1.gz
> or in the git tree and branch at:
>   
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.

Results from Linaro’s test farm.
No regressions on arm64, arm and x86_64.

Summary


kernel: 4.9.84-rc1
git repo:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: e908a050f46f7e7a84e2f8ba03c7398df8120ab4
git describe: v4.9.83-146-ge908a050f46f
Test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.83-146-ge908a050f46f


No regressions (compared to build v4.9.83-88-g5623ac747984)

Boards, architectures and test suites:
-

hi6220-hikey - arm64
* boot - pass: 20,
* kselftest - pass: 40, skip: 24
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 21, skip: 1
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 999, skip: 151
* ltp-timers-tests - pass: 12, skip: 1

juno-r2 - arm64
* boot - pass: 20,
* kselftest - pass: 42, skip: 23
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 10, skip: 4
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1001, skip: 149
* ltp-timers-tests - pass: 12, skip: 1

x15 - arm
* boot - pass: 20,
* kselftest - pass: 39, skip: 25
* libhugetlbfs - pass: 87, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 61, skip: 2
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 20, skip: 2
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 13, skip: 1
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1053, skip: 97
* ltp-timers-tests - pass: 12, skip: 1

x86_64
* boot - pass: 20,
* kselftest - pass: 54, skip: 27
* libhugetlbfs - pass: 90, skip: 1
* ltp-cap_bounds-tests - pass: 2,
* ltp-containers-tests - pass: 64, skip: 17
* ltp-fcntl-locktests-tests - pass: 2,
* ltp-filecaps-tests - pass: 2,
* ltp-fs-tests - pass: 62, skip: 1
* ltp-fs_bind-tests - pass: 2,
* ltp-fs_perms_simple-tests - pass: 19,
* ltp-fsx-tests - pass: 2,
* ltp-hugetlb-tests - pass: 22,
* ltp-io-tests - pass: 3,
* ltp-ipc-tests - pass: 9,
* ltp-math-tests - pass: 11,
* ltp-nptl-tests - pass: 2,
* ltp-pty-tests - pass: 4,
* ltp-sched-tests - pass: 9, skip: 5
* ltp-securebits-tests - pass: 4,
* ltp-syscalls-tests - pass: 1031, skip: 119
* ltp-timers-tests - pass: 12, skip: 1


--
Linaro QA (beta)
https://qa-reports.linaro.org

[BUG] arm64: Build error with gcc 6

[Masami Hiramatsu]

Hello,

commit e1a50de37860 ("arm64: cputype: Silence Sparse warnings")
introduces "UL" suffix to a hex number, but it causes a build error with gcc-6 
series.
I've hit below error with 6.2.1 and 6.4.1. Of course this is resolved by the 
latest
stable gcc-7.2.1. But from the compatibility point of view, should we revert it?

  AS  arch/arm64/kernel/head.o
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S: Assembler messages:
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
expected: ')'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
expected: ')'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
expected: ')'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: junk at end of 
line, first unrecognized character is `L'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: unexpected 
characters following instruction at operand 2 -- `movz 
x1,:abs_g1_s:0xff00ffUL'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: unexpected 
characters following instruction at operand 2 -- `movk 
x1,:abs_g0_nc:0xff00ffUL'
make[2]: *** [/home/mhiramat/ksrc/linux/scripts/Makefile.build:425: 
arch/arm64/kernel/head.o] error 1

I've checked with below 2 latest gccs.

http://releases.linaro.org/components/toolchain/binaries/latest-6/aarch64-linux-gnu/gcc-linaro-6.4.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz

http://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz

Thank you,

-- 
Masami Hiramatsu 

[BUG] arm64: Build error with gcc 6

[Masami Hiramatsu]

Hello,

commit e1a50de37860 ("arm64: cputype: Silence Sparse warnings")
introduces "UL" suffix to a hex number, but it causes a build error with gcc-6 
series.
I've hit below error with 6.2.1 and 6.4.1. Of course this is resolved by the 
latest
stable gcc-7.2.1. But from the compatibility point of view, should we revert it?

  AS  arch/arm64/kernel/head.o
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S: Assembler messages:
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
expected: ')'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
expected: ')'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: found 'L', 
expected: ')'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: junk at end of 
line, first unrecognized character is `L'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: unexpected 
characters following instruction at operand 2 -- `movz 
x1,:abs_g1_s:0xff00ffUL'
/home/mhiramat/ksrc/linux/arch/arm64/kernel/head.S:677: Error: unexpected 
characters following instruction at operand 2 -- `movk 
x1,:abs_g0_nc:0xff00ffUL'
make[2]: *** [/home/mhiramat/ksrc/linux/scripts/Makefile.build:425: 
arch/arm64/kernel/head.o] error 1

I've checked with below 2 latest gccs.

http://releases.linaro.org/components/toolchain/binaries/latest-6/aarch64-linux-gnu/gcc-linaro-6.4.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz

http://releases.linaro.org/components/toolchain/binaries/latest-7/aarch64-linux-gnu/gcc-linaro-7.2.1-2017.11-x86_64_aarch64-linux-gnu.tar.xz

Thank you,

-- 
Masami Hiramatsu 

Re: [PATCH 4/7] Protectable Memory

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2]
[cannot apply to next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/genalloc-track-beginning-of-allocations/20180225-081601
config: arm-allnoconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   mm/pmalloc.o: In function `pmalloc_prealloc':
>> pmalloc.c:(.text+0x280): undefined reference to `vfree_atomic'
   mm/pmalloc.o: In function `pmalloc':
   pmalloc.c:(.text+0x2c4): undefined reference to `vfree_atomic'
   mm/pmalloc.o: In function `pmalloc_chunk_free':
   pmalloc.c:(.text+0x9e): undefined reference to `vfree_atomic'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 4/7] Protectable Memory

[kbuild test robot]

Hi Igor,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linus/master]
[also build test ERROR on v4.16-rc2]
[cannot apply to next-20180223]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Igor-Stoppa/genalloc-track-beginning-of-allocations/20180225-081601
config: arm-allnoconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   mm/pmalloc.o: In function `pmalloc_prealloc':
>> pmalloc.c:(.text+0x280): undefined reference to `vfree_atomic'
   mm/pmalloc.o: In function `pmalloc':
   pmalloc.c:(.text+0x2c4): undefined reference to `vfree_atomic'
   mm/pmalloc.o: In function `pmalloc_chunk_free':
   pmalloc.c:(.text+0x9e): undefined reference to `vfree_atomic'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

DMA map SG ignores DMA mask or don't report error

[Aron]

Hello,


tl;dr: Custom PCIe FPGA board, custom driver: dma_map_sg() and dma_set_mask() 
do not report any error, the dma addresses are bigger than the useable address 
space (30 bit).


I'm trying to write a direct I/O driver for a custom PCIe FPGA board (for my 
MSc thesis). I would like to use streaming scatter/gather DMA mapping to 
transfer large buffers between user space application and the FPGA.

I have set up the PCIe IP core in the FPGA to map the first 1 GB of the 
internal (AXI bus) address space to the host (so there is address space left 
for other internal peripherals).

In the driver in the PCIe probe function I call the dma_set_mask() and the 
dma_set_coherent_mask() to inform the kernel my device only can use 30 bit 
addressing, both returns 0. (I have found that this does not guarantees that I 
can use DMA [1].)

I use get_user_pages_fast() to get the pages of the user space buffer, and 
populate the scatter/gather list. After that I use the dma_map_sg() to set the 
dma addresses in the sg list, the return value of the dma_map_sg() is the same 
as the nents parameter (the number of pages returned by get_user_pages_fast()).
The DMA-API documentation says the dma_map_sg() returns 0 if it fails [2]. But 
the dma addresses in the sg list are grater than 1 GB (they can not be 
addressed with only 30 bits).

I have found in the drivers/usb/core/usb.c that "generic api broken like pci, 
can't report errors" [3]
so if this is true the dma_map_sg() will not report any errors if the dma 
addresses can't be used with the current DMA mask?


Questions:
How can / should I detect this? It is sufficient to looping trough the sg list 
and comparing the dma address with the mask?
Or this whole thing (30 bit addressing) is a bad practice? Should I put more 
effort to make possible to use the full 32 bit address space form the FPGA/PCIe?


Results:
Coherent DMA mapping works file, the dma address is 0x2.
One page streaming DMA mapping reports error (dma_mapping_error() after 
dma_map_page()), dma address is 0xddff8000 (> 1 GB / 30 bit).
Scatter-gather streaming DMA mapping reports no error, but I get dma address 
somewhere 0xd85d (> 1 GB / 30 bit).

Kernel: 4.9.65-3+deb9u2~bpo8+1 (debian jessie-backports)
Memory: 16 GB
CPU: i7-3930K
Motherboard: Asus P9X79


Thank you,
Aron


 [1] https://lkml.org/lkml/2016/10/17/531
 [2] https://www.kernel.org/doc/Documentation/DMA-API.txt
 [3] 
https://elixir.bootlin.com/linux/v4.15.5/source/drivers/usb/core/usb.c#L1069

DMA map SG ignores DMA mask or don't report error

[Aron]

Hello,


tl;dr: Custom PCIe FPGA board, custom driver: dma_map_sg() and dma_set_mask() 
do not report any error, the dma addresses are bigger than the useable address 
space (30 bit).


I'm trying to write a direct I/O driver for a custom PCIe FPGA board (for my 
MSc thesis). I would like to use streaming scatter/gather DMA mapping to 
transfer large buffers between user space application and the FPGA.

I have set up the PCIe IP core in the FPGA to map the first 1 GB of the 
internal (AXI bus) address space to the host (so there is address space left 
for other internal peripherals).

In the driver in the PCIe probe function I call the dma_set_mask() and the 
dma_set_coherent_mask() to inform the kernel my device only can use 30 bit 
addressing, both returns 0. (I have found that this does not guarantees that I 
can use DMA [1].)

I use get_user_pages_fast() to get the pages of the user space buffer, and 
populate the scatter/gather list. After that I use the dma_map_sg() to set the 
dma addresses in the sg list, the return value of the dma_map_sg() is the same 
as the nents parameter (the number of pages returned by get_user_pages_fast()).
The DMA-API documentation says the dma_map_sg() returns 0 if it fails [2]. But 
the dma addresses in the sg list are grater than 1 GB (they can not be 
addressed with only 30 bits).

I have found in the drivers/usb/core/usb.c that "generic api broken like pci, 
can't report errors" [3]
so if this is true the dma_map_sg() will not report any errors if the dma 
addresses can't be used with the current DMA mask?


Questions:
How can / should I detect this? It is sufficient to looping trough the sg list 
and comparing the dma address with the mask?
Or this whole thing (30 bit addressing) is a bad practice? Should I put more 
effort to make possible to use the full 32 bit address space form the FPGA/PCIe?


Results:
Coherent DMA mapping works file, the dma address is 0x2.
One page streaming DMA mapping reports error (dma_mapping_error() after 
dma_map_page()), dma address is 0xddff8000 (> 1 GB / 30 bit).
Scatter-gather streaming DMA mapping reports no error, but I get dma address 
somewhere 0xd85d (> 1 GB / 30 bit).

Kernel: 4.9.65-3+deb9u2~bpo8+1 (debian jessie-backports)
Memory: 16 GB
CPU: i7-3930K
Motherboard: Asus P9X79


Thank you,
Aron


 [1] https://lkml.org/lkml/2016/10/17/531
 [2] https://www.kernel.org/doc/Documentation/DMA-API.txt
 [3] 
https://elixir.bootlin.com/linux/v4.15.5/source/drivers/usb/core/usb.c#L1069

[PATCH] pwm: sun4i: properly check current state

[Alexandre Belloni]

Correctly extract the prescaler value from CTRL_REG before comparing it to
PWM_PRESCAL_MASK.

Also, check that both PWM_CLK_GATING and PWM_EN to ensure the PWM is
enabled instead of relying on only one of those.

Fixes: 93e0dfb2c52f ("pwm: sun4i: Improve hardware read out")
Signed-off-by: Alexandre Belloni 
---
 drivers/pwm/pwm-sun4i.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 334199c58f1d..42e6f0873d1c 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -117,7 +117,8 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
 
val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
 
-   if ((val == PWM_PRESCAL_MASK) && sun4i_pwm->data->has_prescaler_bypass)
+   if ((PWM_REG_PRESCAL(val, pwm->hwpwm) == PWM_PRESCAL_MASK) &&
+   sun4i_pwm->data->has_prescaler_bypass)
prescaler = 1;
else
prescaler = prescaler_table[PWM_REG_PRESCAL(val, pwm->hwpwm)];
@@ -130,7 +131,8 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
else
state->polarity = PWM_POLARITY_INVERSED;
 
-   if (val & BIT_CH(PWM_CLK_GATING | PWM_EN, pwm->hwpwm))
+   if ((val & BIT_CH(PWM_CLK_GATING | PWM_EN, pwm->hwpwm)) ==
+   BIT_CH(PWM_CLK_GATING | PWM_EN, pwm->hwpwm))
state->enabled = true;
else
state->enabled = false;
-- 
2.16.1

[PATCH] pwm: sun4i: properly check current state

[Alexandre Belloni]

Correctly extract the prescaler value from CTRL_REG before comparing it to
PWM_PRESCAL_MASK.

Also, check that both PWM_CLK_GATING and PWM_EN to ensure the PWM is
enabled instead of relying on only one of those.

Fixes: 93e0dfb2c52f ("pwm: sun4i: Improve hardware read out")
Signed-off-by: Alexandre Belloni 
---
 drivers/pwm/pwm-sun4i.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 334199c58f1d..42e6f0873d1c 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -117,7 +117,8 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
 
val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
 
-   if ((val == PWM_PRESCAL_MASK) && sun4i_pwm->data->has_prescaler_bypass)
+   if ((PWM_REG_PRESCAL(val, pwm->hwpwm) == PWM_PRESCAL_MASK) &&
+   sun4i_pwm->data->has_prescaler_bypass)
prescaler = 1;
else
prescaler = prescaler_table[PWM_REG_PRESCAL(val, pwm->hwpwm)];
@@ -130,7 +131,8 @@ static void sun4i_pwm_get_state(struct pwm_chip *chip,
else
state->polarity = PWM_POLARITY_INVERSED;
 
-   if (val & BIT_CH(PWM_CLK_GATING | PWM_EN, pwm->hwpwm))
+   if ((val & BIT_CH(PWM_CLK_GATING | PWM_EN, pwm->hwpwm)) ==
+   BIT_CH(PWM_CLK_GATING | PWM_EN, pwm->hwpwm))
state->enabled = true;
else
state->enabled = false;
-- 
2.16.1

Logitech webcam USB audio breakage during the 4.10 merge window

[Marius Cirsta]

 I have a problem that was previously reported here:

https://www.spinics.net/lists/linux-usb/msg156999.html

 It seems that with the 4.10-rc1 kernel a regression was introduced
that makes my Logitech C310 microphone record a distorted ( chipmunk )
sound. With the 4.9.1 kernel it works perfectly.

 Immediately after I plug it into the USB port all is fine but after a
few minutes this problem occurs.

 Also if add this the kernel cmd line :  usbcore.autosuspend=-1  it
also works fine.

 One other thing that I've noticed is that if I make the sampling rate
22K it again works fine so only the 44K and 48K sampling rates have
this problem but unfortunately those are the default that Chromium for
instance uses ( it gets them from pulseaudio )


Let me know if you need any more details or testing.

Regards,

Marius Cirsta   ,

mfor...@gmail.com

Logitech webcam USB audio breakage during the 4.10 merge window

[Marius Cirsta]

 I have a problem that was previously reported here:

https://www.spinics.net/lists/linux-usb/msg156999.html

 It seems that with the 4.10-rc1 kernel a regression was introduced
that makes my Logitech C310 microphone record a distorted ( chipmunk )
sound. With the 4.9.1 kernel it works perfectly.

 Immediately after I plug it into the USB port all is fine but after a
few minutes this problem occurs.

 Also if add this the kernel cmd line :  usbcore.autosuspend=-1  it
also works fine.

 One other thing that I've noticed is that if I make the sampling rate
22K it again works fine so only the 44K and 48K sampling rates have
this problem but unfortunately those are the default that Chromium for
instance uses ( it gets them from pulseaudio )


Let me know if you need any more details or testing.

Regards,

Marius Cirsta   ,

mfor...@gmail.com

Re: [PATCH v0 1/3] livepatch: add sample cumulative patch

[Philippe Ombredanne]

Joe,

On Fri, Feb 23, 2018 at 1:33 PM, Joe Lawrence  wrote:
> Add a simple atomic replace / cumulative livepatch example.
>
> Signed-off-by: Joe Lawrence 
> ---
>  samples/livepatch/Makefile   |   1 +
>  samples/livepatch/livepatch-cumulative.c | 216 
> +++
>  2 files changed, 217 insertions(+)
>  create mode 100644 samples/livepatch/livepatch-cumulative.c
>
> diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
> index 2472ce39a18d..dd0e2a8af1af 100644
> --- a/samples/livepatch/Makefile
> +++ b/samples/livepatch/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-shadow-fix2.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-demo.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-mod.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-busymod.o
> +obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-cumulative.o
> diff --git a/samples/livepatch/livepatch-cumulative.c 
> b/samples/livepatch/livepatch-cumulative.c
> new file mode 100644
> index ..ab036439e08c
> --- /dev/null
> +++ b/samples/livepatch/livepatch-cumulative.c
> @@ -0,0 +1,216 @@
> +/*
> + * Copyright (C) 2018 Joe Lawrence 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */

May be you could use the new SPDX tags instead of this fine but long
legalese? [1]
This would replace ~12 lines of comment by a single line with the same effect.
Thanks!

[1]  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst
--
Philippe

Re: [PATCH v0 1/3] livepatch: add sample cumulative patch

[Philippe Ombredanne]

Joe,

On Fri, Feb 23, 2018 at 1:33 PM, Joe Lawrence  wrote:
> Add a simple atomic replace / cumulative livepatch example.
>
> Signed-off-by: Joe Lawrence 
> ---
>  samples/livepatch/Makefile   |   1 +
>  samples/livepatch/livepatch-cumulative.c | 216 
> +++
>  2 files changed, 217 insertions(+)
>  create mode 100644 samples/livepatch/livepatch-cumulative.c
>
> diff --git a/samples/livepatch/Makefile b/samples/livepatch/Makefile
> index 2472ce39a18d..dd0e2a8af1af 100644
> --- a/samples/livepatch/Makefile
> +++ b/samples/livepatch/Makefile
> @@ -5,3 +5,4 @@ obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-shadow-fix2.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-demo.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-mod.o
>  obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-callbacks-busymod.o
> +obj-$(CONFIG_SAMPLE_LIVEPATCH) += livepatch-cumulative.o
> diff --git a/samples/livepatch/livepatch-cumulative.c 
> b/samples/livepatch/livepatch-cumulative.c
> new file mode 100644
> index ..ab036439e08c
> --- /dev/null
> +++ b/samples/livepatch/livepatch-cumulative.c
> @@ -0,0 +1,216 @@
> +/*
> + * Copyright (C) 2018 Joe Lawrence 
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see .
> + */

May be you could use the new SPDX tags instead of this fine but long
legalese? [1]
This would replace ~12 lines of comment by a single line with the same effect.
Thanks!

[1]  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst
--
Philippe

Re: mmotm 2018-02-21-14-48 uploaded (mm/page_alloc.c on UML)

[Eugeniu Rosca]

Hello Andrew, Michal,

On Thu, Feb 22, 2018 at 02:26:30PM +0100, Michal Hocko wrote:
> On Thu 22-02-18 14:08:14, Eugeniu Rosca wrote:
> > On Thu, Feb 22, 2018 at 01:59:55PM +0100, Michal Hocko wrote:
> > > On Thu 22-02-18 11:38:32, Eugeniu Rosca wrote:
> > > > Hi Michal,
> > > > 
> > > > Please, let me know if any action is expected from my end.
> > > 
> > > I do not thing anything is really needed right now. If you have a strong
> > > opinion about the solution (ifdef vs. noop stub) then speak up.
> > 
> > No different preference on my side. I was more thinking if you are going
> > to amend the patch or create a fix on top of it. Since it didn't reach
> > mainline, it makes sense to amend it. If you can do it without the
> > intervention of the author, that's also fine for me.
> 
> Andrew usually takes the incremental fix and then squash them when
> sending to Linus

This may sound like bikeshedding, but if commit [1] is squashed onto [2],
the resulted commit will pointlessly relocate the ifdef line, like seen
in [3]. Feel free to skip this comment/request, but imho applying [4] on
top of [1] would then result in a cleaner squashed commit. No functional
change is intended here. TIA.

[1] linux-next commit 5fd667a8c762 
("mm-page_alloc-skip-over-regions-of-invalid-pfns-on-uma-fix")
[2] linux-next commit 72a571e91476 ("mm: page_alloc: skip over regions of 
invalid pfns on UMA")

[3] Ugly and unneeded ifdef line relocation
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cb416723538f..a89b029985ef 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5355,12 +5355,12 @@ void __meminit memmap_init_zone(unsigned long size, int 
nid, unsigned long zone,
goto not_early;

if (!early_pfn_valid(pfn)) {
-#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
/*
 * Skip to the pfn preceding the next valid one (or
 * end_pfn), such that we hit a valid pfn (or end_pfn)
 * on our next iteration of the loop.
 */
+#ifdef CONFIG_HAVE_MEMBLOCK
pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
 #endif
continue;


[4] Patch to be applied on top of [1], for a cleaner squashed commit.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a89b029985ef..10cbf9f1fb35 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5355,12 +5355,12 @@ void __meminit memmap_init_zone(unsigned long size, int 
nid, unsigned long zone,
goto not_early;

if (!early_pfn_valid(pfn)) {
+#ifdef CONFIG_HAVE_MEMBLOCK
/*
 * Skip to the pfn preceding the next valid one (or
 * end_pfn), such that we hit a valid pfn (or end_pfn)
 * on our next iteration of the loop.
 */
-#ifdef CONFIG_HAVE_MEMBLOCK
pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
 #endif
continue;

Best regards,
Eugeniu.

Re: mmotm 2018-02-21-14-48 uploaded (mm/page_alloc.c on UML)

[Eugeniu Rosca]

Hello Andrew, Michal,

On Thu, Feb 22, 2018 at 02:26:30PM +0100, Michal Hocko wrote:
> On Thu 22-02-18 14:08:14, Eugeniu Rosca wrote:
> > On Thu, Feb 22, 2018 at 01:59:55PM +0100, Michal Hocko wrote:
> > > On Thu 22-02-18 11:38:32, Eugeniu Rosca wrote:
> > > > Hi Michal,
> > > > 
> > > > Please, let me know if any action is expected from my end.
> > > 
> > > I do not thing anything is really needed right now. If you have a strong
> > > opinion about the solution (ifdef vs. noop stub) then speak up.
> > 
> > No different preference on my side. I was more thinking if you are going
> > to amend the patch or create a fix on top of it. Since it didn't reach
> > mainline, it makes sense to amend it. If you can do it without the
> > intervention of the author, that's also fine for me.
> 
> Andrew usually takes the incremental fix and then squash them when
> sending to Linus

This may sound like bikeshedding, but if commit [1] is squashed onto [2],
the resulted commit will pointlessly relocate the ifdef line, like seen
in [3]. Feel free to skip this comment/request, but imho applying [4] on
top of [1] would then result in a cleaner squashed commit. No functional
change is intended here. TIA.

[1] linux-next commit 5fd667a8c762 
("mm-page_alloc-skip-over-regions-of-invalid-pfns-on-uma-fix")
[2] linux-next commit 72a571e91476 ("mm: page_alloc: skip over regions of 
invalid pfns on UMA")

[3] Ugly and unneeded ifdef line relocation
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index cb416723538f..a89b029985ef 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5355,12 +5355,12 @@ void __meminit memmap_init_zone(unsigned long size, int 
nid, unsigned long zone,
goto not_early;

if (!early_pfn_valid(pfn)) {
-#ifdef CONFIG_HAVE_MEMBLOCK_NODE_MAP
/*
 * Skip to the pfn preceding the next valid one (or
 * end_pfn), such that we hit a valid pfn (or end_pfn)
 * on our next iteration of the loop.
 */
+#ifdef CONFIG_HAVE_MEMBLOCK
pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
 #endif
continue;


[4] Patch to be applied on top of [1], for a cleaner squashed commit.
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index a89b029985ef..10cbf9f1fb35 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -5355,12 +5355,12 @@ void __meminit memmap_init_zone(unsigned long size, int 
nid, unsigned long zone,
goto not_early;

if (!early_pfn_valid(pfn)) {
+#ifdef CONFIG_HAVE_MEMBLOCK
/*
 * Skip to the pfn preceding the next valid one (or
 * end_pfn), such that we hit a valid pfn (or end_pfn)
 * on our next iteration of the loop.
 */
-#ifdef CONFIG_HAVE_MEMBLOCK
pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1;
 #endif
continue;

Best regards,
Eugeniu.

Re: 500 ms delay in time saved into RTC

[Alexandre Belloni]

Hi,

On 19/02/2018 at 12:03:28 +0100, Karel Zak wrote:
> On Mon, Feb 19, 2018 at 08:11:05AM +0100, Rasmus Villemoes wrote:
> > It's because util-linux's hwclock still assumes the world is x86. See
> > this comment in the util-linux source code:
> > 
> > /*
> >  * The Hardware Clock can only be set to any integer time plus one
> >  * half second.  The integer time is required because there is no
> >  * interface to set or get a fractional second.  The additional half
> >  * second is because the Hardware Clock updates to the following
> >  * second precisely 500 ms (not 1 second!) after you release the
> >  * divider reset (after setting the new time) - see description of
> >  * DV2, DV1, DV0 in Register A in the MC146818A data sheet (and note
> > 
> > So if hwclock is asked to --systohc at time 01:02:03.x, it waits until
> > the time is 01:02:03.5 to set the rtc to 01:02:03, or if that has
> > already passed, waits until  01:02:04.5 and sets it to 01:02:04.
> > 
> > On our ARM BSP we patch util-linux to have the "implicit fractional
> > part" configurable, and trying to upstream something like that has been
> > on my todo-list for quite a while. See
> > 
> > https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch
> > 
> > for the patch we currently use (on top of that, we change the 0.5
> > initializer to 0.0 to avoid having to always pass the --delay argument).
> > Incidentally, it seems we're on the same util-linux version, so you
> > should be able to try out that patch and see if it works for you.
> 
> Would be possible to somehow detect what is the right default setting for
> --delay? I mean for example detect architecture / clock HW, etc.
> 
> I have no problem with --delay, but it's tuning for advanced users and
> HW specific stuff. It would be nice to have something more portable.
> 

This is what I'm using to synchronize the RTC to the system time:

https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/rtc-tools.git/tree/rtc-sync.c

With sane RTCs, it manages to do so with a good precision, 10µs on a
pcf85363 connected to a sama5d4 xplained, 96µs on my PC.

It can still be improved and doesn't handle RTCs in localtime.

I'm planning to integrate that in hwclock at some point i(hopefully
soon) but I didn't have the time to dive too much in the code yet.

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: 500 ms delay in time saved into RTC

[Alexandre Belloni]

Hi,

On 19/02/2018 at 12:03:28 +0100, Karel Zak wrote:
> On Mon, Feb 19, 2018 at 08:11:05AM +0100, Rasmus Villemoes wrote:
> > It's because util-linux's hwclock still assumes the world is x86. See
> > this comment in the util-linux source code:
> > 
> > /*
> >  * The Hardware Clock can only be set to any integer time plus one
> >  * half second.  The integer time is required because there is no
> >  * interface to set or get a fractional second.  The additional half
> >  * second is because the Hardware Clock updates to the following
> >  * second precisely 500 ms (not 1 second!) after you release the
> >  * divider reset (after setting the new time) - see description of
> >  * DV2, DV1, DV0 in Register A in the MC146818A data sheet (and note
> > 
> > So if hwclock is asked to --systohc at time 01:02:03.x, it waits until
> > the time is 01:02:03.5 to set the rtc to 01:02:03, or if that has
> > already passed, waits until  01:02:04.5 and sets it to 01:02:04.
> > 
> > On our ARM BSP we patch util-linux to have the "implicit fractional
> > part" configurable, and trying to upstream something like that has been
> > on my todo-list for quite a while. See
> > 
> > https://raw.githubusercontent.com/oe-lite/base/master/recipes/util-linux/util-linux-2.29/hwclock-tweak-delay.patch
> > 
> > for the patch we currently use (on top of that, we change the 0.5
> > initializer to 0.0 to avoid having to always pass the --delay argument).
> > Incidentally, it seems we're on the same util-linux version, so you
> > should be able to try out that patch and see if it works for you.
> 
> Would be possible to somehow detect what is the right default setting for
> --delay? I mean for example detect architecture / clock HW, etc.
> 
> I have no problem with --delay, but it's tuning for advanced users and
> HW specific stuff. It would be nice to have something more portable.
> 

This is what I'm using to synchronize the RTC to the system time:

https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/rtc-tools.git/tree/rtc-sync.c

With sane RTCs, it manages to do so with a good precision, 10µs on a
pcf85363 connected to a sama5d4 xplained, 96µs on my PC.

It can still be improved and doesn't handle RTCs in localtime.

I'm planning to integrate that in hwclock at some point i(hopefully
soon) but I didn't have the time to dive too much in the code yet.

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [GIT PULL] KVM changes for 4.16-rc3

[Linus Torvalds]

On Fri, Feb 23, 2018 at 5:46 PM, Paolo Bonzini  wrote:
>
>   git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

This has 28 fixes that were committed one hour before you sent this email.

I pulled, but I think I'm going to unpull, just because I want an
explanation of how that could possibly have had sufficient testing for
the upcoming rc?

Linus

Re: [GIT PULL] KVM changes for 4.16-rc3

[Linus Torvalds]

On Fri, Feb 23, 2018 at 5:46 PM, Paolo Bonzini  wrote:
>
>   git://git.kernel.org/pub/scm/virt/kvm/kvm.git tags/for-linus

This has 28 fixes that were committed one hour before you sent this email.

I pulled, but I think I'm going to unpull, just because I want an
explanation of how that could possibly have had sufficient testing for
the upcoming rc?

Linus

Re: [PATCH] lib/test_kmod: Fix an integer overflow test

[Dan Carpenter]

On Sat, Feb 24, 2018 at 10:06:01PM +, Luis R. Rodriguez wrote:
> On Sat, Feb 24, 2018 at 11:45:16AM +0300, Dan Carpenter wrote:
> > On Sat, Feb 24, 2018 at 02:59:41AM +, Luis R. Rodriguez wrote:
> > > On Mon, Jan 22, 2018 at 01:27:54PM +0300, Dan Carpenter wrote:
> > > > The main problem is that the parentheses are in the wrong place and the
> > > > unlikely() call returns either 0 or 1 so it's never less than zero.
> > > 
> > > Doh, thanks, yes. Seems worth considering a grammar rule for it.
> > > 
> > > > The other problem is that signed integer overflows like "INT_MAX + 1" 
> > > > are
> > > > undefined behavior.
> > > 
> > > Likewise.
> > > 
> > > This seems like another possible generic typo issue. But I would not 
> > > resolve it
> > > the way you did, in this particular case below num_test_devs represents 
> > > the
> > > number of already registered devs, before we increment. So the way to 
> > > resolve
> > > this would be:
> > > 
> > >   if (num_test_devs + 1 == INT_MAX)
> > > 
> > > I'll get this upstream, thanks!
> > 
> > There is no issue if num_test_devs is INT_MAX.  But capping it at
> > INT_MAX - 1 is also fine.
> 
> If num_test_devs is INT_MAX, then doing num_test_devs + 1 overflows
> and as you noted that is undefined?

If it's INT_MAX we never do "num_test_devs + 1", we return a NULL.

regards,
dan carpenter

Re: [PATCH] lib/test_kmod: Fix an integer overflow test

[Dan Carpenter]

On Sat, Feb 24, 2018 at 10:06:01PM +, Luis R. Rodriguez wrote:
> On Sat, Feb 24, 2018 at 11:45:16AM +0300, Dan Carpenter wrote:
> > On Sat, Feb 24, 2018 at 02:59:41AM +, Luis R. Rodriguez wrote:
> > > On Mon, Jan 22, 2018 at 01:27:54PM +0300, Dan Carpenter wrote:
> > > > The main problem is that the parentheses are in the wrong place and the
> > > > unlikely() call returns either 0 or 1 so it's never less than zero.
> > > 
> > > Doh, thanks, yes. Seems worth considering a grammar rule for it.
> > > 
> > > > The other problem is that signed integer overflows like "INT_MAX + 1" 
> > > > are
> > > > undefined behavior.
> > > 
> > > Likewise.
> > > 
> > > This seems like another possible generic typo issue. But I would not 
> > > resolve it
> > > the way you did, in this particular case below num_test_devs represents 
> > > the
> > > number of already registered devs, before we increment. So the way to 
> > > resolve
> > > this would be:
> > > 
> > >   if (num_test_devs + 1 == INT_MAX)
> > > 
> > > I'll get this upstream, thanks!
> > 
> > There is no issue if num_test_devs is INT_MAX.  But capping it at
> > INT_MAX - 1 is also fine.
> 
> If num_test_devs is INT_MAX, then doing num_test_devs + 1 overflows
> and as you noted that is undefined?

If it's INT_MAX we never do "num_test_devs + 1", we return a NULL.

regards,
dan carpenter

[PATCH net 3/4] net/sonic: Clean up and modernize log messages

[Finn Thain]

Add missing printk severity levels by adopting pr_foo() calls for the
platform_driver and dev_foo() calls for the nubus_driver.
Avoid KERN_CONT usage as per advice from checkpatch.
Avoid #ifdef around printk calls.
Don't log driver probe messages after calling register_netdev().

Cc: Thomas Bogendoerfer 
Cc: Chris Zankel 
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
Only the macsonic.c changes have been tested. The other changes
are similar but untested.
---
 drivers/net/ethernet/natsemi/jazzsonic.c | 13 -
 drivers/net/ethernet/natsemi/macsonic.c  | 49 ++--
 drivers/net/ethernet/natsemi/xtsonic.c   | 11 +++
 3 files changed, 33 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/natsemi/jazzsonic.c 
b/drivers/net/ethernet/natsemi/jazzsonic.c
index d5b28884e21e..58495316d318 100644
--- a/drivers/net/ethernet/natsemi/jazzsonic.c
+++ b/drivers/net/ethernet/natsemi/jazzsonic.c
@@ -142,17 +142,14 @@ static int sonic_probe1(struct net_device *dev)
i++;
 
if (known_revisions[i] == 0x) {
-   printk("SONIC ethernet controller not found (0x%4x)\n",
-  silicon_revision);
+   pr_info("SONIC ethernet controller not found (0x%4x)\n",
+   silicon_revision);
goto out;
}
 
if (sonic_debug  &&  version_printed++ == 0)
printk(version);
 
-   printk(KERN_INFO "%s: Sonic ethernet found at 0x%08lx, ",
-  dev_name(lp->device), dev->base_addr);
-
/*
 * Put the sonic into software reset, then
 * retrieve and print the ethernet address.
@@ -245,12 +242,14 @@ static int jazz_sonic_probe(struct platform_device *pdev)
err = sonic_probe1(dev);
if (err)
goto out;
+
+   pr_info("SONIC ethernet @%08lx, MAC %pM, IRQ %d\n",
+   dev->base_addr, dev->dev_addr, dev->irq);
+
err = register_netdev(dev);
if (err)
goto out1;
 
-   printk("%s: MAC %pM IRQ %d\n", dev->name, dev->dev_addr, dev->irq);
-
return 0;
 
 out1:
diff --git a/drivers/net/ethernet/natsemi/macsonic.c 
b/drivers/net/ethernet/natsemi/macsonic.c
index f6745a893c82..dc690f287a6d 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -311,8 +311,6 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
int sr;
bool commslot = macintosh_config->expansion_type == MAC_EXP_PDS_COMM;
 
-   printk(KERN_INFO "Checking for internal Macintosh ethernet (SONIC).. ");
-
/* Bogus probing, on the models which may or may not have
   Ethernet (BTW, the Ethernet *is* always at the same
   address, and nothing else lives there, at least if Apple's
@@ -322,13 +320,11 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
 
card_present = hwreg_present((void*)ONBOARD_SONIC_REGISTERS);
if (!card_present) {
-   printk("none.\n");
+   pr_info("Onboard/comm-slot SONIC not found\n");
return -ENODEV;
}
}
 
-   printk("yes\n");
-
/* Danger!  My arms are flailing wildly!  You *must* set lp->reg_offset
 * and dev->base_addr before using SONIC_READ() or SONIC_WRITE() */
dev->base_addr = ONBOARD_SONIC_REGISTERS;
@@ -341,14 +337,11 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
printk(KERN_INFO "%s", version);
sonic_version_printed = 1;
}
-   printk(KERN_INFO "%s: onboard / comm-slot SONIC at 0x%08lx\n",
-  dev_name(lp->device), dev->base_addr);
 
/* The PowerBook's SONIC is 16 bit always. */
if (macintosh_config->ident == MAC_MODEL_PB520) {
lp->reg_offset = 0;
lp->dma_bitmode = SONIC_BITMODE16;
-   sr = SONIC_READ(SONIC_SR);
} else if (commslot) {
/* Some of the comm-slot cards are 16 bit.  But some
   of them are not.  The 32-bit cards use offset 2 and
@@ -365,22 +358,21 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
else {
lp->dma_bitmode = SONIC_BITMODE16;
lp->reg_offset = 0;
-   sr = SONIC_READ(SONIC_SR);
}
} else {
/* All onboard cards are at offset 2 with 32 bit DMA. */
lp->reg_offset = 2;
lp->dma_bitmode = SONIC_BITMODE32;
-   sr = SONIC_READ(SONIC_SR);
}
-   printk(KERN_INFO
-  "%s: revision 0x%04x, using %d bit DMA and register offset %d\n",
-  dev_name(lp->device), sr, lp->dma_bitmode?32:16, lp->reg_offset);
 
-#if 0 /* This is sometimes useful to find 

[PATCH net 4/4] net/sonic: Replace custom debug logging with netif_* calls

[Finn Thain]

Eliminate duplicated debug code by moving it into the core driver.
Don't log the only valid silicon revision number (it's in the source).

Cc: Thomas Bogendoerfer 
Cc: Chris Zankel 
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
Only the sonic.[ch] and macsonic.c changes have been tested. The other
changes are similar but untested.
---
 drivers/net/ethernet/natsemi/jazzsonic.c | 19 +-
 drivers/net/ethernet/natsemi/macsonic.c  | 25 ++--
 drivers/net/ethernet/natsemi/sonic.c | 99 
 drivers/net/ethernet/natsemi/sonic.h |  2 +
 drivers/net/ethernet/natsemi/xtsonic.c   | 19 +-
 5 files changed, 61 insertions(+), 103 deletions(-)

diff --git a/drivers/net/ethernet/natsemi/jazzsonic.c 
b/drivers/net/ethernet/natsemi/jazzsonic.c
index 58495316d318..51fa82b429a3 100644
--- a/drivers/net/ethernet/natsemi/jazzsonic.c
+++ b/drivers/net/ethernet/natsemi/jazzsonic.c
@@ -60,14 +60,6 @@ do { 
\
*((volatile unsigned int *)dev->base_addr+(reg)) = (val);   
\
 } while (0)
 
-
-/* use 0 for production, 1 for verification, >1 for debug */
-#ifdef SONIC_DEBUG
-static unsigned int sonic_debug = SONIC_DEBUG;
-#else
-static unsigned int sonic_debug = 1;
-#endif
-
 /*
  * We cannot use station (ethernet) address prefixes to detect the
  * sonic controller since these are board manufacturer depended.
@@ -117,7 +109,6 @@ static const struct net_device_ops sonic_netdev_ops = {
 
 static int sonic_probe1(struct net_device *dev)
 {
-   static unsigned version_printed;
unsigned int silicon_revision;
unsigned int val;
struct sonic_local *lp = netdev_priv(dev);
@@ -133,9 +124,6 @@ static int sonic_probe1(struct net_device *dev)
 * the expected location.
 */
silicon_revision = SONIC_READ(SONIC_SR);
-   if (sonic_debug > 1)
-   printk("SONIC Silicon Revision = 0x%04x\n",silicon_revision);
-
i = 0;
while (known_revisions[i] != 0x &&
   known_revisions[i] != silicon_revision)
@@ -147,9 +135,6 @@ static int sonic_probe1(struct net_device *dev)
goto out;
}
 
-   if (sonic_debug  &&  version_printed++ == 0)
-   printk(version);
-
/*
 * Put the sonic into software reset, then
 * retrieve and print the ethernet address.
@@ -246,6 +231,8 @@ static int jazz_sonic_probe(struct platform_device *pdev)
pr_info("SONIC ethernet @%08lx, MAC %pM, IRQ %d\n",
dev->base_addr, dev->dev_addr, dev->irq);
 
+   sonic_msg_init(dev);
+
err = register_netdev(dev);
if (err)
goto out1;
@@ -261,8 +248,6 @@ static int jazz_sonic_probe(struct platform_device *pdev)
 }
 
 MODULE_DESCRIPTION("Jazz SONIC ethernet driver");
-module_param(sonic_debug, int, 0);
-MODULE_PARM_DESC(sonic_debug, "jazzsonic debug level (1-4)");
 MODULE_ALIAS("platform:jazzsonic");
 
 #include "sonic.c"
diff --git a/drivers/net/ethernet/natsemi/macsonic.c 
b/drivers/net/ethernet/natsemi/macsonic.c
index dc690f287a6d..0937fc2a928e 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -70,15 +70,6 @@
 #define SONIC_WRITE(reg,val) (nubus_writew(val, dev->base_addr + (reg * 4) \
  + lp->reg_offset))
 
-/* use 0 for production, 1 for verification, >1 for debug */
-#ifdef SONIC_DEBUG
-static unsigned int sonic_debug = SONIC_DEBUG;
-#else
-static unsigned int sonic_debug = 1;
-#endif
-
-static int sonic_version_printed;
-
 /* For onboard SONIC */
 #define ONBOARD_SONIC_REGISTERS0x50F0A000
 #define ONBOARD_SONIC_PROM_BASE0x50f08000
@@ -333,11 +324,6 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
else
dev->irq = IRQ_NUBUS_9;
 
-   if (!sonic_version_printed) {
-   printk(KERN_INFO "%s", version);
-   sonic_version_printed = 1;
-   }
-
/* The PowerBook's SONIC is 16 bit always. */
if (macintosh_config->ident == MAC_MODEL_PB520) {
lp->reg_offset = 0;
@@ -499,11 +485,6 @@ static int mac_sonic_nubus_probe_board(struct nubus_board 
*board, int id,
lp->dma_bitmode = dma_bitmode;
dev->irq = SLOT2IRQ(board->slot);
 
-   if (!sonic_version_printed) {
-   printk(KERN_INFO "%s", version);
-   sonic_version_printed = 1;
-   }
-
dev_info(>dev, "%s, revision 0x%04x, %d bit DMA, register offset 
%d\n",
 board->name, SONIC_READ(SONIC_SR),
 lp->dma_bitmode ? 32 : 16, lp->reg_offset);
@@ -555,6 +536,8 @@ static int mac_sonic_platform_probe(struct platform_device 
*pdev)
if (err)
goto out;
 
+   sonic_msg_init(dev);
+
err = register_netdev(dev);
if (err)

[PATCH net 3/4] net/sonic: Clean up and modernize log messages

[Finn Thain]

Add missing printk severity levels by adopting pr_foo() calls for the
platform_driver and dev_foo() calls for the nubus_driver.
Avoid KERN_CONT usage as per advice from checkpatch.
Avoid #ifdef around printk calls.
Don't log driver probe messages after calling register_netdev().

Cc: Thomas Bogendoerfer 
Cc: Chris Zankel 
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
Only the macsonic.c changes have been tested. The other changes
are similar but untested.
---
 drivers/net/ethernet/natsemi/jazzsonic.c | 13 -
 drivers/net/ethernet/natsemi/macsonic.c  | 49 ++--
 drivers/net/ethernet/natsemi/xtsonic.c   | 11 +++
 3 files changed, 33 insertions(+), 40 deletions(-)

diff --git a/drivers/net/ethernet/natsemi/jazzsonic.c 
b/drivers/net/ethernet/natsemi/jazzsonic.c
index d5b28884e21e..58495316d318 100644
--- a/drivers/net/ethernet/natsemi/jazzsonic.c
+++ b/drivers/net/ethernet/natsemi/jazzsonic.c
@@ -142,17 +142,14 @@ static int sonic_probe1(struct net_device *dev)
i++;
 
if (known_revisions[i] == 0x) {
-   printk("SONIC ethernet controller not found (0x%4x)\n",
-  silicon_revision);
+   pr_info("SONIC ethernet controller not found (0x%4x)\n",
+   silicon_revision);
goto out;
}
 
if (sonic_debug  &&  version_printed++ == 0)
printk(version);
 
-   printk(KERN_INFO "%s: Sonic ethernet found at 0x%08lx, ",
-  dev_name(lp->device), dev->base_addr);
-
/*
 * Put the sonic into software reset, then
 * retrieve and print the ethernet address.
@@ -245,12 +242,14 @@ static int jazz_sonic_probe(struct platform_device *pdev)
err = sonic_probe1(dev);
if (err)
goto out;
+
+   pr_info("SONIC ethernet @%08lx, MAC %pM, IRQ %d\n",
+   dev->base_addr, dev->dev_addr, dev->irq);
+
err = register_netdev(dev);
if (err)
goto out1;
 
-   printk("%s: MAC %pM IRQ %d\n", dev->name, dev->dev_addr, dev->irq);
-
return 0;
 
 out1:
diff --git a/drivers/net/ethernet/natsemi/macsonic.c 
b/drivers/net/ethernet/natsemi/macsonic.c
index f6745a893c82..dc690f287a6d 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -311,8 +311,6 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
int sr;
bool commslot = macintosh_config->expansion_type == MAC_EXP_PDS_COMM;
 
-   printk(KERN_INFO "Checking for internal Macintosh ethernet (SONIC).. ");
-
/* Bogus probing, on the models which may or may not have
   Ethernet (BTW, the Ethernet *is* always at the same
   address, and nothing else lives there, at least if Apple's
@@ -322,13 +320,11 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
 
card_present = hwreg_present((void*)ONBOARD_SONIC_REGISTERS);
if (!card_present) {
-   printk("none.\n");
+   pr_info("Onboard/comm-slot SONIC not found\n");
return -ENODEV;
}
}
 
-   printk("yes\n");
-
/* Danger!  My arms are flailing wildly!  You *must* set lp->reg_offset
 * and dev->base_addr before using SONIC_READ() or SONIC_WRITE() */
dev->base_addr = ONBOARD_SONIC_REGISTERS;
@@ -341,14 +337,11 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
printk(KERN_INFO "%s", version);
sonic_version_printed = 1;
}
-   printk(KERN_INFO "%s: onboard / comm-slot SONIC at 0x%08lx\n",
-  dev_name(lp->device), dev->base_addr);
 
/* The PowerBook's SONIC is 16 bit always. */
if (macintosh_config->ident == MAC_MODEL_PB520) {
lp->reg_offset = 0;
lp->dma_bitmode = SONIC_BITMODE16;
-   sr = SONIC_READ(SONIC_SR);
} else if (commslot) {
/* Some of the comm-slot cards are 16 bit.  But some
   of them are not.  The 32-bit cards use offset 2 and
@@ -365,22 +358,21 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
else {
lp->dma_bitmode = SONIC_BITMODE16;
lp->reg_offset = 0;
-   sr = SONIC_READ(SONIC_SR);
}
} else {
/* All onboard cards are at offset 2 with 32 bit DMA. */
lp->reg_offset = 2;
lp->dma_bitmode = SONIC_BITMODE32;
-   sr = SONIC_READ(SONIC_SR);
}
-   printk(KERN_INFO
-  "%s: revision 0x%04x, using %d bit DMA and register offset %d\n",
-  dev_name(lp->device), sr, lp->dma_bitmode?32:16, lp->reg_offset);
 
-#if 0 /* This is sometimes useful to find out how MacOS configured the card. */
-   printk(KERN_INFO "%s: DCR: 0x%04x, DCR2: 

[PATCH net 4/4] net/sonic: Replace custom debug logging with netif_* calls

[Finn Thain]

Eliminate duplicated debug code by moving it into the core driver.
Don't log the only valid silicon revision number (it's in the source).

Cc: Thomas Bogendoerfer 
Cc: Chris Zankel 
Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
Only the sonic.[ch] and macsonic.c changes have been tested. The other
changes are similar but untested.
---
 drivers/net/ethernet/natsemi/jazzsonic.c | 19 +-
 drivers/net/ethernet/natsemi/macsonic.c  | 25 ++--
 drivers/net/ethernet/natsemi/sonic.c | 99 
 drivers/net/ethernet/natsemi/sonic.h |  2 +
 drivers/net/ethernet/natsemi/xtsonic.c   | 19 +-
 5 files changed, 61 insertions(+), 103 deletions(-)

diff --git a/drivers/net/ethernet/natsemi/jazzsonic.c 
b/drivers/net/ethernet/natsemi/jazzsonic.c
index 58495316d318..51fa82b429a3 100644
--- a/drivers/net/ethernet/natsemi/jazzsonic.c
+++ b/drivers/net/ethernet/natsemi/jazzsonic.c
@@ -60,14 +60,6 @@ do { 
\
*((volatile unsigned int *)dev->base_addr+(reg)) = (val);   
\
 } while (0)
 
-
-/* use 0 for production, 1 for verification, >1 for debug */
-#ifdef SONIC_DEBUG
-static unsigned int sonic_debug = SONIC_DEBUG;
-#else
-static unsigned int sonic_debug = 1;
-#endif
-
 /*
  * We cannot use station (ethernet) address prefixes to detect the
  * sonic controller since these are board manufacturer depended.
@@ -117,7 +109,6 @@ static const struct net_device_ops sonic_netdev_ops = {
 
 static int sonic_probe1(struct net_device *dev)
 {
-   static unsigned version_printed;
unsigned int silicon_revision;
unsigned int val;
struct sonic_local *lp = netdev_priv(dev);
@@ -133,9 +124,6 @@ static int sonic_probe1(struct net_device *dev)
 * the expected location.
 */
silicon_revision = SONIC_READ(SONIC_SR);
-   if (sonic_debug > 1)
-   printk("SONIC Silicon Revision = 0x%04x\n",silicon_revision);
-
i = 0;
while (known_revisions[i] != 0x &&
   known_revisions[i] != silicon_revision)
@@ -147,9 +135,6 @@ static int sonic_probe1(struct net_device *dev)
goto out;
}
 
-   if (sonic_debug  &&  version_printed++ == 0)
-   printk(version);
-
/*
 * Put the sonic into software reset, then
 * retrieve and print the ethernet address.
@@ -246,6 +231,8 @@ static int jazz_sonic_probe(struct platform_device *pdev)
pr_info("SONIC ethernet @%08lx, MAC %pM, IRQ %d\n",
dev->base_addr, dev->dev_addr, dev->irq);
 
+   sonic_msg_init(dev);
+
err = register_netdev(dev);
if (err)
goto out1;
@@ -261,8 +248,6 @@ static int jazz_sonic_probe(struct platform_device *pdev)
 }
 
 MODULE_DESCRIPTION("Jazz SONIC ethernet driver");
-module_param(sonic_debug, int, 0);
-MODULE_PARM_DESC(sonic_debug, "jazzsonic debug level (1-4)");
 MODULE_ALIAS("platform:jazzsonic");
 
 #include "sonic.c"
diff --git a/drivers/net/ethernet/natsemi/macsonic.c 
b/drivers/net/ethernet/natsemi/macsonic.c
index dc690f287a6d..0937fc2a928e 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -70,15 +70,6 @@
 #define SONIC_WRITE(reg,val) (nubus_writew(val, dev->base_addr + (reg * 4) \
  + lp->reg_offset))
 
-/* use 0 for production, 1 for verification, >1 for debug */
-#ifdef SONIC_DEBUG
-static unsigned int sonic_debug = SONIC_DEBUG;
-#else
-static unsigned int sonic_debug = 1;
-#endif
-
-static int sonic_version_printed;
-
 /* For onboard SONIC */
 #define ONBOARD_SONIC_REGISTERS0x50F0A000
 #define ONBOARD_SONIC_PROM_BASE0x50f08000
@@ -333,11 +324,6 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
else
dev->irq = IRQ_NUBUS_9;
 
-   if (!sonic_version_printed) {
-   printk(KERN_INFO "%s", version);
-   sonic_version_printed = 1;
-   }
-
/* The PowerBook's SONIC is 16 bit always. */
if (macintosh_config->ident == MAC_MODEL_PB520) {
lp->reg_offset = 0;
@@ -499,11 +485,6 @@ static int mac_sonic_nubus_probe_board(struct nubus_board 
*board, int id,
lp->dma_bitmode = dma_bitmode;
dev->irq = SLOT2IRQ(board->slot);
 
-   if (!sonic_version_printed) {
-   printk(KERN_INFO "%s", version);
-   sonic_version_printed = 1;
-   }
-
dev_info(>dev, "%s, revision 0x%04x, %d bit DMA, register offset 
%d\n",
 board->name, SONIC_READ(SONIC_SR),
 lp->dma_bitmode ? 32 : 16, lp->reg_offset);
@@ -555,6 +536,8 @@ static int mac_sonic_platform_probe(struct platform_device 
*pdev)
if (err)
goto out;
 
+   sonic_msg_init(dev);
+
err = register_netdev(dev);
if (err)
goto out;
@@ -568,8 +551,6 @@ static int mac_sonic_platform_probe(struct platform_device 

[PATCH net 1/4] net/macsonic: Convert to nubus_driver

[Finn Thain]

This resolves an old issue preventing any NuBus SONIC NICs from
working in a Mac with an on-board SONIC device.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/net/ethernet/natsemi/macsonic.c | 173 ++--
 1 file changed, 119 insertions(+), 54 deletions(-)

diff --git a/drivers/net/ethernet/natsemi/macsonic.c 
b/drivers/net/ethernet/natsemi/macsonic.c
index b922ab5cedea..c744912f55a9 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -60,8 +60,6 @@
 #include 
 #include 
 
-static char mac_sonic_string[] = "macsonic";
-
 #include "sonic.h"
 
 /* These should basically be bus-size and endian independent (since
@@ -410,7 +408,7 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
return macsonic_init(dev);
 }
 
-static int mac_nubus_sonic_ethernet_addr(struct net_device *dev,
+static int mac_sonic_nubus_ethernet_addr(struct net_device *dev,
 unsigned long prom_addr, int id)
 {
int i;
@@ -449,70 +447,49 @@ static int macsonic_ident(struct nubus_rsrc *fres)
return -1;
 }
 
-static int mac_nubus_sonic_probe(struct net_device *dev)
+static int mac_sonic_nubus_probe_board(struct nubus_board *board, int id,
+  struct net_device *dev)
 {
-   static int slots;
-   struct nubus_rsrc *ndev = NULL;
struct sonic_local* lp = netdev_priv(dev);
unsigned long base_addr, prom_addr;
u16 sonic_dcr;
-   int id = -1;
int reg_offset, dma_bitmode;
 
-   /* Find the first SONIC that hasn't been initialized already */
-   for_each_func_rsrc(ndev) {
-   if (ndev->category != NUBUS_CAT_NETWORK ||
-   ndev->type != NUBUS_TYPE_ETHERNET)
-   continue;
-
-   /* Have we seen it already? */
-   if (slots & (1slot))
-   continue;
-   slots |= 1slot;
-
-   /* Is it one of ours? */
-   if ((id = macsonic_ident(ndev)) != -1)
-   break;
-   }
-
-   if (ndev == NULL)
-   return -ENODEV;
-
switch (id) {
case MACSONIC_DUODOCK:
-   base_addr = ndev->board->slot_addr + DUODOCK_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + DUODOCK_SONIC_PROM_BASE;
+   base_addr = board->slot_addr + DUODOCK_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + DUODOCK_SONIC_PROM_BASE;
sonic_dcr = SONIC_DCR_EXBUS | SONIC_DCR_RFT0 | SONIC_DCR_RFT1 |
SONIC_DCR_TFT0;
reg_offset = 2;
dma_bitmode = SONIC_BITMODE32;
break;
case MACSONIC_APPLE:
-   base_addr = ndev->board->slot_addr + APPLE_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + APPLE_SONIC_PROM_BASE;
+   base_addr = board->slot_addr + APPLE_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + APPLE_SONIC_PROM_BASE;
sonic_dcr = SONIC_DCR_BMS | SONIC_DCR_RFT1 | SONIC_DCR_TFT0;
reg_offset = 0;
dma_bitmode = SONIC_BITMODE32;
break;
case MACSONIC_APPLE16:
-   base_addr = ndev->board->slot_addr + APPLE_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + APPLE_SONIC_PROM_BASE;
+   base_addr = board->slot_addr + APPLE_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + APPLE_SONIC_PROM_BASE;
sonic_dcr = SONIC_DCR_EXBUS | SONIC_DCR_RFT1 | SONIC_DCR_TFT0 |
SONIC_DCR_PO1 | SONIC_DCR_BMS;
reg_offset = 0;
dma_bitmode = SONIC_BITMODE16;
break;
case MACSONIC_DAYNALINK:
-   base_addr = ndev->board->slot_addr + APPLE_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + DAYNALINK_PROM_BASE;
+   base_addr = board->slot_addr + APPLE_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + DAYNALINK_PROM_BASE;
sonic_dcr = SONIC_DCR_RFT1 | SONIC_DCR_TFT0 |
SONIC_DCR_PO1 | SONIC_DCR_BMS;
reg_offset = 0;
dma_bitmode = SONIC_BITMODE16;
break;
case MACSONIC_DAYNA:
-   base_addr = ndev->board->slot_addr + DAYNA_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + DAYNA_SONIC_MAC_ADDR;
+   base_addr = board->slot_addr + DAYNA_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + DAYNA_SONIC_MAC_ADDR;
sonic_dcr = SONIC_DCR_BMS |
SONIC_DCR_RFT1 | SONIC_DCR_TFT0 | SONIC_DCR_PO1;
reg_offset = 0;
@@ -528,14 +505,14 @@ static int mac_nubus_sonic_probe(struct net_device 

[PATCH net 0/4] Fixes, cleanup and modernization for SONIC ethernet drivers

[Finn Thain]

Changes since v4 of combined patch series:
- Removed redundant and non-portable MACH_IS_MAC tests.
- Omitted patches unrelated to SONIC drivers.
- Dropped changes to the 'version_printed' logic and debug message text.


Finn Thain (4):
  net/macsonic: Convert to nubus_driver
  net/macsonic: Drop redundant MACH_IS_MAC test
  net/sonic: Clean up and modernize log messages
  net/sonic: Replace custom debug logging with netif_* calls

 drivers/net/ethernet/natsemi/jazzsonic.c |  32 +---
 drivers/net/ethernet/natsemi/macsonic.c  | 244 ++-
 drivers/net/ethernet/natsemi/sonic.c |  99 +++--
 drivers/net/ethernet/natsemi/sonic.h |   2 +
 drivers/net/ethernet/natsemi/xtsonic.c   |  30 +---
 5 files changed, 210 insertions(+), 197 deletions(-)

-- 
2.16.1

[PATCH net 2/4] net/macsonic: Drop redundant MACH_IS_MAC test

[Finn Thain]

The MACH_IS_MAC test is redundant here because the platform device
won't get registered unless MACH_IS_MAC.

Cc: Geert Uytterhoeven 
Signed-off-by: Finn Thain 
---
 drivers/net/ethernet/natsemi/macsonic.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/natsemi/macsonic.c 
b/drivers/net/ethernet/natsemi/macsonic.c
index c744912f55a9..f6745a893c82 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -311,9 +311,6 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
int sr;
bool commslot = macintosh_config->expansion_type == MAC_EXP_PDS_COMM;
 
-   if (!MACH_IS_MAC)
-   return -ENODEV;
-
printk(KERN_INFO "Checking for internal Macintosh ethernet (SONIC).. ");
 
/* Bogus probing, on the models which may or may not have
-- 
2.16.1

[PATCH net 1/4] net/macsonic: Convert to nubus_driver

[Finn Thain]

This resolves an old issue preventing any NuBus SONIC NICs from
working in a Mac with an on-board SONIC device.

Tested-by: Stan Johnson 
Signed-off-by: Finn Thain 
---
 drivers/net/ethernet/natsemi/macsonic.c | 173 ++--
 1 file changed, 119 insertions(+), 54 deletions(-)

diff --git a/drivers/net/ethernet/natsemi/macsonic.c 
b/drivers/net/ethernet/natsemi/macsonic.c
index b922ab5cedea..c744912f55a9 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -60,8 +60,6 @@
 #include 
 #include 
 
-static char mac_sonic_string[] = "macsonic";
-
 #include "sonic.h"
 
 /* These should basically be bus-size and endian independent (since
@@ -410,7 +408,7 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
return macsonic_init(dev);
 }
 
-static int mac_nubus_sonic_ethernet_addr(struct net_device *dev,
+static int mac_sonic_nubus_ethernet_addr(struct net_device *dev,
 unsigned long prom_addr, int id)
 {
int i;
@@ -449,70 +447,49 @@ static int macsonic_ident(struct nubus_rsrc *fres)
return -1;
 }
 
-static int mac_nubus_sonic_probe(struct net_device *dev)
+static int mac_sonic_nubus_probe_board(struct nubus_board *board, int id,
+  struct net_device *dev)
 {
-   static int slots;
-   struct nubus_rsrc *ndev = NULL;
struct sonic_local* lp = netdev_priv(dev);
unsigned long base_addr, prom_addr;
u16 sonic_dcr;
-   int id = -1;
int reg_offset, dma_bitmode;
 
-   /* Find the first SONIC that hasn't been initialized already */
-   for_each_func_rsrc(ndev) {
-   if (ndev->category != NUBUS_CAT_NETWORK ||
-   ndev->type != NUBUS_TYPE_ETHERNET)
-   continue;
-
-   /* Have we seen it already? */
-   if (slots & (1slot))
-   continue;
-   slots |= 1slot;
-
-   /* Is it one of ours? */
-   if ((id = macsonic_ident(ndev)) != -1)
-   break;
-   }
-
-   if (ndev == NULL)
-   return -ENODEV;
-
switch (id) {
case MACSONIC_DUODOCK:
-   base_addr = ndev->board->slot_addr + DUODOCK_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + DUODOCK_SONIC_PROM_BASE;
+   base_addr = board->slot_addr + DUODOCK_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + DUODOCK_SONIC_PROM_BASE;
sonic_dcr = SONIC_DCR_EXBUS | SONIC_DCR_RFT0 | SONIC_DCR_RFT1 |
SONIC_DCR_TFT0;
reg_offset = 2;
dma_bitmode = SONIC_BITMODE32;
break;
case MACSONIC_APPLE:
-   base_addr = ndev->board->slot_addr + APPLE_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + APPLE_SONIC_PROM_BASE;
+   base_addr = board->slot_addr + APPLE_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + APPLE_SONIC_PROM_BASE;
sonic_dcr = SONIC_DCR_BMS | SONIC_DCR_RFT1 | SONIC_DCR_TFT0;
reg_offset = 0;
dma_bitmode = SONIC_BITMODE32;
break;
case MACSONIC_APPLE16:
-   base_addr = ndev->board->slot_addr + APPLE_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + APPLE_SONIC_PROM_BASE;
+   base_addr = board->slot_addr + APPLE_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + APPLE_SONIC_PROM_BASE;
sonic_dcr = SONIC_DCR_EXBUS | SONIC_DCR_RFT1 | SONIC_DCR_TFT0 |
SONIC_DCR_PO1 | SONIC_DCR_BMS;
reg_offset = 0;
dma_bitmode = SONIC_BITMODE16;
break;
case MACSONIC_DAYNALINK:
-   base_addr = ndev->board->slot_addr + APPLE_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + DAYNALINK_PROM_BASE;
+   base_addr = board->slot_addr + APPLE_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + DAYNALINK_PROM_BASE;
sonic_dcr = SONIC_DCR_RFT1 | SONIC_DCR_TFT0 |
SONIC_DCR_PO1 | SONIC_DCR_BMS;
reg_offset = 0;
dma_bitmode = SONIC_BITMODE16;
break;
case MACSONIC_DAYNA:
-   base_addr = ndev->board->slot_addr + DAYNA_SONIC_REGISTERS;
-   prom_addr = ndev->board->slot_addr + DAYNA_SONIC_MAC_ADDR;
+   base_addr = board->slot_addr + DAYNA_SONIC_REGISTERS;
+   prom_addr = board->slot_addr + DAYNA_SONIC_MAC_ADDR;
sonic_dcr = SONIC_DCR_BMS |
SONIC_DCR_RFT1 | SONIC_DCR_TFT0 | SONIC_DCR_PO1;
reg_offset = 0;
@@ -528,14 +505,14 @@ static int mac_nubus_sonic_probe(struct net_device *dev)
dev->base_addr = base_addr;
   

[PATCH net 0/4] Fixes, cleanup and modernization for SONIC ethernet drivers

[Finn Thain]

Changes since v4 of combined patch series:
- Removed redundant and non-portable MACH_IS_MAC tests.
- Omitted patches unrelated to SONIC drivers.
- Dropped changes to the 'version_printed' logic and debug message text.


Finn Thain (4):
  net/macsonic: Convert to nubus_driver
  net/macsonic: Drop redundant MACH_IS_MAC test
  net/sonic: Clean up and modernize log messages
  net/sonic: Replace custom debug logging with netif_* calls

 drivers/net/ethernet/natsemi/jazzsonic.c |  32 +---
 drivers/net/ethernet/natsemi/macsonic.c  | 244 ++-
 drivers/net/ethernet/natsemi/sonic.c |  99 +++--
 drivers/net/ethernet/natsemi/sonic.h |   2 +
 drivers/net/ethernet/natsemi/xtsonic.c   |  30 +---
 5 files changed, 210 insertions(+), 197 deletions(-)

-- 
2.16.1

[PATCH net 2/4] net/macsonic: Drop redundant MACH_IS_MAC test

[Finn Thain]

The MACH_IS_MAC test is redundant here because the platform device
won't get registered unless MACH_IS_MAC.

Cc: Geert Uytterhoeven 
Signed-off-by: Finn Thain 
---
 drivers/net/ethernet/natsemi/macsonic.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/net/ethernet/natsemi/macsonic.c 
b/drivers/net/ethernet/natsemi/macsonic.c
index c744912f55a9..f6745a893c82 100644
--- a/drivers/net/ethernet/natsemi/macsonic.c
+++ b/drivers/net/ethernet/natsemi/macsonic.c
@@ -311,9 +311,6 @@ static int mac_onboard_sonic_probe(struct net_device *dev)
int sr;
bool commslot = macintosh_config->expansion_type == MAC_EXP_PDS_COMM;
 
-   if (!MACH_IS_MAC)
-   return -ENODEV;
-
printk(KERN_INFO "Checking for internal Macintosh ethernet (SONIC).. ");
 
/* Bogus probing, on the models which may or may not have
-- 
2.16.1

Re: [PATCH V2 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Daniel Lezcano]

On 23/02/2018 16:26, Vincent Guittot wrote:
> Hi Daniel,
> 
> On 21 February 2018 at 16:29, Daniel Lezcano  
> wrote:
>> +
>> +/**
>> + * struct cpuidle_cooling_device - data for the idle cooling device
>> + * @cdev: a pointer to a struct thermal_cooling_device
>> + * @cpumask: a cpumask containing the CPU managed by the cooling device
>> + * @timer: a hrtimer giving the tempo for the idle injection cycles
>> + * @kref: a kernel refcount on this structure
>> + * @count: an atomic to keep track of the last task exiting the idle cycle
>> + * @idle_cycle: an integer defining the duration of the idle injection
>> + * @state: an normalized integer giving the state of the cooling device
>> + */
>> +struct cpuidle_cooling_device {
>> +   struct thermal_cooling_device *cdev;
>> +   struct cpumask *cpumask;
>> +   struct list_head node;
>> +   struct hrtimer timer;
>> +   struct kref kref;
>> +   atomic_t count;
>> +   unsigned int idle_cycle;
>> +   unsigned int state;
>> +};
>> +
>> +/**
>> + * @tsk: an array of pointer to the idle injection tasks
>> + * @waitq: the waiq for the idle injection tasks
>> + */
>> +struct cpuidle_cooling_tsk {
>> +   struct task_struct *tsk;
>> +   wait_queue_head_t waitq;
> 
> Why are you creating one wait_queue_head_t per cpu instead of one per
> cooling device and then save a pointer in the per cpu struct
> cpuidle_cooling_tsk ?
> Then, you can use wake_up_interruptible_all() to wake up all threads
> instead of using for_each_cpu ... wake_up_process() loop in
> cpuidle_cooling_wakeup() ?
Yes, that should do the trick. I will give it a try.



  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH V2 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver

[Daniel Lezcano]

On 23/02/2018 16:26, Vincent Guittot wrote:
> Hi Daniel,
> 
> On 21 February 2018 at 16:29, Daniel Lezcano  
> wrote:
>> +
>> +/**
>> + * struct cpuidle_cooling_device - data for the idle cooling device
>> + * @cdev: a pointer to a struct thermal_cooling_device
>> + * @cpumask: a cpumask containing the CPU managed by the cooling device
>> + * @timer: a hrtimer giving the tempo for the idle injection cycles
>> + * @kref: a kernel refcount on this structure
>> + * @count: an atomic to keep track of the last task exiting the idle cycle
>> + * @idle_cycle: an integer defining the duration of the idle injection
>> + * @state: an normalized integer giving the state of the cooling device
>> + */
>> +struct cpuidle_cooling_device {
>> +   struct thermal_cooling_device *cdev;
>> +   struct cpumask *cpumask;
>> +   struct list_head node;
>> +   struct hrtimer timer;
>> +   struct kref kref;
>> +   atomic_t count;
>> +   unsigned int idle_cycle;
>> +   unsigned int state;
>> +};
>> +
>> +/**
>> + * @tsk: an array of pointer to the idle injection tasks
>> + * @waitq: the waiq for the idle injection tasks
>> + */
>> +struct cpuidle_cooling_tsk {
>> +   struct task_struct *tsk;
>> +   wait_queue_head_t waitq;
> 
> Why are you creating one wait_queue_head_t per cpu instead of one per
> cooling device and then save a pointer in the per cpu struct
> cpuidle_cooling_tsk ?
> Then, you can use wake_up_interruptible_all() to wake up all threads
> instead of using for_each_cpu ... wake_up_process() loop in
> cpuidle_cooling_wakeup() ?
Yes, that should do the trick. I will give it a try.



  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH V2 7/7] cpuidle/drivers/cpuidle-arm: Register the cooling device

[Daniel Lezcano]

On 24/02/2018 03:50, Wangtao (Kevin, Kirin) wrote:
> 
> 
> On 2018/2/21 23:29, Daniel Lezcano wrote:
>> Register the ARM generic cpuidle driver as a cooling device.
>>
>> Signed-off-by: Daniel Lezcano 
>> ---
>>   drivers/cpuidle/cpuidle-arm.c | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/cpuidle/cpuidle-arm.c
>> b/drivers/cpuidle/cpuidle-arm.c
>> index ddee1b6..c100915 100644
>> --- a/drivers/cpuidle/cpuidle-arm.c
>> +++ b/drivers/cpuidle/cpuidle-arm.c
>> @@ -11,6 +11,7 @@
>>     #define pr_fmt(fmt) "CPUidle arm: " fmt
>>   +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -172,6 +173,10 @@ static int __init arm_idle_init(void)
>>   goto out_fail;
>>   }
>>   +    ret = cpuidle_cooling_register();
>> +    if (ret)
>> +    pr_warn("Failed to register the cpuidle cooling device\n");
>> +
> SoC which uses Big-Little architecture doesn't use cpuidle-arm driver,
> is it
> better to put cpuidle_cooling_register to cpuidle_register_driver, and
> use the
> cpumask of cpuidle driver to register cpuidle cooling device intead of
> get it
> from topology?

The bL is supported by the cpuidle-arm driver, however due to how the
cpumask is built, we can't use this in cpuidle_register_driver for that,
it is a soapy board for now.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH V2 7/7] cpuidle/drivers/cpuidle-arm: Register the cooling device

[Daniel Lezcano]

On 24/02/2018 03:50, Wangtao (Kevin, Kirin) wrote:
> 
> 
> On 2018/2/21 23:29, Daniel Lezcano wrote:
>> Register the ARM generic cpuidle driver as a cooling device.
>>
>> Signed-off-by: Daniel Lezcano 
>> ---
>>   drivers/cpuidle/cpuidle-arm.c | 5 +
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/drivers/cpuidle/cpuidle-arm.c
>> b/drivers/cpuidle/cpuidle-arm.c
>> index ddee1b6..c100915 100644
>> --- a/drivers/cpuidle/cpuidle-arm.c
>> +++ b/drivers/cpuidle/cpuidle-arm.c
>> @@ -11,6 +11,7 @@
>>     #define pr_fmt(fmt) "CPUidle arm: " fmt
>>   +#include 
>>   #include 
>>   #include 
>>   #include 
>> @@ -172,6 +173,10 @@ static int __init arm_idle_init(void)
>>   goto out_fail;
>>   }
>>   +    ret = cpuidle_cooling_register();
>> +    if (ret)
>> +    pr_warn("Failed to register the cpuidle cooling device\n");
>> +
> SoC which uses Big-Little architecture doesn't use cpuidle-arm driver,
> is it
> better to put cpuidle_cooling_register to cpuidle_register_driver, and
> use the
> cpumask of cpuidle driver to register cpuidle cooling device intead of
> get it
> from topology?

The bL is supported by the cpuidle-arm driver, however due to how the
cpumask is built, we can't use this in cpuidle_register_driver for that,
it is a soapy board for now.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [RFC tip/locking/lockdep v5 16/17] lockdep: Documention for recursive read lock detection reasoning

[Andrea Parri]

On Thu, Feb 22, 2018 at 03:09:03PM +0800, Boqun Feng wrote:
> As now we support recursive read lock deadlock detection, add related
> explanation in the Documentation/lockdep/lockdep-desgin.txt:
> 
> * Definition of recursive read locks, non-recursive locks, strong
>   dependency path and notions of -(**)->.
> 
> * Lockdep's assumption.
> 
> * Informal proof of recursive read lock deadlock detection.

Once again... much appreciated!!, thanks for sharing.


> 
> Signed-off-by: Boqun Feng 
> Cc: Randy Dunlap 
> ---
>  Documentation/locking/lockdep-design.txt | 170 
> +++
>  1 file changed, 170 insertions(+)
> 
> diff --git a/Documentation/locking/lockdep-design.txt 
> b/Documentation/locking/lockdep-design.txt
> index 382bc25589c2..fd8a8d97ce58 100644
> --- a/Documentation/locking/lockdep-design.txt
> +++ b/Documentation/locking/lockdep-design.txt
> @@ -284,3 +284,173 @@ Run the command and save the output, then compare 
> against the output from
>  a later run of this command to identify the leakers.  This same output
>  can also help you find situations where runtime lock initialization has
>  been omitted.
> +
> +Recursive Read Deadlock Detection:
> +--
> +Lockdep now is equipped with deadlock detection for recursive read locks.
> +
> +Recursive read locks, as their name indicates, are the locks able to be
> +acquired recursively. Unlike non-recursive read locks, recursive read locks
> +only get blocked by current write lock *holders* other than write lock
> +*waiters*, for example:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> +
> + write_lock(X);
> +
> + read_lock(X);
> +
> +is not a deadlock for recursive read locks, as while the task B is waiting 
> for
> +the lock X, the second read_lock() doesn't need to wait because it's a 
> recursive
> +read lock.
> +
> +Note that a lock can be a write lock(exclusive lock), a non-recursive read 
> lock
> +(non-recursive shared lock) or a recursive read lock(recursive shared lock),
> +depending on the API used to acquire it(more specifically, the value of the
> +'read' parameter for lock_acquire(...)). In other words, a single lock 
> instance
> +has three types of acquisition depending on the acquisition functions:
> +exclusive, non-recursive read, and recursive read.
> +
> +That said, recursive read locks could introduce deadlocks too, considering 
> the
> +following:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> + read_lock(Y);
> + write_lock(Y);
> + write_lock(X);
> +
> +, neither task could get the write locks because the corresponding read locks
> +are held by each other.
> +
> +Lockdep could detect recursive read lock related deadlocks. The 
> dependencies(edges)
> +in the lockdep graph are classified into four categories:
> +
> +1) -(NN)->: non-recursive to non-recursive dependency, non-recursive locks 
> include
> +non-recursive read locks, write locks and exclusive locks(e.g. 
> spinlock_t).
> + They are treated equally in deadlock detection. "X -(NN)-> Y" means
> +X -> Y and both X and Y are non-recursive locks.
> +
> +2) -(RN)->: recursive to non-recursive dependency, recursive locks means 
> recursive read
> + locks. "X -(RN)-> Y" means X -> Y and X is recursive read lock and
> +Y is non-recursive lock.
> +
> +3) -(NR)->: non-recursive to recursive dependency, "X -(NR)-> Y" means X -> 
> Y and X is
> +non-recursive lock and Y is recursive lock.
> +
> +4) -(RR)->: recursive to recursive dependency, "X -(RR)-> Y" means X -> Y 
> and both X
> +and Y are recursive locks.
> +
> +Note that given two locks, they may have multiple dependencies between them, 
> for example:
> +
> + TASK A:
> +
> + read_lock(X);
> + write_lock(Y);
> + ...
> +
> + TASK B:
> +
> + write_lock(X);
> + write_lock(Y);
> +
> +, we have both X -(RN)-> Y and X -(NN)-> Y in the dependency graph.
> +
> +And obviously a non-recursive lock can block the corresponding recursive 
> lock,
> +and vice versa. Besides a non-recursive lock may block the other 
> non-recursive
> +lock of the same instance(e.g. a write lock may block a corresponding
> +non-recursive read lock and vice versa).
> +
> +We use -(*N)-> for edges that is either -(RN)-> or -(NN)->, the similar for 
> -(N*)->,
> +-(*R)-> and -(R*)->
> +
> +A "path" is a series of conjunct dependency edges in the graph. And we 
> define a
> +"strong" path, which indicates the strong dependency throughout each 
> dependency
> +in the path, as the path that doesn't have two conjunct edges(dependencies) 
> as
> +-(*R)-> and -(R*)->. IOW, a "strong" path is a path from a lock walking to 
> another
> +through the lock dependencies, and if X -> Y -> Z in the path(where X, Y, Z 
> are

Re: [RFC tip/locking/lockdep v5 16/17] lockdep: Documention for recursive read lock detection reasoning

[Andrea Parri]

On Thu, Feb 22, 2018 at 03:09:03PM +0800, Boqun Feng wrote:
> As now we support recursive read lock deadlock detection, add related
> explanation in the Documentation/lockdep/lockdep-desgin.txt:
> 
> * Definition of recursive read locks, non-recursive locks, strong
>   dependency path and notions of -(**)->.
> 
> * Lockdep's assumption.
> 
> * Informal proof of recursive read lock deadlock detection.

Once again... much appreciated!!, thanks for sharing.


> 
> Signed-off-by: Boqun Feng 
> Cc: Randy Dunlap 
> ---
>  Documentation/locking/lockdep-design.txt | 170 
> +++
>  1 file changed, 170 insertions(+)
> 
> diff --git a/Documentation/locking/lockdep-design.txt 
> b/Documentation/locking/lockdep-design.txt
> index 382bc25589c2..fd8a8d97ce58 100644
> --- a/Documentation/locking/lockdep-design.txt
> +++ b/Documentation/locking/lockdep-design.txt
> @@ -284,3 +284,173 @@ Run the command and save the output, then compare 
> against the output from
>  a later run of this command to identify the leakers.  This same output
>  can also help you find situations where runtime lock initialization has
>  been omitted.
> +
> +Recursive Read Deadlock Detection:
> +--
> +Lockdep now is equipped with deadlock detection for recursive read locks.
> +
> +Recursive read locks, as their name indicates, are the locks able to be
> +acquired recursively. Unlike non-recursive read locks, recursive read locks
> +only get blocked by current write lock *holders* other than write lock
> +*waiters*, for example:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> +
> + write_lock(X);
> +
> + read_lock(X);
> +
> +is not a deadlock for recursive read locks, as while the task B is waiting 
> for
> +the lock X, the second read_lock() doesn't need to wait because it's a 
> recursive
> +read lock.
> +
> +Note that a lock can be a write lock(exclusive lock), a non-recursive read 
> lock
> +(non-recursive shared lock) or a recursive read lock(recursive shared lock),
> +depending on the API used to acquire it(more specifically, the value of the
> +'read' parameter for lock_acquire(...)). In other words, a single lock 
> instance
> +has three types of acquisition depending on the acquisition functions:
> +exclusive, non-recursive read, and recursive read.
> +
> +That said, recursive read locks could introduce deadlocks too, considering 
> the
> +following:
> +
> + TASK A: TASK B:
> +
> + read_lock(X);
> + read_lock(Y);
> + write_lock(Y);
> + write_lock(X);
> +
> +, neither task could get the write locks because the corresponding read locks
> +are held by each other.
> +
> +Lockdep could detect recursive read lock related deadlocks. The 
> dependencies(edges)
> +in the lockdep graph are classified into four categories:
> +
> +1) -(NN)->: non-recursive to non-recursive dependency, non-recursive locks 
> include
> +non-recursive read locks, write locks and exclusive locks(e.g. 
> spinlock_t).
> + They are treated equally in deadlock detection. "X -(NN)-> Y" means
> +X -> Y and both X and Y are non-recursive locks.
> +
> +2) -(RN)->: recursive to non-recursive dependency, recursive locks means 
> recursive read
> + locks. "X -(RN)-> Y" means X -> Y and X is recursive read lock and
> +Y is non-recursive lock.
> +
> +3) -(NR)->: non-recursive to recursive dependency, "X -(NR)-> Y" means X -> 
> Y and X is
> +non-recursive lock and Y is recursive lock.
> +
> +4) -(RR)->: recursive to recursive dependency, "X -(RR)-> Y" means X -> Y 
> and both X
> +and Y are recursive locks.
> +
> +Note that given two locks, they may have multiple dependencies between them, 
> for example:
> +
> + TASK A:
> +
> + read_lock(X);
> + write_lock(Y);
> + ...
> +
> + TASK B:
> +
> + write_lock(X);
> + write_lock(Y);
> +
> +, we have both X -(RN)-> Y and X -(NN)-> Y in the dependency graph.
> +
> +And obviously a non-recursive lock can block the corresponding recursive 
> lock,
> +and vice versa. Besides a non-recursive lock may block the other 
> non-recursive
> +lock of the same instance(e.g. a write lock may block a corresponding
> +non-recursive read lock and vice versa).
> +
> +We use -(*N)-> for edges that is either -(RN)-> or -(NN)->, the similar for 
> -(N*)->,
> +-(*R)-> and -(R*)->
> +
> +A "path" is a series of conjunct dependency edges in the graph. And we 
> define a
> +"strong" path, which indicates the strong dependency throughout each 
> dependency
> +in the path, as the path that doesn't have two conjunct edges(dependencies) 
> as
> +-(*R)-> and -(R*)->. IOW, a "strong" path is a path from a lock walking to 
> another
> +through the lock dependencies, and if X -> Y -> Z in the path(where X, Y, Z 
> are
> +locks), if the walk from X to Y is through 

Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

[Akira Yokosawa]

On 2018/02/24 10:08:14 -0800, Paul E. McKenney wrote:
> On Sat, Feb 24, 2018 at 11:49:20AM -0500, Alan Stern wrote:
>> On Sat, 24 Feb 2018, Andrea Parri wrote:
>>
>>> On Fri, Feb 23, 2018 at 07:30:13PM -0800, Paul E. McKenney wrote:
 On Sat, Feb 24, 2018 at 12:22:24PM +0900, Akira Yokosawa wrote:
> On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote:
>> On 2018/02/22 2:15, Alan Stern wrote:
>>>
>>> [...]
>>>
>>>
>>> Akira pointed out some typos in the original patch, and he noted that
>>> cheatsheet.txt should be updated to indicate how unsuccessful RMW
>>> operations relate to address dependencies.
>>
>> My point was to separate unannotated loads from READ_ONCE(), if the
>> cheatsheet should concern such accesses as well.
>> Unsuccessful RMW operations were brought up by Andrea.
>>
>
> Paul, can you amend above paragraph in the change log to something like:
>
> Akira pointed out some typos in the original patch, and he noted that
> cheatsheet.txt should be updated to indicate READ_ONCE() implies
> address dependency, which invited Andrea's observation that it should
> also be updated to indicate how unsuccessful RMW operations relate to
> address dependencies.
>
> , if Alan and Andrea are OK with the amendment.
>
> Also, please append my Acked-by.
>
> Acked-by: Akira Yokosawa 

 I can still amend this, and have added your Acked-by.  If Alan and Andrea
 OK with your change, I will apply that also.
>>>
>>> LGTM. Thanks,
>>
>> Me too.
> 
> Very good, how about this for the new version?
> 
>   Thanx, Paul
> 
> 
> 
> commit 21ede43970e50b7397420f17ed08bb02c187e2eb
> Author: Alan Stern 
> Date:   Wed Feb 21 12:15:56 2018 -0500
> 
> tools/memory-model: Update: Remove rb-dep, smp_read_barrier_depends, and 
> lockless_dereference
> 
> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference") was accidentally
> merged too early, while it was still in RFC form.  This patch adds in
> the missing pieces.
> 
> Akira pointed out some typos in the original patch, and he noted that
> cheatsheet.txt should indicate that READ_ONCE() now implies an address
> dependency.  Andrea suggested documenting the relationship betwwen
> unsuccessful RMW operations and address dependencies.

Looks good. But I've found a remaining typo in the patch. See below.

> > Andrea pointed out that the macro for rcu_dereference() in linux.def
> should now use the "once" annotation instead of "deref".  He also
> suggested that the comments should mention commit 5a8897cc7631
> ("locking/atomics/alpha: Add smp_read_barrier_depends() to
> _release()/_relaxed() atomics") as an important precursor, and he
> contributed commit cb13b424e986 ("locking/xchg/alpha: Add
> unconditional memory barrier to cmpxchg()"), another prerequisite.
> 
> Signed-off-by: Alan Stern 
> Suggested-by: Akira Yokosawa 
> Suggested-by: Andrea Parri 
> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep, 
> smp_read_barrier_depends, and lockless_dereference")
> Acked-by: Andrea Parri 
> Acked-by: Akira Yokosawa 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/tools/memory-model/Documentation/cheatsheet.txt 
> b/tools/memory-model/Documentation/cheatsheet.txt
> index 04e458acd6d4..956b1ae4aafb 100644
> --- a/tools/memory-model/Documentation/cheatsheet.txt
> +++ b/tools/memory-model/Documentation/cheatsheet.txt
> @@ -1,11 +1,11 @@
>Prior Operation Subsequent Operation
>---  
> ---
> C  Self  R  W  RWM  Self  R  W  DR  DW  RMW  
> SV
> -  __    -  -  ---    -  -  --  --  ---  
> --
> +  --    -  -  ---    -  -  --  --  ---  
> --
>  
>  Store, e.g., WRITE_ONCE()Y   
> Y
> -Load, e.g., READ_ONCE()  Y  Y
> Y
> -Unsuccessful RMW operation   Y  Y
> Y
> +Load, e.g., READ_ONCE()  Y  Y   Y
> Y
> +Unsuccessful RMW operation   Y  Y   Y
> Y
>  rcu_dereference()Y  Y   Y
> Y
>  Successful *_acquire()   R   Y  Y   Y   YY   
> Y
>  Successful *_release() CY  Y

Re: [PATCH] tools/memory-model: update: remove rb-dep, smp_read_barrier_depends, and lockless_dereference

[Akira Yokosawa]

On 2018/02/24 10:08:14 -0800, Paul E. McKenney wrote:
> On Sat, Feb 24, 2018 at 11:49:20AM -0500, Alan Stern wrote:
>> On Sat, 24 Feb 2018, Andrea Parri wrote:
>>
>>> On Fri, Feb 23, 2018 at 07:30:13PM -0800, Paul E. McKenney wrote:
 On Sat, Feb 24, 2018 at 12:22:24PM +0900, Akira Yokosawa wrote:
> On 2018/02/22 07:29:02 +0900, Akira Yokosawa wrote:
>> On 2018/02/22 2:15, Alan Stern wrote:
>>>
>>> [...]
>>>
>>>
>>> Akira pointed out some typos in the original patch, and he noted that
>>> cheatsheet.txt should be updated to indicate how unsuccessful RMW
>>> operations relate to address dependencies.
>>
>> My point was to separate unannotated loads from READ_ONCE(), if the
>> cheatsheet should concern such accesses as well.
>> Unsuccessful RMW operations were brought up by Andrea.
>>
>
> Paul, can you amend above paragraph in the change log to something like:
>
> Akira pointed out some typos in the original patch, and he noted that
> cheatsheet.txt should be updated to indicate READ_ONCE() implies
> address dependency, which invited Andrea's observation that it should
> also be updated to indicate how unsuccessful RMW operations relate to
> address dependencies.
>
> , if Alan and Andrea are OK with the amendment.
>
> Also, please append my Acked-by.
>
> Acked-by: Akira Yokosawa 

 I can still amend this, and have added your Acked-by.  If Alan and Andrea
 OK with your change, I will apply that also.
>>>
>>> LGTM. Thanks,
>>
>> Me too.
> 
> Very good, how about this for the new version?
> 
>   Thanx, Paul
> 
> 
> 
> commit 21ede43970e50b7397420f17ed08bb02c187e2eb
> Author: Alan Stern 
> Date:   Wed Feb 21 12:15:56 2018 -0500
> 
> tools/memory-model: Update: Remove rb-dep, smp_read_barrier_depends, and 
> lockless_dereference
> 
> Commit bf28ae562744 ("tools/memory-model: Remove rb-dep,
> smp_read_barrier_depends, and lockless_dereference") was accidentally
> merged too early, while it was still in RFC form.  This patch adds in
> the missing pieces.
> 
> Akira pointed out some typos in the original patch, and he noted that
> cheatsheet.txt should indicate that READ_ONCE() now implies an address
> dependency.  Andrea suggested documenting the relationship betwwen
> unsuccessful RMW operations and address dependencies.

Looks good. But I've found a remaining typo in the patch. See below.

> > Andrea pointed out that the macro for rcu_dereference() in linux.def
> should now use the "once" annotation instead of "deref".  He also
> suggested that the comments should mention commit 5a8897cc7631
> ("locking/atomics/alpha: Add smp_read_barrier_depends() to
> _release()/_relaxed() atomics") as an important precursor, and he
> contributed commit cb13b424e986 ("locking/xchg/alpha: Add
> unconditional memory barrier to cmpxchg()"), another prerequisite.
> 
> Signed-off-by: Alan Stern 
> Suggested-by: Akira Yokosawa 
> Suggested-by: Andrea Parri 
> Fixes: bf28ae562744 ("tools/memory-model: Remove rb-dep, 
> smp_read_barrier_depends, and lockless_dereference")
> Acked-by: Andrea Parri 
> Acked-by: Akira Yokosawa 
> Signed-off-by: Paul E. McKenney 
> 
> diff --git a/tools/memory-model/Documentation/cheatsheet.txt 
> b/tools/memory-model/Documentation/cheatsheet.txt
> index 04e458acd6d4..956b1ae4aafb 100644
> --- a/tools/memory-model/Documentation/cheatsheet.txt
> +++ b/tools/memory-model/Documentation/cheatsheet.txt
> @@ -1,11 +1,11 @@
>Prior Operation Subsequent Operation
>---  
> ---
> C  Self  R  W  RWM  Self  R  W  DR  DW  RMW  
> SV
> -  __    -  -  ---    -  -  --  --  ---  
> --
> +  --    -  -  ---    -  -  --  --  ---  
> --
>  
>  Store, e.g., WRITE_ONCE()Y   
> Y
> -Load, e.g., READ_ONCE()  Y  Y
> Y
> -Unsuccessful RMW operation   Y  Y
> Y
> +Load, e.g., READ_ONCE()  Y  Y   Y
> Y
> +Unsuccessful RMW operation   Y  Y   Y
> Y
>  rcu_dereference()Y  Y   Y
> Y
>  Successful *_acquire()   R   Y  Y   Y   YY   
> Y
>  Successful *_release() CY  YY W  
> Y
> diff --git a/tools/memory-model/Documentation/explanation.txt 
> b/tools/memory-model/Documentation/explanation.txt
> index 

[PATCH] i2c: xiic: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
error branch.

Fixes: 36ecbcab84d0 ("i2c: xiic: Implement power management")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-xiic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index ae6ed254e01d..fd03e40ca832 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -682,8 +682,10 @@ static int xiic_xfer(struct i2c_adapter *adap, struct 
i2c_msg *msgs, int num)
xiic_getreg8(i2c, XIIC_SR_REG_OFFSET));
 
err = pm_runtime_get_sync(i2c->dev);
-   if (err < 0)
+   if (err < 0) {
+   pm_runtime_put_noidle(i2c->dev);
return err;
+   }
 
err = xiic_busy(i2c);
if (err)
-- 
2.11.0

[PATCH] i2c: xiic: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
error branch.

Fixes: 36ecbcab84d0 ("i2c: xiic: Implement power management")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-xiic.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-xiic.c b/drivers/i2c/busses/i2c-xiic.c
index ae6ed254e01d..fd03e40ca832 100644
--- a/drivers/i2c/busses/i2c-xiic.c
+++ b/drivers/i2c/busses/i2c-xiic.c
@@ -682,8 +682,10 @@ static int xiic_xfer(struct i2c_adapter *adap, struct 
i2c_msg *msgs, int num)
xiic_getreg8(i2c, XIIC_SR_REG_OFFSET));
 
err = pm_runtime_get_sync(i2c->dev);
-   if (err < 0)
+   if (err < 0) {
+   pm_runtime_put_noidle(i2c->dev);
return err;
+   }
 
err = xiic_busy(i2c);
if (err)
-- 
2.11.0

[PATCH] i2c: tegra: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
related error branches.

Fixes: 1f50ad2c86cd ("i2c: tegra: Add runtime power-management support")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-tegra.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 60292d243e24..d53136538339 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -484,6 +484,7 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
err = pm_runtime_get_sync(i2c_dev->dev);
if (err < 0) {
dev_err(i2c_dev->dev, "runtime resume failed %d\n", err);
+   pm_runtime_put_noidle(i2c_dev->dev);
return err;
}
 
@@ -740,6 +741,7 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct 
i2c_msg msgs[],
ret = pm_runtime_get_sync(i2c_dev->dev);
if (ret < 0) {
dev_err(i2c_dev->dev, "runtime resume failed %d\n", ret);
+   pm_runtime_put_noidle(i2c_dev->dev);
return ret;
}
 
-- 
2.11.0

[PATCH] i2c: tegra: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
related error branches.

Fixes: 1f50ad2c86cd ("i2c: tegra: Add runtime power-management support")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-tegra.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-tegra.c b/drivers/i2c/busses/i2c-tegra.c
index 60292d243e24..d53136538339 100644
--- a/drivers/i2c/busses/i2c-tegra.c
+++ b/drivers/i2c/busses/i2c-tegra.c
@@ -484,6 +484,7 @@ static int tegra_i2c_init(struct tegra_i2c_dev *i2c_dev)
err = pm_runtime_get_sync(i2c_dev->dev);
if (err < 0) {
dev_err(i2c_dev->dev, "runtime resume failed %d\n", err);
+   pm_runtime_put_noidle(i2c_dev->dev);
return err;
}
 
@@ -740,6 +741,7 @@ static int tegra_i2c_xfer(struct i2c_adapter *adap, struct 
i2c_msg msgs[],
ret = pm_runtime_get_sync(i2c_dev->dev);
if (ret < 0) {
dev_err(i2c_dev->dev, "runtime resume failed %d\n", ret);
+   pm_runtime_put_noidle(i2c_dev->dev);
return ret;
}
 
-- 
2.11.0

[PATCH] i2c: sprd: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
related error branches.

Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-sprd.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
index 25fcc3c1e32b..5dae56e9ef73 100644
--- a/drivers/i2c/busses/i2c-sprd.c
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -284,8 +284,10 @@ static int sprd_i2c_master_xfer(struct i2c_adapter 
*i2c_adap,
int im, ret;
 
ret = pm_runtime_get_sync(i2c_dev->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+   }
 
for (im = 0; im < num - 1; im++) {
ret = sprd_i2c_handle_msg(i2c_adap, [im], 0);
@@ -572,8 +574,10 @@ static int sprd_i2c_remove(struct platform_device *pdev)
int ret;
 
ret = pm_runtime_get_sync(i2c_dev->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+   }
 
i2c_del_adapter(_dev->adap);
clk_disable_unprepare(i2c_dev->clk);
-- 
2.11.0

[PATCH] i2c: sprd: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
related error branches.

Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-sprd.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-sprd.c b/drivers/i2c/busses/i2c-sprd.c
index 25fcc3c1e32b..5dae56e9ef73 100644
--- a/drivers/i2c/busses/i2c-sprd.c
+++ b/drivers/i2c/busses/i2c-sprd.c
@@ -284,8 +284,10 @@ static int sprd_i2c_master_xfer(struct i2c_adapter 
*i2c_adap,
int im, ret;
 
ret = pm_runtime_get_sync(i2c_dev->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+   }
 
for (im = 0; im < num - 1; im++) {
ret = sprd_i2c_handle_msg(i2c_adap, [im], 0);
@@ -572,8 +574,10 @@ static int sprd_i2c_remove(struct platform_device *pdev)
int ret;
 
ret = pm_runtime_get_sync(i2c_dev->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(i2c_dev->dev);
return ret;
+   }
 
i2c_del_adapter(_dev->adap);
clk_disable_unprepare(i2c_dev->clk);
-- 
2.11.0

[PATCH] i2c: imx-lpi2c: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
error branch.

Fixes: 13d6eb20fc79 ("i2c: imx-lpi2c: add runtime pm support")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-imx-lpi2c.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c 
b/drivers/i2c/busses/i2c-imx-lpi2c.c
index e6da2c7a9a3e..793050da3ae3 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -278,8 +278,10 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct 
*lpi2c_imx)
int ret;
 
ret = pm_runtime_get_sync(lpi2c_imx->adapter.dev.parent);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(lpi2c_imx->adapter.dev.parent);
return ret;
+   }
 
temp = MCR_RST;
writel(temp, lpi2c_imx->base + LPI2C_MCR);
-- 
2.11.0

[PATCH] i2c: imx-lpi2c: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
error branch.

Fixes: 13d6eb20fc79 ("i2c: imx-lpi2c: add runtime pm support")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-imx-lpi2c.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-imx-lpi2c.c 
b/drivers/i2c/busses/i2c-imx-lpi2c.c
index e6da2c7a9a3e..793050da3ae3 100644
--- a/drivers/i2c/busses/i2c-imx-lpi2c.c
+++ b/drivers/i2c/busses/i2c-imx-lpi2c.c
@@ -278,8 +278,10 @@ static int lpi2c_imx_master_enable(struct lpi2c_imx_struct 
*lpi2c_imx)
int ret;
 
ret = pm_runtime_get_sync(lpi2c_imx->adapter.dev.parent);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(lpi2c_imx->adapter.dev.parent);
return ret;
+   }
 
temp = MCR_RST;
writel(temp, lpi2c_imx->base + LPI2C_MCR);
-- 
2.11.0

[PATCH] i2c: img-scb: fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
error branch.

Fixes: 93222bd9b966 ("i2c: img-scb: Add runtime PM")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-img-scb.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-img-scb.c b/drivers/i2c/busses/i2c-img-scb.c
index f038858b6c54..569a1a8a2753 100644
--- a/drivers/i2c/busses/i2c-img-scb.c
+++ b/drivers/i2c/busses/i2c-img-scb.c
@@ -1061,8 +1061,10 @@ static int img_i2c_xfer(struct i2c_adapter *adap, struct 
i2c_msg *msgs,
}
 
ret = pm_runtime_get_sync(adap->dev.parent);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(adap->dev.parent);
return ret;
+   }
 
for (i = 0; i < num; i++) {
struct i2c_msg *msg = [i];
@@ -1162,8 +1164,10 @@ static int img_i2c_init(struct img_i2c *i2c)
int ret;
 
ret = pm_runtime_get_sync(i2c->adap.dev.parent);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(i2c->adap.dev.parent);
return ret;
+   }
 
rev = img_i2c_readl(i2c, SCB_CORE_REV_REG);
if ((rev & 0x00ff) < 0x00020200) {
-- 
2.11.0

[PATCH] i2c: imx: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
related error branches.

Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the
  performance")
Signed-off-by: Tobias Jordan 
---
In i2c_imx_xfer(), one could also move the "out" label up (in front of
the call to pm_runtime_put_autosuspend()), but I'm not sure what the
underlying error scenario is; calling _put_noidle() seems to be the
safer bet.

This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-imx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 999557729ad2..dae3c923d42c 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -890,8 +890,10 @@ static int i2c_imx_xfer(struct i2c_adapter *adapter,
dev_dbg(_imx->adapter.dev, "<%s>\n", __func__);
 
result = pm_runtime_get_sync(i2c_imx->adapter.dev.parent);
-   if (result < 0)
+   if (result < 0) {
+   pm_runtime_put_noidle(i2c_imx->adapter.dev.parent);
goto out;
+   }
 
/* Start I2C transfer */
result = i2c_imx_start(i2c_imx);
@@ -1179,8 +1181,10 @@ static int i2c_imx_remove(struct platform_device *pdev)
int ret;
 
ret = pm_runtime_get_sync(>dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
return ret;
+   }
 
/* remove adapter */
dev_dbg(_imx->adapter.dev, "adapter removed\n");
-- 
2.11.0

[PATCH] i2c: img-scb: fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
error branch.

Fixes: 93222bd9b966 ("i2c: img-scb: Add runtime PM")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-img-scb.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-img-scb.c b/drivers/i2c/busses/i2c-img-scb.c
index f038858b6c54..569a1a8a2753 100644
--- a/drivers/i2c/busses/i2c-img-scb.c
+++ b/drivers/i2c/busses/i2c-img-scb.c
@@ -1061,8 +1061,10 @@ static int img_i2c_xfer(struct i2c_adapter *adap, struct 
i2c_msg *msgs,
}
 
ret = pm_runtime_get_sync(adap->dev.parent);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(adap->dev.parent);
return ret;
+   }
 
for (i = 0; i < num; i++) {
struct i2c_msg *msg = [i];
@@ -1162,8 +1164,10 @@ static int img_i2c_init(struct img_i2c *i2c)
int ret;
 
ret = pm_runtime_get_sync(i2c->adap.dev.parent);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(i2c->adap.dev.parent);
return ret;
+   }
 
rev = img_i2c_readl(i2c, SCB_CORE_REV_REG);
if ((rev & 0x00ff) < 0x00020200) {
-- 
2.11.0

[PATCH] i2c: imx: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
related error branches.

Fixes: 588eb93ea49f ("i2c: imx: add runtime pm support to improve the
  performance")
Signed-off-by: Tobias Jordan 
---
In i2c_imx_xfer(), one could also move the "out" label up (in front of
the call to pm_runtime_put_autosuspend()), but I'm not sure what the
underlying error scenario is; calling _put_noidle() seems to be the
safer bet.

This is one of a number of patches for problems found using coccinelle 
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-imx.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 999557729ad2..dae3c923d42c 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -890,8 +890,10 @@ static int i2c_imx_xfer(struct i2c_adapter *adapter,
dev_dbg(_imx->adapter.dev, "<%s>\n", __func__);
 
result = pm_runtime_get_sync(i2c_imx->adapter.dev.parent);
-   if (result < 0)
+   if (result < 0) {
+   pm_runtime_put_noidle(i2c_imx->adapter.dev.parent);
goto out;
+   }
 
/* Start I2C transfer */
result = i2c_imx_start(i2c_imx);
@@ -1179,8 +1181,10 @@ static int i2c_imx_remove(struct platform_device *pdev)
int ret;
 
ret = pm_runtime_get_sync(>dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(>dev);
return ret;
+   }
 
/* remove adapter */
dev_dbg(_imx->adapter.dev, "adapter removed\n");
-- 
2.11.0

[PATCH] i2c: cadence: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
error branch.

Fixes: 7fa32329ca03 ("i2c: cadence: Move to sensible power management")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-cadence.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index b13605718291..898faa7fbac5 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -574,8 +574,10 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap, 
struct i2c_msg *msgs,
bool hold_quirk;
 
ret = pm_runtime_get_sync(id->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(id->dev);
return ret;
+   }
/* Check if the bus is free */
if (cdns_i2c_readreg(CDNS_I2C_SR_OFFSET) & CDNS_I2C_SR_BA) {
ret = -EAGAIN;
-- 
2.11.0

[PATCH] i2c: cadence: Fix PM device usage count

[Tobias Jordan]

pm_runtime_get_sync() increases the device's usage count even when
reporting an error, so add a call to pm_runtime_put_noidle() in the
error branch.

Fixes: 7fa32329ca03 ("i2c: cadence: Move to sensible power management")
Signed-off-by: Tobias Jordan 
---
This is one of a number of patches for problems found using coccinelle
scripting in the SIL2LinuxMP project. The patch has been compile-tested;
it's based on linux-next-20180223.

For a discussion of the corresponding issue, see
https://marc.info/?l=linux-pm=151904483924999=2

 drivers/i2c/busses/i2c-cadence.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-cadence.c b/drivers/i2c/busses/i2c-cadence.c
index b13605718291..898faa7fbac5 100644
--- a/drivers/i2c/busses/i2c-cadence.c
+++ b/drivers/i2c/busses/i2c-cadence.c
@@ -574,8 +574,10 @@ static int cdns_i2c_master_xfer(struct i2c_adapter *adap, 
struct i2c_msg *msgs,
bool hold_quirk;
 
ret = pm_runtime_get_sync(id->dev);
-   if (ret < 0)
+   if (ret < 0) {
+   pm_runtime_put_noidle(id->dev);
return ret;
+   }
/* Check if the bus is free */
if (cdns_i2c_readreg(CDNS_I2C_SR_OFFSET) & CDNS_I2C_SR_BA) {
ret = -EAGAIN;
-- 
2.11.0

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

[James Smart]

About to post a patch to fix. Rather than fidgeting with the copy 
routine, I want to go back to what we originally proposed - writeq() on 
64bit, writel() on 32-bit.


-- james


On 2/23/2018 1:02 PM, Arnd Bergmann wrote:

On Fri, Feb 23, 2018 at 4:36 PM, Arnd Bergmann  wrote:

@@ -138,12 +137,10 @@ lpfc_sli4_wq_put(struct lpfc_queue *q, union lpfc_wqe 
*wqe)
 if (q->phba->sli3_options & LPFC_SLI4_PHWQ_ENABLED)
 bf_set(wqe_wqid, >generic.wqe_com, q->queue_id);
 lpfc_sli_pcimem_bcopy(wqe, temp_wqe, q->entry_size);
-   if (q->dpp_enable && q->phba->cfg_enable_dpp) {
+   if (q->dpp_enable && q->phba->cfg_enable_dpp)
 /* write to DPP aperture taking advatage of Combined Writes */
-   tmp = (uint8_t *)wqe;
-   for (i = 0; i < q->entry_size; i += sizeof(uint64_t))
-   writeq(*((uint64_t *)(tmp + i)), q->dpp_regaddr + i);
-   }
+   memcpy_toio(tmp, q->dpp_regaddr, q->entry_size);
+
 /* ensure WQE bcopy and DPP flushed before doorbell write */
 wmb();


Not sure where we are with the question of whether memcpy_toio
is a good replacement or not, but further build testing showed that
my patch was completely broken in more than one way:

I mixed up the source and destination arguments, and I used
the uninitialized 'tmp' instead of 'wqe'. Don't try this patch.

Arnd

Re: [PATCH] scsi: lpfc: use memcpy_toio instead of writeq

[James Smart]

About to post a patch to fix. Rather than fidgeting with the copy 
routine, I want to go back to what we originally proposed - writeq() on 
64bit, writel() on 32-bit.


-- james


On 2/23/2018 1:02 PM, Arnd Bergmann wrote:

On Fri, Feb 23, 2018 at 4:36 PM, Arnd Bergmann  wrote:

@@ -138,12 +137,10 @@ lpfc_sli4_wq_put(struct lpfc_queue *q, union lpfc_wqe 
*wqe)
 if (q->phba->sli3_options & LPFC_SLI4_PHWQ_ENABLED)
 bf_set(wqe_wqid, >generic.wqe_com, q->queue_id);
 lpfc_sli_pcimem_bcopy(wqe, temp_wqe, q->entry_size);
-   if (q->dpp_enable && q->phba->cfg_enable_dpp) {
+   if (q->dpp_enable && q->phba->cfg_enable_dpp)
 /* write to DPP aperture taking advatage of Combined Writes */
-   tmp = (uint8_t *)wqe;
-   for (i = 0; i < q->entry_size; i += sizeof(uint64_t))
-   writeq(*((uint64_t *)(tmp + i)), q->dpp_regaddr + i);
-   }
+   memcpy_toio(tmp, q->dpp_regaddr, q->entry_size);
+
 /* ensure WQE bcopy and DPP flushed before doorbell write */
 wmb();


Not sure where we are with the question of whether memcpy_toio
is a good replacement or not, but further build testing showed that
my patch was completely broken in more than one way:

I mixed up the source and destination arguments, and I used
the uninitialized 'tmp' instead of 'wqe'. Don't try this patch.

Arnd

[PATCH V1 1/3] x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Invoking efi_runtime_services() through efi_workqueue means all accesses
to efi_runtime_services() should be done after efi_rts_wq has been
created. efi_delete_dummy_variable() calls set_variable(), hence
efi_delete_dummy_variable() should be called after efi_rts_wq has been
created.

efi_delete_dummy_variable() is called from efi_enter_virtual_mode()
which is early in the boot phase (efi_rts_wq isn't created yet), so call
efi_delete_dummy_variable() later in the boot phase i.e. while
initializing efi subsystem. In the next patch, this is the place where
we create efi_rts_wq and all the efi_runtime_services() will be called
using efi_rts_wq.

Signed-off-by: Sai Praneeth Prakhya 
Suggested-by: Andy Lutomirski 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: Dave Hansen 
Cc: Mark Rutland 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ard Biesheuvel 
Cc: Dan Williams 
---
 arch/x86/include/asm/efi.h  | 1 -
 arch/x86/platform/efi/efi.c | 6 --
 drivers/firmware/efi/efi.c  | 7 +++
 include/linux/efi.h | 3 +++
 4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 85f6ccb80b91..34b03440a80f 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -130,7 +130,6 @@ extern void __init efi_runtime_update_mappings(void);
 extern void __init efi_dump_pagetable(void);
 extern void __init efi_apply_memmap_quirks(void);
 extern int __init efi_reuse_config(u64 tables, int nr_tables);
-extern void efi_delete_dummy_variable(void);
 
 struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 9061babfbc83..a3169d14583f 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -893,9 +893,6 @@ static void __init kexec_enter_virtual_mode(void)
 
if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
runtime_code_page_mkexec();
-
-   /* clean DUMMY object */
-   efi_delete_dummy_variable();
 #endif
 }
 
@@ -1015,9 +1012,6 @@ static void __init __efi_enter_virtual_mode(void)
 * necessary relocation fixups for the new virtual addresses.
 */
efi_runtime_update_mappings();
-
-   /* clean DUMMY object */
-   efi_delete_dummy_variable();
 }
 
 void __init efi_enter_virtual_mode(void)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index cd42f66a7c85..ac5db5f8dbbf 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -33,6 +33,7 @@
 #include 
 
 #include 
+#include 
 
 struct efi __read_mostly efi = {
.mps= EFI_INVALID_TABLE_ADDR,
@@ -328,6 +329,12 @@ static int __init efisubsys_init(void)
if (!efi_enabled(EFI_BOOT))
return 0;
 
+   /*
+* Clean DUMMY object calls EFI Runtime Service, set_variable(), so
+* it should be invoked only after efi_rts_workqueue is ready.
+*/
+   efi_delete_dummy_variable();
+
/* We register the efi directory at /sys/firmware/efi */
efi_kobj = kobject_create_and_add("efi", firmware_kobj);
if (!efi_kobj) {
diff --git a/include/linux/efi.h b/include/linux/efi.h
index f5083aa72eae..c4efb3ef0dfa 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -992,6 +992,7 @@ extern efi_status_t efi_query_variable_store(u32 attributes,
 unsigned long size,
 bool nonblocking);
 extern void efi_find_mirror(void);
+extern void efi_delete_dummy_variable(void);
 #else
 static inline void efi_late_init(void) {}
 static inline void efi_free_boot_services(void) {}
@@ -1002,6 +1003,8 @@ static inline efi_status_t efi_query_variable_store(u32 
attributes,
 {
return EFI_SUCCESS;
 }
+
+static inline void efi_delete_dummy_variable(void) {}
 #endif
 extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);
 
-- 
2.1.4

[PATCH V1 1/3] x86/efi: Call efi_delete_dummy_variable() during efi subsystem initialization

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Invoking efi_runtime_services() through efi_workqueue means all accesses
to efi_runtime_services() should be done after efi_rts_wq has been
created. efi_delete_dummy_variable() calls set_variable(), hence
efi_delete_dummy_variable() should be called after efi_rts_wq has been
created.

efi_delete_dummy_variable() is called from efi_enter_virtual_mode()
which is early in the boot phase (efi_rts_wq isn't created yet), so call
efi_delete_dummy_variable() later in the boot phase i.e. while
initializing efi subsystem. In the next patch, this is the place where
we create efi_rts_wq and all the efi_runtime_services() will be called
using efi_rts_wq.

Signed-off-by: Sai Praneeth Prakhya 
Suggested-by: Andy Lutomirski 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: Dave Hansen 
Cc: Mark Rutland 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ard Biesheuvel 
Cc: Dan Williams 
---
 arch/x86/include/asm/efi.h  | 1 -
 arch/x86/platform/efi/efi.c | 6 --
 drivers/firmware/efi/efi.c  | 7 +++
 include/linux/efi.h | 3 +++
 4 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 85f6ccb80b91..34b03440a80f 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -130,7 +130,6 @@ extern void __init efi_runtime_update_mappings(void);
 extern void __init efi_dump_pagetable(void);
 extern void __init efi_apply_memmap_quirks(void);
 extern int __init efi_reuse_config(u64 tables, int nr_tables);
-extern void efi_delete_dummy_variable(void);
 
 struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index 9061babfbc83..a3169d14583f 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -893,9 +893,6 @@ static void __init kexec_enter_virtual_mode(void)
 
if (efi_enabled(EFI_OLD_MEMMAP) && (__supported_pte_mask & _PAGE_NX))
runtime_code_page_mkexec();
-
-   /* clean DUMMY object */
-   efi_delete_dummy_variable();
 #endif
 }
 
@@ -1015,9 +1012,6 @@ static void __init __efi_enter_virtual_mode(void)
 * necessary relocation fixups for the new virtual addresses.
 */
efi_runtime_update_mappings();
-
-   /* clean DUMMY object */
-   efi_delete_dummy_variable();
 }
 
 void __init efi_enter_virtual_mode(void)
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index cd42f66a7c85..ac5db5f8dbbf 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -33,6 +33,7 @@
 #include 
 
 #include 
+#include 
 
 struct efi __read_mostly efi = {
.mps= EFI_INVALID_TABLE_ADDR,
@@ -328,6 +329,12 @@ static int __init efisubsys_init(void)
if (!efi_enabled(EFI_BOOT))
return 0;
 
+   /*
+* Clean DUMMY object calls EFI Runtime Service, set_variable(), so
+* it should be invoked only after efi_rts_workqueue is ready.
+*/
+   efi_delete_dummy_variable();
+
/* We register the efi directory at /sys/firmware/efi */
efi_kobj = kobject_create_and_add("efi", firmware_kobj);
if (!efi_kobj) {
diff --git a/include/linux/efi.h b/include/linux/efi.h
index f5083aa72eae..c4efb3ef0dfa 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -992,6 +992,7 @@ extern efi_status_t efi_query_variable_store(u32 attributes,
 unsigned long size,
 bool nonblocking);
 extern void efi_find_mirror(void);
+extern void efi_delete_dummy_variable(void);
 #else
 static inline void efi_late_init(void) {}
 static inline void efi_free_boot_services(void) {}
@@ -1002,6 +1003,8 @@ static inline efi_status_t efi_query_variable_store(u32 
attributes,
 {
return EFI_SUCCESS;
 }
+
+static inline void efi_delete_dummy_variable(void) {}
 #endif
 extern void __iomem *efi_lookup_mapped_addr(u64 phys_addr);
 
-- 
2.1.4

[PATCH V1 3/3] efi: Use efi_rts_workqueue to invoke EFI Runtime Services

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Presently, efi_runtime_services() are executed by firmware in process
context. To execute efi_runtime_service(), kernel switches the page
directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have any
user space mappings. A potential issue could be, for instance, an NMI
interrupt (like perf) trying to profile some user data while in efi_pgd.

A solution for this issue could be to use kthread to run
efi_runtime_service(). When a user/kernel thread requests to execute
efi_runtime_service(), kernel off-loads this work to kthread which in
turn uses efi_pgd. Anything that tries to touch user space addresses
while in kthread is terminally broken. This patch adds support to efi
subsystem to handle all calls to efi_runtime_services() using a work
queue (which in turn uses kthread).

Implementation summary:
---
1. When user/kernel thread requests to execute efi_runtime_service(),
enqueue work to efi_rts_workqueue.
2. Caller thread waits until the work is finished because it's dependent
on the return status of efi_runtime_service().

pstore writes could potentially be invoked in interrupt context and it
uses set_variable<>() and query_variable_info<>() to store logs. If we
invoke efi_runtime_services() through efi_rts_wq while in atomic()
kernel issues a warning ("scheduling wile in atomic") and prints stack
trace. One way to overcome this is to not make the caller process wait
for the worker thread to finish. This approach breaks pstore i.e. the
log messages aren't written to efi variables. Hence, pstore calls
efi_runtime_services() without using efi_rts_wq or in other words
efi_rts_wq will be used unconditionally for all the
efi_runtime_services() except set_variable<>() and
query_variable_info<>()

Semantics to pack arguments in efi_runtime_work (has void pointers):
1. If argument is a pointer (of any type), pass it as is.
2. If argument is a value (of any type), address of the value is
passed.

Signed-off-by: Sai Praneeth Prakhya 
Suggested-by: Andy Lutomirski 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: Dave Hansen 
Cc: Mark Rutland 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ard Biesheuvel 
Cc: Dan Williams 
---
 drivers/firmware/efi/runtime-wrappers.c | 86 +
 1 file changed, 66 insertions(+), 20 deletions(-)

diff --git a/drivers/firmware/efi/runtime-wrappers.c 
b/drivers/firmware/efi/runtime-wrappers.c
index 5cdb787da5d3..531d077aac70 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -68,6 +68,16 @@
  * semaphore (efi_runtime_lock) and caller waits until the work is
  * finished, hence _only_ one work is queued at a time. So, queue_work()
  * should never fail.
+ *
+ * efi_rts_workqueue to run efi_runtime_services() shouldn't be used
+ * while in atomic, because caller thread might sleep. pstore writes
+ * could potentially be invoked in interrupt context and it uses
+ * set_variable<>() and query_variable_info<>(), so pstore code doesn't
+ * use efi_rts_workqueue.
+ *
+ * Semantics that caller function should follow while passing arguments:
+ * 1. If argument is a pointer (of any type), pass it as is.
+ * 2. If argument is a value (of any type), address of the value is passed.
  */
 #define efi_queue_work(_rts, _arg1, _arg2, _arg3, _arg4, _arg5)
\
 ({ \
@@ -150,7 +160,7 @@ static efi_status_t virt_efi_get_time(efi_time_t *tm, 
efi_time_cap_t *tc)
 
if (down_interruptible(_runtime_lock))
return EFI_ABORTED;
-   status = efi_call_virt(get_time, tm, tc);
+   status = efi_queue_work(GET_TIME, tm, tc, NULL, NULL, NULL);
up(_runtime_lock);
return status;
 }
@@ -161,7 +171,7 @@ static efi_status_t virt_efi_set_time(efi_time_t *tm)
 
if (down_interruptible(_runtime_lock))
return EFI_ABORTED;
-   status = efi_call_virt(set_time, tm);
+   status = efi_queue_work(SET_TIME, tm, NULL, NULL, NULL, NULL);
up(_runtime_lock);
return status;
 }
@@ -174,7 +184,8 @@ static efi_status_t virt_efi_get_wakeup_time(efi_bool_t 
*enabled,
 
if (down_interruptible(_runtime_lock))
return EFI_ABORTED;
-   status = efi_call_virt(get_wakeup_time, enabled, pending, tm);
+   status = efi_queue_work(GET_WAKEUP_TIME, enabled, pending, tm, NULL,
+   NULL);
up(_runtime_lock);
return status;
 }
@@ -185,7 

[PATCH V1 3/3] efi: Use efi_rts_workqueue to invoke EFI Runtime Services

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Presently, efi_runtime_services() are executed by firmware in process
context. To execute efi_runtime_service(), kernel switches the page
directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have any
user space mappings. A potential issue could be, for instance, an NMI
interrupt (like perf) trying to profile some user data while in efi_pgd.

A solution for this issue could be to use kthread to run
efi_runtime_service(). When a user/kernel thread requests to execute
efi_runtime_service(), kernel off-loads this work to kthread which in
turn uses efi_pgd. Anything that tries to touch user space addresses
while in kthread is terminally broken. This patch adds support to efi
subsystem to handle all calls to efi_runtime_services() using a work
queue (which in turn uses kthread).

Implementation summary:
---
1. When user/kernel thread requests to execute efi_runtime_service(),
enqueue work to efi_rts_workqueue.
2. Caller thread waits until the work is finished because it's dependent
on the return status of efi_runtime_service().

pstore writes could potentially be invoked in interrupt context and it
uses set_variable<>() and query_variable_info<>() to store logs. If we
invoke efi_runtime_services() through efi_rts_wq while in atomic()
kernel issues a warning ("scheduling wile in atomic") and prints stack
trace. One way to overcome this is to not make the caller process wait
for the worker thread to finish. This approach breaks pstore i.e. the
log messages aren't written to efi variables. Hence, pstore calls
efi_runtime_services() without using efi_rts_wq or in other words
efi_rts_wq will be used unconditionally for all the
efi_runtime_services() except set_variable<>() and
query_variable_info<>()

Semantics to pack arguments in efi_runtime_work (has void pointers):
1. If argument is a pointer (of any type), pass it as is.
2. If argument is a value (of any type), address of the value is
passed.

Signed-off-by: Sai Praneeth Prakhya 
Suggested-by: Andy Lutomirski 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: Dave Hansen 
Cc: Mark Rutland 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ard Biesheuvel 
Cc: Dan Williams 
---
 drivers/firmware/efi/runtime-wrappers.c | 86 +
 1 file changed, 66 insertions(+), 20 deletions(-)

diff --git a/drivers/firmware/efi/runtime-wrappers.c 
b/drivers/firmware/efi/runtime-wrappers.c
index 5cdb787da5d3..531d077aac70 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -68,6 +68,16 @@
  * semaphore (efi_runtime_lock) and caller waits until the work is
  * finished, hence _only_ one work is queued at a time. So, queue_work()
  * should never fail.
+ *
+ * efi_rts_workqueue to run efi_runtime_services() shouldn't be used
+ * while in atomic, because caller thread might sleep. pstore writes
+ * could potentially be invoked in interrupt context and it uses
+ * set_variable<>() and query_variable_info<>(), so pstore code doesn't
+ * use efi_rts_workqueue.
+ *
+ * Semantics that caller function should follow while passing arguments:
+ * 1. If argument is a pointer (of any type), pass it as is.
+ * 2. If argument is a value (of any type), address of the value is passed.
  */
 #define efi_queue_work(_rts, _arg1, _arg2, _arg3, _arg4, _arg5)
\
 ({ \
@@ -150,7 +160,7 @@ static efi_status_t virt_efi_get_time(efi_time_t *tm, 
efi_time_cap_t *tc)
 
if (down_interruptible(_runtime_lock))
return EFI_ABORTED;
-   status = efi_call_virt(get_time, tm, tc);
+   status = efi_queue_work(GET_TIME, tm, tc, NULL, NULL, NULL);
up(_runtime_lock);
return status;
 }
@@ -161,7 +171,7 @@ static efi_status_t virt_efi_set_time(efi_time_t *tm)
 
if (down_interruptible(_runtime_lock))
return EFI_ABORTED;
-   status = efi_call_virt(set_time, tm);
+   status = efi_queue_work(SET_TIME, tm, NULL, NULL, NULL, NULL);
up(_runtime_lock);
return status;
 }
@@ -174,7 +184,8 @@ static efi_status_t virt_efi_get_wakeup_time(efi_bool_t 
*enabled,
 
if (down_interruptible(_runtime_lock))
return EFI_ABORTED;
-   status = efi_call_virt(get_wakeup_time, enabled, pending, tm);
+   status = efi_queue_work(GET_WAKEUP_TIME, enabled, pending, tm, NULL,
+   NULL);
up(_runtime_lock);
return status;
 }
@@ -185,7 +196,8 @@ static efi_status_t virt_efi_set_wakeup_time(efi_bool_t 
enabled, efi_time_t *tm)
 
if (down_interruptible(_runtime_lock))
return EFI_ABORTED;
-   status = efi_call_virt(set_wakeup_time, enabled, tm);
+   status = efi_queue_work(SET_WAKEUP_TIME, , tm, NULL, NULL,
+   NULL);
up(_runtime_lock);

[PATCH V1 2/3] efi: Introduce efi_rts_workqueue and necessary infrastructure to invoke all efi_runtime_services()

[Sai Praneeth Prakhya]

From: Sai Praneeth 

When a process requests the kernel to execute any efi_runtime_service(),
the requested efi_runtime_service (represented as an identifier) and its
arguments are packed into a struct named efi_runtime_work and queued
onto work queue named efi_rts_wq. The caller then waits until the work
is completed.

Introduce necessary infrastructure:
1. Creating workqueue named efi_rts_wq
2. A macro (efi_queue_work()) that
a. populates efi_runtime_work
b. queues work onto efi_rts_wq and
c. waits until worker thread returns
3. A handler function that
a. understands efi_runtime_work and
b. invokes the appropriate efi_runtime_service() with the
appropriate arguments

The caller thread has to wait until the worker thread returns, because
it's dependent on the return status of efi_runtime_service() and, in
specific cases, the arguments populated by efi_runtime_service(). Some
efi_runtime_services() takes a pointer to buffer as an argument and
fills up the buffer with requested data. For instance,
efi_get_variable() and efi_get_next_variable(). Hence, caller process
cannot just post the work and get going.

Some facts about efi_runtime_services():
1. A quick look at all the efi_runtime_services() shows that any
efi_runtime_service() has five or less arguments.
2. An argument of efi_runtime_service() can be a value (of any type)
or a pointer (of any type).
Hence, efi_runtime_work has five void pointers to store these arguments.

Semantics followed by efi_call_rts() to understand efi_runtime_work:
1. If argument was a pointer, recast it from void pointer to original
pointer type.
2. If argument was a value, recast it from void pointer to original
pointer type and dereference it.

Signed-off-by: Sai Praneeth Prakhya 
Suggested-by: Andy Lutomirski 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: Dave Hansen 
Cc: Mark Rutland 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ard Biesheuvel 
Cc: Dan Williams 
---
 drivers/firmware/efi/efi.c  |  11 +++
 drivers/firmware/efi/runtime-wrappers.c | 143 
 include/linux/efi.h |  23 +
 3 files changed, 177 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index ac5db5f8dbbf..4714b305ca90 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -76,6 +76,8 @@ static unsigned long *efi_tables[] = {
_attr_table,
 };
 
+struct workqueue_struct *efi_rts_wq;
+
 static bool disable_runtime;
 static int __init setup_noefi(char *arg)
 {
@@ -329,6 +331,15 @@ static int __init efisubsys_init(void)
if (!efi_enabled(EFI_BOOT))
return 0;
 
+   /* Create a work queue to run EFI Runtime Services */
+   efi_rts_wq = create_workqueue("efi_rts_workqueue");
+   if (!efi_rts_wq) {
+   pr_err("Failed to create efi_rts_workqueue, EFI runtime 
services "
+  "disabled.\n");
+   clear_bit(EFI_RUNTIME_SERVICES, );
+   return 0;
+   }
+
/*
 * Clean DUMMY object calls EFI Runtime Service, set_variable(), so
 * it should be invoked only after efi_rts_workqueue is ready.
diff --git a/drivers/firmware/efi/runtime-wrappers.c 
b/drivers/firmware/efi/runtime-wrappers.c
index ae54870b2788..5cdb787da5d3 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -1,6 +1,14 @@
 /*
  * runtime-wrappers.c - Runtime Services function call wrappers
  *
+ * Implementation summary:
+ * ---
+ * 1. When user/kernel thread requests to execute efi_runtime_service(),
+ * enqueue work to efi_rts_workqueue.
+ * 2. Caller thread waits until the work is finished because it's
+ * dependent on the return status and execution of efi_runtime_service().
+ * For instance, get_variable() and get_next_variable().
+ *
  * Copyright (C) 2014 Linaro Ltd. 
  *
  * Split off from arch/x86/platform/efi/efi.c
@@ -22,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 
 /*
@@ -33,6 +43,50 @@
 #define __efi_call_virt(f, args...) \
__efi_call_virt_pointer(efi.systab->runtime, f, args)
 
+/* Each EFI Runtime Service is represented with a unique number */
+#define GET_TIME   0
+#define SET_TIME   1
+#define GET_WAKEUP_TIME2
+#define SET_WAKEUP_TIME

[PATCH V1 2/3] efi: Introduce efi_rts_workqueue and necessary infrastructure to invoke all efi_runtime_services()

[Sai Praneeth Prakhya]

From: Sai Praneeth 

When a process requests the kernel to execute any efi_runtime_service(),
the requested efi_runtime_service (represented as an identifier) and its
arguments are packed into a struct named efi_runtime_work and queued
onto work queue named efi_rts_wq. The caller then waits until the work
is completed.

Introduce necessary infrastructure:
1. Creating workqueue named efi_rts_wq
2. A macro (efi_queue_work()) that
a. populates efi_runtime_work
b. queues work onto efi_rts_wq and
c. waits until worker thread returns
3. A handler function that
a. understands efi_runtime_work and
b. invokes the appropriate efi_runtime_service() with the
appropriate arguments

The caller thread has to wait until the worker thread returns, because
it's dependent on the return status of efi_runtime_service() and, in
specific cases, the arguments populated by efi_runtime_service(). Some
efi_runtime_services() takes a pointer to buffer as an argument and
fills up the buffer with requested data. For instance,
efi_get_variable() and efi_get_next_variable(). Hence, caller process
cannot just post the work and get going.

Some facts about efi_runtime_services():
1. A quick look at all the efi_runtime_services() shows that any
efi_runtime_service() has five or less arguments.
2. An argument of efi_runtime_service() can be a value (of any type)
or a pointer (of any type).
Hence, efi_runtime_work has five void pointers to store these arguments.

Semantics followed by efi_call_rts() to understand efi_runtime_work:
1. If argument was a pointer, recast it from void pointer to original
pointer type.
2. If argument was a value, recast it from void pointer to original
pointer type and dereference it.

Signed-off-by: Sai Praneeth Prakhya 
Suggested-by: Andy Lutomirski 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: Dave Hansen 
Cc: Mark Rutland 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ard Biesheuvel 
Cc: Dan Williams 
---
 drivers/firmware/efi/efi.c  |  11 +++
 drivers/firmware/efi/runtime-wrappers.c | 143 
 include/linux/efi.h |  23 +
 3 files changed, 177 insertions(+)

diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index ac5db5f8dbbf..4714b305ca90 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -76,6 +76,8 @@ static unsigned long *efi_tables[] = {
_attr_table,
 };
 
+struct workqueue_struct *efi_rts_wq;
+
 static bool disable_runtime;
 static int __init setup_noefi(char *arg)
 {
@@ -329,6 +331,15 @@ static int __init efisubsys_init(void)
if (!efi_enabled(EFI_BOOT))
return 0;
 
+   /* Create a work queue to run EFI Runtime Services */
+   efi_rts_wq = create_workqueue("efi_rts_workqueue");
+   if (!efi_rts_wq) {
+   pr_err("Failed to create efi_rts_workqueue, EFI runtime 
services "
+  "disabled.\n");
+   clear_bit(EFI_RUNTIME_SERVICES, );
+   return 0;
+   }
+
/*
 * Clean DUMMY object calls EFI Runtime Service, set_variable(), so
 * it should be invoked only after efi_rts_workqueue is ready.
diff --git a/drivers/firmware/efi/runtime-wrappers.c 
b/drivers/firmware/efi/runtime-wrappers.c
index ae54870b2788..5cdb787da5d3 100644
--- a/drivers/firmware/efi/runtime-wrappers.c
+++ b/drivers/firmware/efi/runtime-wrappers.c
@@ -1,6 +1,14 @@
 /*
  * runtime-wrappers.c - Runtime Services function call wrappers
  *
+ * Implementation summary:
+ * ---
+ * 1. When user/kernel thread requests to execute efi_runtime_service(),
+ * enqueue work to efi_rts_workqueue.
+ * 2. Caller thread waits until the work is finished because it's
+ * dependent on the return status and execution of efi_runtime_service().
+ * For instance, get_variable() and get_next_variable().
+ *
  * Copyright (C) 2014 Linaro Ltd. 
  *
  * Split off from arch/x86/platform/efi/efi.c
@@ -22,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+
 #include 
 
 /*
@@ -33,6 +43,50 @@
 #define __efi_call_virt(f, args...) \
__efi_call_virt_pointer(efi.systab->runtime, f, args)
 
+/* Each EFI Runtime Service is represented with a unique number */
+#define GET_TIME   0
+#define SET_TIME   1
+#define GET_WAKEUP_TIME2
+#define SET_WAKEUP_TIME3
+#define GET_VARIABLE   4
+#define GET_NEXT_VARIABLE  5
+#define SET_VARIABLE   6
+#define SET_VARIABLE_NONBLOCKING   7
+#define QUERY_VARIABLE_INFO8
+#define QUERY_VARIABLE_INFO_NONBLOCKING9
+#define GET_NEXT_HIGH_MONO_COUNT   

[PATCH V1 0/3] Use efi_rts_workqueue to invoke EFI Runtime Services

[Sai Praneeth Prakhya]

From: Sai Praneeth 

This patch set is an outcome of the discussion at
https://lkml.org/lkml/2017/8/21/607

Presently, efi_runtime_services() are executed by firmware in process
context. To execute efi_runtime_service(), kernel switches the page
directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have any
user space mappings. A potential issue could be, for instance, an NMI
interrupt (like perf) trying to profile some user data while in efi_pgd.

A solution for this issue could be to use kthread to run
efi_runtime_service(). When a user/kernel thread requests to execute
efi_runtime_service(), kernel off-loads this work to kthread which in
turn uses efi_pgd. Anything that tries to touch user space addresses
while in kthread is terminally broken. This patch set adds support to
the efi subsystem to handle all calls to efi_runtime_services() using a
work queue (which in turn uses kthread).

Implementation summary:
---
1. When a user/kernel thread requests to execute efi_runtime_service(),
enqueue work to a work queue, efi_rts_workqueue.
2. The caller thread waits until the work is finished because it's
dependent on the return status of efi_runtime_service() and, in specific
cases, the arguments populated by efi_runtime_service(). Some
efi_runtime_services() takes a pointer to buffer as an argument and
fills up the buffer with requested data. For instance, efi_get_variable()
and efi_get_next_variable(). Hence, the caller process cannot just post
the work and get going, it has to wait for results from firmware.

Caveat: efi_rts_workqueue to run efi_runtime_services() shouldn't be used
while in atomic, because caller thread might sleep. Presently, pstore
code doesn't use efi_rts_workqueue.

Tested using LUV (Linux UEFI Validation) for x86_64 and x86_32. Builds
fine for arm and arm64. Will appreciate the effort if someone could test
the patches on ARM (although I was able to boot with LUV for ARM).
LUV: https://01.org/linux-uefi-validation

Thanks to Ricardo and Dan for initial reviews and suggestions. Please
feel free to pour in your comments and concerns.
Note: Patches are based on Linus's kernel v4.16-rc2

Sai Praneeth (3):
  x86/efi: Call efi_delete_dummy_variable() during efi subsystem
initialization
  efi: Introduce efi_rts_workqueue and necessary infrastructure to
invoke all efi_runtime_services()
  efi: Use efi_rts_workqueue to invoke EFI Runtime Services

 arch/x86/include/asm/efi.h  |   1 -
 arch/x86/platform/efi/efi.c |   6 -
 drivers/firmware/efi/efi.c  |  18 +++
 drivers/firmware/efi/runtime-wrappers.c | 229 +---
 include/linux/efi.h |  26 
 5 files changed, 253 insertions(+), 27 deletions(-)

Signed-off-by: Sai Praneeth Prakhya 
Suggested-by: Andy Lutomirski 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: Dave Hansen 
Cc: Mark Rutland 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ard Biesheuvel 
Cc: Dan Williams 

-- 
2.1.4

[PATCH V1 0/3] Use efi_rts_workqueue to invoke EFI Runtime Services

[Sai Praneeth Prakhya]

From: Sai Praneeth 

This patch set is an outcome of the discussion at
https://lkml.org/lkml/2017/8/21/607

Presently, efi_runtime_services() are executed by firmware in process
context. To execute efi_runtime_service(), kernel switches the page
directory from swapper_pgd to efi_pgd. However, efi_pgd doesn't have any
user space mappings. A potential issue could be, for instance, an NMI
interrupt (like perf) trying to profile some user data while in efi_pgd.

A solution for this issue could be to use kthread to run
efi_runtime_service(). When a user/kernel thread requests to execute
efi_runtime_service(), kernel off-loads this work to kthread which in
turn uses efi_pgd. Anything that tries to touch user space addresses
while in kthread is terminally broken. This patch set adds support to
the efi subsystem to handle all calls to efi_runtime_services() using a
work queue (which in turn uses kthread).

Implementation summary:
---
1. When a user/kernel thread requests to execute efi_runtime_service(),
enqueue work to a work queue, efi_rts_workqueue.
2. The caller thread waits until the work is finished because it's
dependent on the return status of efi_runtime_service() and, in specific
cases, the arguments populated by efi_runtime_service(). Some
efi_runtime_services() takes a pointer to buffer as an argument and
fills up the buffer with requested data. For instance, efi_get_variable()
and efi_get_next_variable(). Hence, the caller process cannot just post
the work and get going, it has to wait for results from firmware.

Caveat: efi_rts_workqueue to run efi_runtime_services() shouldn't be used
while in atomic, because caller thread might sleep. Presently, pstore
code doesn't use efi_rts_workqueue.

Tested using LUV (Linux UEFI Validation) for x86_64 and x86_32. Builds
fine for arm and arm64. Will appreciate the effort if someone could test
the patches on ARM (although I was able to boot with LUV for ARM).
LUV: https://01.org/linux-uefi-validation

Thanks to Ricardo and Dan for initial reviews and suggestions. Please
feel free to pour in your comments and concerns.
Note: Patches are based on Linus's kernel v4.16-rc2

Sai Praneeth (3):
  x86/efi: Call efi_delete_dummy_variable() during efi subsystem
initialization
  efi: Introduce efi_rts_workqueue and necessary infrastructure to
invoke all efi_runtime_services()
  efi: Use efi_rts_workqueue to invoke EFI Runtime Services

 arch/x86/include/asm/efi.h  |   1 -
 arch/x86/platform/efi/efi.c |   6 -
 drivers/firmware/efi/efi.c  |  18 +++
 drivers/firmware/efi/runtime-wrappers.c | 229 +---
 include/linux/efi.h |  26 
 5 files changed, 253 insertions(+), 27 deletions(-)

Signed-off-by: Sai Praneeth Prakhya 
Suggested-by: Andy Lutomirski 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Will Deacon 
Cc: Dave Hansen 
Cc: Mark Rutland 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Ravi Shankar 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Ard Biesheuvel 
Cc: Dan Williams 

-- 
2.1.4

[PATCH 12/15] drm/sun4i: Allow building on arm64

[Jernej Skrabec]

64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which
is compatible to 32-bit SoCs, so allow building DRM driver for
arm64 architecture.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 7327da3bc94f..eee6bc0eaf97 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -1,6 +1,6 @@
 config DRM_SUN4I
tristate "DRM Support for Allwinner A10 Display Engine"
-   depends on DRM && ARM && COMMON_CLK
+   depends on DRM && (ARM || ARM64) && COMMON_CLK
depends on ARCH_SUNXI || COMPILE_TEST
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
-- 
2.16.2

[PATCH 12/15] drm/sun4i: Allow building on arm64

[Jernej Skrabec]

64-bit ARM SoCs from Allwinner have DE2/TCON/HDMI periphery which
is compatible to 32-bit SoCs, so allow building DRM driver for
arm64 architecture.

Signed-off-by: Jernej Skrabec 
---
 drivers/gpu/drm/sun4i/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 7327da3bc94f..eee6bc0eaf97 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -1,6 +1,6 @@
 config DRM_SUN4I
tristate "DRM Support for Allwinner A10 Display Engine"
-   depends on DRM && ARM && COMMON_CLK
+   depends on DRM && (ARM || ARM64) && COMMON_CLK
depends on ARCH_SUNXI || COMPILE_TEST
select DRM_GEM_CMA_HELPER
select DRM_KMS_HELPER
-- 
2.16.2

[PATCH 02/15] clk: sunxi-ng: h3: h5: Add minimal rate for video PLL

[Jernej Skrabec]

Although user manuals for H3 and H5 SoCs state that minimal rate
supported by video PLL is around 30 MHz, it seems that in reality
minimal rate is around 192 MHz.

Experiments showed that any rate below 96 MHz doesn't produce any video
output at all. Even at this frequency, stable output depends on right
factors. For example, when N = 4 and M = 1, output is stable and when N
= 8 and M = 2, it's not.

BSP clock driver suggest that minimum stable frequency is 192 MHz. That
would also be in line with A64 SoC, which has similar periphery.

Set minimal video PLL rate for H3/H5 to 192 MHz.

Signed-off-by: Jernej Skrabec 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 29bc0566b776..b9f39078c0b2 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -69,17 +69,18 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, 
"pll-audio-base",
   BIT(28), /* lock */
   CLK_SET_RATE_UNGATE);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video_clk, "pll-video",
-   "osc24M", 0x0010,
-   8, 7,   /* N */
-   0, 4,   /* M */
-   BIT(24),/* frac enable */
-   BIT(25),/* frac select */
-   27000,  /* frac rate 0 */
-   29700,  /* frac rate 1 */
-   BIT(31),/* gate */
-   BIT(28),/* lock */
-   CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video_clk, "pll-video",
+   "osc24M", 0x0010,
+   19200,  /* Minimum rate */
+   8, 7,   /* N */
+   0, 4,   /* M */
+   BIT(24),/* frac enable */
+   BIT(25),/* frac select */
+   27000,  /* frac rate 0 */
+   29700,  /* frac rate 1 */
+   BIT(31),/* gate */
+   BIT(28),/* lock */
+   CLK_SET_RATE_UNGATE);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
"osc24M", 0x0018,
-- 
2.16.2

[PATCH 02/15] clk: sunxi-ng: h3: h5: Add minimal rate for video PLL

[Jernej Skrabec]

Although user manuals for H3 and H5 SoCs state that minimal rate
supported by video PLL is around 30 MHz, it seems that in reality
minimal rate is around 192 MHz.

Experiments showed that any rate below 96 MHz doesn't produce any video
output at all. Even at this frequency, stable output depends on right
factors. For example, when N = 4 and M = 1, output is stable and when N
= 8 and M = 2, it's not.

BSP clock driver suggest that minimum stable frequency is 192 MHz. That
would also be in line with A64 SoC, which has similar periphery.

Set minimal video PLL rate for H3/H5 to 192 MHz.

Signed-off-by: Jernej Skrabec 
---
 drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 23 ---
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c 
b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
index 29bc0566b776..b9f39078c0b2 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
@@ -69,17 +69,18 @@ static SUNXI_CCU_NM_WITH_SDM_GATE_LOCK(pll_audio_base_clk, 
"pll-audio-base",
   BIT(28), /* lock */
   CLK_SET_RATE_UNGATE);
 
-static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_video_clk, "pll-video",
-   "osc24M", 0x0010,
-   8, 7,   /* N */
-   0, 4,   /* M */
-   BIT(24),/* frac enable */
-   BIT(25),/* frac select */
-   27000,  /* frac rate 0 */
-   29700,  /* frac rate 1 */
-   BIT(31),/* gate */
-   BIT(28),/* lock */
-   CLK_SET_RATE_UNGATE);
+static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK_MIN(pll_video_clk, "pll-video",
+   "osc24M", 0x0010,
+   19200,  /* Minimum rate */
+   8, 7,   /* N */
+   0, 4,   /* M */
+   BIT(24),/* frac enable */
+   BIT(25),/* frac select */
+   27000,  /* frac rate 0 */
+   29700,  /* frac rate 1 */
+   BIT(31),/* gate */
+   BIT(28),/* lock */
+   CLK_SET_RATE_UNGATE);
 
 static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_ve_clk, "pll-ve",
"osc24M", 0x0018,
-- 
2.16.2

Re: [PATCH] lib/test_kmod: Fix an integer overflow test

[Luis R. Rodriguez]

On Sat, Feb 24, 2018 at 11:45:16AM +0300, Dan Carpenter wrote:
> On Sat, Feb 24, 2018 at 02:59:41AM +, Luis R. Rodriguez wrote:
> > On Mon, Jan 22, 2018 at 01:27:54PM +0300, Dan Carpenter wrote:
> > > The main problem is that the parentheses are in the wrong place and the
> > > unlikely() call returns either 0 or 1 so it's never less than zero.
> > 
> > Doh, thanks, yes. Seems worth considering a grammar rule for it.
> > 
> > > The other problem is that signed integer overflows like "INT_MAX + 1" are
> > > undefined behavior.
> > 
> > Likewise.
> > 
> > This seems like another possible generic typo issue. But I would not 
> > resolve it
> > the way you did, in this particular case below num_test_devs represents the
> > number of already registered devs, before we increment. So the way to 
> > resolve
> > this would be:
> > 
> > if (num_test_devs + 1 == INT_MAX)
> > 
> > I'll get this upstream, thanks!
> 
> There is no issue if num_test_devs is INT_MAX.  But capping it at
> INT_MAX - 1 is also fine.

If num_test_devs is INT_MAX, then doing num_test_devs + 1 overflows
and as you noted that is undefined?

  Luis

Re: [PATCH] lib/test_kmod: Fix an integer overflow test

[Luis R. Rodriguez]

On Sat, Feb 24, 2018 at 11:45:16AM +0300, Dan Carpenter wrote:
> On Sat, Feb 24, 2018 at 02:59:41AM +, Luis R. Rodriguez wrote:
> > On Mon, Jan 22, 2018 at 01:27:54PM +0300, Dan Carpenter wrote:
> > > The main problem is that the parentheses are in the wrong place and the
> > > unlikely() call returns either 0 or 1 so it's never less than zero.
> > 
> > Doh, thanks, yes. Seems worth considering a grammar rule for it.
> > 
> > > The other problem is that signed integer overflows like "INT_MAX + 1" are
> > > undefined behavior.
> > 
> > Likewise.
> > 
> > This seems like another possible generic typo issue. But I would not 
> > resolve it
> > the way you did, in this particular case below num_test_devs represents the
> > number of already registered devs, before we increment. So the way to 
> > resolve
> > this would be:
> > 
> > if (num_test_devs + 1 == INT_MAX)
> > 
> > I'll get this upstream, thanks!
> 
> There is no issue if num_test_devs is INT_MAX.  But capping it at
> INT_MAX - 1 is also fine.

If num_test_devs is INT_MAX, then doing num_test_devs + 1 overflows
and as you noted that is undefined?

  Luis