Re: [PATCH v2 1/2] mm/page_alloc: Fix panic caused by passing debug_guardpage_minorder or kernelcore to command line
On Mon 24-09-18 14:42:17, Andrew Morton wrote: > On Mon, 24 Sep 2018 16:24:08 +0200 Michal Hocko wrote: > > > On Sat 22-09-18 22:53:32, zhe...@windriver.com wrote: > > > From: He Zhe > > > > > > debug_guardpage_minorder_setup and cmdline_parse_kernelcore do not check > > > input argument before using it. The argument would be a NULL pointer if > > > "debug_guardpage_minorder" or "kernelcore", without its value, is set in > > > command line and thus causes the following panic. > > > > > > PANIC: early exception 0xe3 IP 10:a08146f1 error 0 cr2 0x0 > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > 4.19.0-rc4-yocto-standard+ #11 > > > [0.00] RIP: 0010:parse_option_str+0x11/0x90 > > > ... > > > [0.00] Call Trace: > > > [0.00] cmdline_parse_kernelcore+0x19/0x41 > > > [0.00] do_early_param+0x57/0x8e > > > [0.00] parse_args+0x208/0x320 > > > [0.00] ? rdinit_setup+0x30/0x30 > > > [0.00] parse_early_options+0x29/0x2d > > > [0.00] ? rdinit_setup+0x30/0x30 > > > [0.00] parse_early_param+0x36/0x4d > > > [0.00] setup_arch+0x336/0x99e > > > [0.00] start_kernel+0x6f/0x4ee > > > [0.00] x86_64_start_reservations+0x24/0x26 > > > [0.00] x86_64_start_kernel+0x6f/0x72 > > > [0.00] secondary_startup_64+0xa4/0xb0 > > > > > > This patch adds a check to prevent the panic > > > > Is this something we deeply care about? The kernel command line > > interface is to be used by admins who know what they are doing. Using > > random or wrong values for these parameters can have detrimental effects > > on the system. This particular case would blow up early, good. At least > > it is visible immediately. This and many other parameters could have a > > seemingly valid input (e.g. not a missing value) and subtle runtime > > effect. You won't blow up immediately but the system is hardly usable > > and the early checking cannot possible catch all those cases. Take a > > mem=$N copied from one machine to another with a different memory > > layout. While 2G can be perfectly fine on one a different machine might > > result on a completely unusable system because the available RAM is > > place higher. > > > > So I am really wondering. Do we really want a lot of code to catch > > kernel command line incorrect inputs? Does it really lead to better > > quality overall? IMHO, we do have a proper documentation and we should > > trust those starting the kernel. > > No, it's not very important. It might help some people understand why > their kernel went splat in rare circumstances. And it's __init code so > the runtime impact is nil. > > It bothers me that there are many other kernel parameters which have > the same undesirable behaviour. I'd much prefer a general fixup which > gave all of them this treatment, but it's unclear how to do this. If early_param took an additional argument to tell "this really requires a parameter" then we could do it in the common code. $ git grep "early_param(\"" | wc -l 251 quite a lot of work for something that hasn't been a problem for years I guess. But maybe this would allow to remove ad-hoc checks in handlers and reduce the overal code size (in LOC) in the end. -- Michal Hocko SUSE Labs
Re: [PATCH v2 1/2] mm/page_alloc: Fix panic caused by passing debug_guardpage_minorder or kernelcore to command line
On Mon 24-09-18 14:42:17, Andrew Morton wrote: > On Mon, 24 Sep 2018 16:24:08 +0200 Michal Hocko wrote: > > > On Sat 22-09-18 22:53:32, zhe...@windriver.com wrote: > > > From: He Zhe > > > > > > debug_guardpage_minorder_setup and cmdline_parse_kernelcore do not check > > > input argument before using it. The argument would be a NULL pointer if > > > "debug_guardpage_minorder" or "kernelcore", without its value, is set in > > > command line and thus causes the following panic. > > > > > > PANIC: early exception 0xe3 IP 10:a08146f1 error 0 cr2 0x0 > > > [0.00] CPU: 0 PID: 0 Comm: swapper Not tainted > > > 4.19.0-rc4-yocto-standard+ #11 > > > [0.00] RIP: 0010:parse_option_str+0x11/0x90 > > > ... > > > [0.00] Call Trace: > > > [0.00] cmdline_parse_kernelcore+0x19/0x41 > > > [0.00] do_early_param+0x57/0x8e > > > [0.00] parse_args+0x208/0x320 > > > [0.00] ? rdinit_setup+0x30/0x30 > > > [0.00] parse_early_options+0x29/0x2d > > > [0.00] ? rdinit_setup+0x30/0x30 > > > [0.00] parse_early_param+0x36/0x4d > > > [0.00] setup_arch+0x336/0x99e > > > [0.00] start_kernel+0x6f/0x4ee > > > [0.00] x86_64_start_reservations+0x24/0x26 > > > [0.00] x86_64_start_kernel+0x6f/0x72 > > > [0.00] secondary_startup_64+0xa4/0xb0 > > > > > > This patch adds a check to prevent the panic > > > > Is this something we deeply care about? The kernel command line > > interface is to be used by admins who know what they are doing. Using > > random or wrong values for these parameters can have detrimental effects > > on the system. This particular case would blow up early, good. At least > > it is visible immediately. This and many other parameters could have a > > seemingly valid input (e.g. not a missing value) and subtle runtime > > effect. You won't blow up immediately but the system is hardly usable > > and the early checking cannot possible catch all those cases. Take a > > mem=$N copied from one machine to another with a different memory > > layout. While 2G can be perfectly fine on one a different machine might > > result on a completely unusable system because the available RAM is > > place higher. > > > > So I am really wondering. Do we really want a lot of code to catch > > kernel command line incorrect inputs? Does it really lead to better > > quality overall? IMHO, we do have a proper documentation and we should > > trust those starting the kernel. > > No, it's not very important. It might help some people understand why > their kernel went splat in rare circumstances. And it's __init code so > the runtime impact is nil. > > It bothers me that there are many other kernel parameters which have > the same undesirable behaviour. I'd much prefer a general fixup which > gave all of them this treatment, but it's unclear how to do this. If early_param took an additional argument to tell "this really requires a parameter" then we could do it in the common code. $ git grep "early_param(\"" | wc -l 251 quite a lot of work for something that hasn't been a problem for years I guess. But maybe this would allow to remove ad-hoc checks in handlers and reduce the overal code size (in LOC) in the end. -- Michal Hocko SUSE Labs
Re: [PATCH v2] remoteproc: q6v5: Add support to vote for rpmh power domains
Hi Ulf,
On 9/11/2018 5:00 PM, Ulf Hansson wrote:
+Viresh
On 4 September 2018 at 09:10, Rajendra Nayak wrote:
With rpmh ARC resources being modelled as power domains with performance
state,
we need to proxy vote on these for SDM845.
Add support to vote on multiple of them, now that genpd supports
associating
mutliple power domains to a device.
thanks for the review, looks like I missed responding to this one somehow :(
I guess it's fair to mention that the votes are, at this point, done
for maximum performance!?
Is that really needed in the long run? I mean, I guess you should walk
through the OPP library to find the needed performance level? No?
well, yes the votes are for max perf, but these are just sort of *proxy*
votes from the remoteproc driver on behalf of the firmware, up until the
time the firmware itself is up and running and can put its own requests.
So this is general practice to just vote for max clocks/regulator/perf states
because we don't really know what meets the firmware requirements.
Signed-off-by: Rajendra Nayak
---
Changes in v2:
* Drop the perf vote along with disabling the powerdomain
* pm_suspend_ignore_children() to not mess with runtime PM of children
* Detach powerdomains as part of .remove and in error path during probe,
issue reported by Brian Norris
* Use dev_pm_domain_attach_by_name() api
drivers/remoteproc/qcom_q6v5_pil.c | 111 -
1 file changed, 109 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c
b/drivers/remoteproc/qcom_q6v5_pil.c
index d7a4b9eca5d2..f4b3a9b09a5d 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -131,6 +133,7 @@ struct rproc_hexagon_res {
char **proxy_clk_names;
char **reset_clk_names;
char **active_clk_names;
+ char **pd_names;
int version;
bool need_mem_protection;
bool has_alt_reset;
@@ -155,9 +158,11 @@ struct q6v5 {
struct clk *active_clks[8];
struct clk *reset_clks[4];
struct clk *proxy_clks[4];
+ struct device *pd_devs[3];
int active_clk_count;
int reset_clk_count;
int proxy_clk_count;
+ int pd_count;
struct reg_info active_regs[1];
struct reg_info proxy_regs[3];
@@ -316,6 +321,40 @@ static void q6v5_clk_disable(struct device *dev,
clk_disable_unprepare(clks[i]);
}
+static int q6v5_powerdomain_enable(struct device *dev, struct device **devs,
+ int count)
Looks like passing the qproc struct, rather than a couple of its
member could simplify the code a bit. No strong opinion though.
sure, I will try to simplify this one.
+{
+ int i;
+
+ if (!count)
+ return 0;
+
+ if (count > 1)
+ for (i = 0; i < count; i++)
+ dev_pm_genpd_set_performance_state(devs[i], INT_MAX);
+ else
+ dev_pm_genpd_set_performance_state(dev, INT_MAX);
+
+ return pm_runtime_get_sync(dev);
+}
+
+static int q6v5_powerdomain_disable(struct device *dev, struct device **devs,
+ int count)
Ditto.
+{
+ int i;
+
+ if (!count)
+ return 0;
+
+ if (count > 1)
+ for (i = 0; i < count; i++)
+ dev_pm_genpd_set_performance_state(devs[i], 0);
+ else
+ dev_pm_genpd_set_performance_state(dev, 0);
+
+ return pm_runtime_put(dev);
+}
+
static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
bool remote_owner, phys_addr_t addr,
size_t size)
@@ -792,11 +831,18 @@ static int q6v5_start(struct rproc *rproc)
qcom_q6v5_prepare(>q6v5);
+ ret = q6v5_powerdomain_enable(qproc->dev, qproc->pd_devs,
+ qproc->pd_count);
+ if (ret < 0) {
+ dev_err(qproc->dev, "failed to enable power domains\n");
+ goto disable_irqs;
+ }
+
ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
qproc->proxy_reg_count);
if (ret) {
dev_err(qproc->dev, "failed to enable proxy supplies\n");
- goto disable_irqs;
+ goto disable_powerdomains;
}
ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
@@ -920,6 +966,8 @@ static int q6v5_start(struct rproc *rproc)
q6v5_regulator_disable(qproc, qproc->proxy_regs,
qproc->proxy_reg_count);
+disable_powerdomains:
+ q6v5_powerdomain_disable(qproc->dev, qproc->pd_devs, qproc->pd_count);
disable_irqs:
qcom_q6v5_unprepare(>q6v5);
@@ -972,7 +1020,7 @@ static int q6v5_stop(struct rproc
Re: [PATCH v2] remoteproc: q6v5: Add support to vote for rpmh power domains
Hi Ulf,
On 9/11/2018 5:00 PM, Ulf Hansson wrote:
+Viresh
On 4 September 2018 at 09:10, Rajendra Nayak wrote:
With rpmh ARC resources being modelled as power domains with performance
state,
we need to proxy vote on these for SDM845.
Add support to vote on multiple of them, now that genpd supports
associating
mutliple power domains to a device.
thanks for the review, looks like I missed responding to this one somehow :(
I guess it's fair to mention that the votes are, at this point, done
for maximum performance!?
Is that really needed in the long run? I mean, I guess you should walk
through the OPP library to find the needed performance level? No?
well, yes the votes are for max perf, but these are just sort of *proxy*
votes from the remoteproc driver on behalf of the firmware, up until the
time the firmware itself is up and running and can put its own requests.
So this is general practice to just vote for max clocks/regulator/perf states
because we don't really know what meets the firmware requirements.
Signed-off-by: Rajendra Nayak
---
Changes in v2:
* Drop the perf vote along with disabling the powerdomain
* pm_suspend_ignore_children() to not mess with runtime PM of children
* Detach powerdomains as part of .remove and in error path during probe,
issue reported by Brian Norris
* Use dev_pm_domain_attach_by_name() api
drivers/remoteproc/qcom_q6v5_pil.c | 111 -
1 file changed, 109 insertions(+), 2 deletions(-)
diff --git a/drivers/remoteproc/qcom_q6v5_pil.c
b/drivers/remoteproc/qcom_q6v5_pil.c
index d7a4b9eca5d2..f4b3a9b09a5d 100644
--- a/drivers/remoteproc/qcom_q6v5_pil.c
+++ b/drivers/remoteproc/qcom_q6v5_pil.c
@@ -25,6 +25,8 @@
#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -131,6 +133,7 @@ struct rproc_hexagon_res {
char **proxy_clk_names;
char **reset_clk_names;
char **active_clk_names;
+ char **pd_names;
int version;
bool need_mem_protection;
bool has_alt_reset;
@@ -155,9 +158,11 @@ struct q6v5 {
struct clk *active_clks[8];
struct clk *reset_clks[4];
struct clk *proxy_clks[4];
+ struct device *pd_devs[3];
int active_clk_count;
int reset_clk_count;
int proxy_clk_count;
+ int pd_count;
struct reg_info active_regs[1];
struct reg_info proxy_regs[3];
@@ -316,6 +321,40 @@ static void q6v5_clk_disable(struct device *dev,
clk_disable_unprepare(clks[i]);
}
+static int q6v5_powerdomain_enable(struct device *dev, struct device **devs,
+ int count)
Looks like passing the qproc struct, rather than a couple of its
member could simplify the code a bit. No strong opinion though.
sure, I will try to simplify this one.
+{
+ int i;
+
+ if (!count)
+ return 0;
+
+ if (count > 1)
+ for (i = 0; i < count; i++)
+ dev_pm_genpd_set_performance_state(devs[i], INT_MAX);
+ else
+ dev_pm_genpd_set_performance_state(dev, INT_MAX);
+
+ return pm_runtime_get_sync(dev);
+}
+
+static int q6v5_powerdomain_disable(struct device *dev, struct device **devs,
+ int count)
Ditto.
+{
+ int i;
+
+ if (!count)
+ return 0;
+
+ if (count > 1)
+ for (i = 0; i < count; i++)
+ dev_pm_genpd_set_performance_state(devs[i], 0);
+ else
+ dev_pm_genpd_set_performance_state(dev, 0);
+
+ return pm_runtime_put(dev);
+}
+
static int q6v5_xfer_mem_ownership(struct q6v5 *qproc, int *current_perm,
bool remote_owner, phys_addr_t addr,
size_t size)
@@ -792,11 +831,18 @@ static int q6v5_start(struct rproc *rproc)
qcom_q6v5_prepare(>q6v5);
+ ret = q6v5_powerdomain_enable(qproc->dev, qproc->pd_devs,
+ qproc->pd_count);
+ if (ret < 0) {
+ dev_err(qproc->dev, "failed to enable power domains\n");
+ goto disable_irqs;
+ }
+
ret = q6v5_regulator_enable(qproc, qproc->proxy_regs,
qproc->proxy_reg_count);
if (ret) {
dev_err(qproc->dev, "failed to enable proxy supplies\n");
- goto disable_irqs;
+ goto disable_powerdomains;
}
ret = q6v5_clk_enable(qproc->dev, qproc->proxy_clks,
@@ -920,6 +966,8 @@ static int q6v5_start(struct rproc *rproc)
q6v5_regulator_disable(qproc, qproc->proxy_regs,
qproc->proxy_reg_count);
+disable_powerdomains:
+ q6v5_powerdomain_disable(qproc->dev, qproc->pd_devs, qproc->pd_count);
disable_irqs:
qcom_q6v5_unprepare(>q6v5);
@@ -972,7 +1020,7 @@ static int q6v5_stop(struct rproc
Re: [patch v2] mm, thp: always specify ineligible vmas as nh in smaps
On Mon 24-09-18 22:43:49, Vlastimil Babka wrote: > On 9/24/18 10:02 PM, Michal Hocko wrote: > > On Mon 24-09-18 21:56:03, Michal Hocko wrote: [...] > >> That being said, I do not object to the patch, I am just trying to > >> understand what is the intended usage for the flag that does try to say > >> more than the madvise status. > > > > And moreover, how is the PR_SET_THP_DISABLE any different from the > > global THP disabled case. Do we want to set all vmas to nh as well? > > Probably not. It's easy to check the global status, but is it possible > to query for the prctl flags of a process? Dunno but I suspect there is no way to check for this. > We are looking at process or > even vma-specific flags here. If the prctl was historically implemented > via VM_NOHUGEPAGE and thus reported as such in smaps, it makes sense to > do so even with the MMF_ flag IMHO? Yes if this breaks some userspace which relied on the previous behavior. But if nothing really broke then I guess it would be better to have the semantic as clear as possible. Go and check the global status to make the whole picture doesn't look very sound to me. On the other hand this VMA has a madvise flag on it sounds quite clear and you know what to expect at least. Sure the hint might be ignored in the end but well, these are hints they do not guarantee anything after all. -- Michal Hocko SUSE Labs
Re: [patch v2] mm, thp: always specify ineligible vmas as nh in smaps
On Mon 24-09-18 22:43:49, Vlastimil Babka wrote: > On 9/24/18 10:02 PM, Michal Hocko wrote: > > On Mon 24-09-18 21:56:03, Michal Hocko wrote: [...] > >> That being said, I do not object to the patch, I am just trying to > >> understand what is the intended usage for the flag that does try to say > >> more than the madvise status. > > > > And moreover, how is the PR_SET_THP_DISABLE any different from the > > global THP disabled case. Do we want to set all vmas to nh as well? > > Probably not. It's easy to check the global status, but is it possible > to query for the prctl flags of a process? Dunno but I suspect there is no way to check for this. > We are looking at process or > even vma-specific flags here. If the prctl was historically implemented > via VM_NOHUGEPAGE and thus reported as such in smaps, it makes sense to > do so even with the MMF_ flag IMHO? Yes if this breaks some userspace which relied on the previous behavior. But if nothing really broke then I guess it would be better to have the semantic as clear as possible. Go and check the global status to make the whole picture doesn't look very sound to me. On the other hand this VMA has a madvise flag on it sounds quite clear and you know what to expect at least. Sure the hint might be ignored in the end but well, these are hints they do not guarantee anything after all. -- Michal Hocko SUSE Labs
[LKP] [mm, oom] 6209f6fc62: general_protection_fault:#[##]
FYI, we noticed the following commit (built with gcc-7):
commit: 6209f6fc62835d84c2a92d237588a114e39436ce ("mm, oom: rework mmap_exit
vs. oom_reaper synchronization")
https://github.com/0day-ci/linux
UPDATE-20180911-024633/Tetsuo-Handa/mm-oom-Fix-unnecessary-killing-of-additional-processes/20180910-163452
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2
-m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | a49a9dcce8 | 6209f6fc62 |
+--+++
| boot_successes | 4 | 0 |
| boot_failures| 11 | 9 |
| invoked_oom-killer:gfp_mask=0x | 10 | 9 |
| Mem-Info | 11 | 9 |
| Out_of_memory:Kill_process | 11 | 9 |
| general_protection_fault:#[##] | 0 | 7 |
| RIP:__oom_reap_task_mm | 0 | 8 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 8 |
+--+++
[ 75.095365] [431] 0 431 4460 1839696320
-1000 sed
[ 75.116040] [439] 0 439 4469 729737280
-1000 rc.local
[ 75.137487] [440] 0 440 1078 313532480
0 sleep
[ 75.158428] [441] 0 441 4990 178614400
-1000 lkp-setup-rootf
[ 75.181175] [442] 0 442 85 49409600
-1000 run-parts
[ 75.202754] Out of memory: Kill process 397 (rc) score 7 or sacrifice child
[ 75.219642] Killed process 427 (S99rc.local) total-vm:18036kB,
anon-rss:420kB, file-rss:2704kB, shmem-rss:0kB
/etc/init.d/rc: line 149: 427 Killed $debug "$script" $action
[ 75.270407] general protection fault: [#1] DEBUG_PAGEALLOC PTI
[ 75.289553] CPU: 0 PID: 11 Comm: oom_reaper Not tainted
4.19.0-rc2-00206-g6209f6f #1
[ 75.309358] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 75.330813] RIP: 0010:__oom_reap_task_mm+0x40/0x180
[ 75.343290] Code: 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 80 8f b2 04 00 00
40 48 8b 1f 48 85 db 0f 84 0b 01 00 00 49 89 fc c6 85 47 ff ff ff 01 <48> 8b 43
50 a9 00 24 40 00 0f 85 e3 00 00 00 48 83 bb 90 00 00 00
[ 75.386036] RSP: 0018:88001d087db8 EFLAGS: 00010202
[ 75.399221] RAX: 6b6b6b6b6b6b6b6b RBX: 6b6b6b6b6b05036b RCX: 01ab
[ 75.416364] RDX: 88001d0828e0 RSI: a0ac31fe RDI: 88000d103a80
[ 75.433182] RBP: 88001d087e78 R08: 4ab0396a R09: a0ac31fe
[ 75.449774] R10: 88000d103b78 R11: 88001d0822c0 R12: 88000d103a80
[ 75.466591] R13: 88000d103a80 R14: 88000d103b28 R15: 840b6574
[ 75.483286] FS: () GS:8308c000()
knlGS:
[ 75.503824] CS: 0010 DS: ES: CR0: 80050033
[ 75.518117] CR2: 7f7171c3b1f4 CR3: 03062003 CR4: 000206b0
[ 75.533929] Call Trace:
[ 75.541424] ? oom_reaper+0x1aa/0x4c0
[ 75.550332] oom_reaper+0x36b/0x4c0
[ 75.559503] ? __wake_up_common_lock+0xc0/0xc0
[ 75.569710] kthread+0x151/0x160
[ 75.578584] ? __oom_reap_task_mm+0x180/0x180
[ 75.589480] ? __kthread_create_on_node+0x1e0/0x1e0
[ 75.601818] ret_from_fork+0x24/0x30
[ 75.637304] ---[ end trace 084a6c5aff200732 ]---
[ 75.661129] RIP: 0010:__oom_reap_task_mm+0x40/0x180
[ 75.672375] Code: 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 80 8f b2 04 00 00
40 48 8b 1f 48 85 db 0f 84 0b 01 00 00 49 89 fc c6 85 47 ff ff ff 01 <48> 8b 43
50 a9 00 24 40 00 0f 85 e3 00 00 00 48 83 bb 90 00 00 00
[ 75.717670] RSP: 0018:88001d087db8 EFLAGS: 00010202
[ 75.733410] RAX: 6b6b6b6b6b6b6b6b RBX: 6b6b6b6b6b05036b RCX: 01ab
[ 75.751142] RDX: 88001d0828e0 RSI: a0ac31fe RDI: 88000d103a80
[ 75.769090] RBP: 88001d087e78 R08: 4ab0396a R09: a0ac31fe
[ 75.786955] R10: 88000d103b78 R11: 88001d0822c0 R12: 88000d103a80
[ 75.805100] R13: 88000d103a80 R14: 88000d103b28 R15: 840b6574
[ 75.823112] FS: () GS:8308c000()
knlGS:
[ 75.845084] CS: 0010 DS: ES: CR0: 80050033
[ 75.860290] CR2: 7f7171c3b1f4 CR3: 03062003 CR4: 000206b0
[ 75.878136] Kernel panic - not syncing: Fatal exception
[ 75.891719] Kernel Offset: disabled
Elapsed
[LKP] [mm, oom] 6209f6fc62: general_protection_fault:#[##]
FYI, we noticed the following commit (built with gcc-7):
commit: 6209f6fc62835d84c2a92d237588a114e39436ce ("mm, oom: rework mmap_exit
vs. oom_reaper synchronization")
https://github.com/0day-ci/linux
UPDATE-20180911-024633/Tetsuo-Handa/mm-oom-Fix-unnecessary-killing-of-additional-processes/20180910-163452
in testcase: trinity
with following parameters:
runtime: 300s
test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/
on test machine: qemu-system-x86_64 -enable-kvm -cpu Haswell,+smep,+smap -smp 2
-m 512M
caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):
+--+++
| | a49a9dcce8 | 6209f6fc62 |
+--+++
| boot_successes | 4 | 0 |
| boot_failures| 11 | 9 |
| invoked_oom-killer:gfp_mask=0x | 10 | 9 |
| Mem-Info | 11 | 9 |
| Out_of_memory:Kill_process | 11 | 9 |
| general_protection_fault:#[##] | 0 | 7 |
| RIP:__oom_reap_task_mm | 0 | 8 |
| Kernel_panic-not_syncing:Fatal_exception | 0 | 8 |
+--+++
[ 75.095365] [431] 0 431 4460 1839696320
-1000 sed
[ 75.116040] [439] 0 439 4469 729737280
-1000 rc.local
[ 75.137487] [440] 0 440 1078 313532480
0 sleep
[ 75.158428] [441] 0 441 4990 178614400
-1000 lkp-setup-rootf
[ 75.181175] [442] 0 442 85 49409600
-1000 run-parts
[ 75.202754] Out of memory: Kill process 397 (rc) score 7 or sacrifice child
[ 75.219642] Killed process 427 (S99rc.local) total-vm:18036kB,
anon-rss:420kB, file-rss:2704kB, shmem-rss:0kB
/etc/init.d/rc: line 149: 427 Killed $debug "$script" $action
[ 75.270407] general protection fault: [#1] DEBUG_PAGEALLOC PTI
[ 75.289553] CPU: 0 PID: 11 Comm: oom_reaper Not tainted
4.19.0-rc2-00206-g6209f6f #1
[ 75.309358] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.10.2-1 04/01/2014
[ 75.330813] RIP: 0010:__oom_reap_task_mm+0x40/0x180
[ 75.343290] Code: 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 80 8f b2 04 00 00
40 48 8b 1f 48 85 db 0f 84 0b 01 00 00 49 89 fc c6 85 47 ff ff ff 01 <48> 8b 43
50 a9 00 24 40 00 0f 85 e3 00 00 00 48 83 bb 90 00 00 00
[ 75.386036] RSP: 0018:88001d087db8 EFLAGS: 00010202
[ 75.399221] RAX: 6b6b6b6b6b6b6b6b RBX: 6b6b6b6b6b05036b RCX: 01ab
[ 75.416364] RDX: 88001d0828e0 RSI: a0ac31fe RDI: 88000d103a80
[ 75.433182] RBP: 88001d087e78 R08: 4ab0396a R09: a0ac31fe
[ 75.449774] R10: 88000d103b78 R11: 88001d0822c0 R12: 88000d103a80
[ 75.466591] R13: 88000d103a80 R14: 88000d103b28 R15: 840b6574
[ 75.483286] FS: () GS:8308c000()
knlGS:
[ 75.503824] CS: 0010 DS: ES: CR0: 80050033
[ 75.518117] CR2: 7f7171c3b1f4 CR3: 03062003 CR4: 000206b0
[ 75.533929] Call Trace:
[ 75.541424] ? oom_reaper+0x1aa/0x4c0
[ 75.550332] oom_reaper+0x36b/0x4c0
[ 75.559503] ? __wake_up_common_lock+0xc0/0xc0
[ 75.569710] kthread+0x151/0x160
[ 75.578584] ? __oom_reap_task_mm+0x180/0x180
[ 75.589480] ? __kthread_create_on_node+0x1e0/0x1e0
[ 75.601818] ret_from_fork+0x24/0x30
[ 75.637304] ---[ end trace 084a6c5aff200732 ]---
[ 75.661129] RIP: 0010:__oom_reap_task_mm+0x40/0x180
[ 75.672375] Code: 8b 04 25 28 00 00 00 48 89 45 d0 31 c0 80 8f b2 04 00 00
40 48 8b 1f 48 85 db 0f 84 0b 01 00 00 49 89 fc c6 85 47 ff ff ff 01 <48> 8b 43
50 a9 00 24 40 00 0f 85 e3 00 00 00 48 83 bb 90 00 00 00
[ 75.717670] RSP: 0018:88001d087db8 EFLAGS: 00010202
[ 75.733410] RAX: 6b6b6b6b6b6b6b6b RBX: 6b6b6b6b6b05036b RCX: 01ab
[ 75.751142] RDX: 88001d0828e0 RSI: a0ac31fe RDI: 88000d103a80
[ 75.769090] RBP: 88001d087e78 R08: 4ab0396a R09: a0ac31fe
[ 75.786955] R10: 88000d103b78 R11: 88001d0822c0 R12: 88000d103a80
[ 75.805100] R13: 88000d103a80 R14: 88000d103b28 R15: 840b6574
[ 75.823112] FS: () GS:8308c000()
knlGS:
[ 75.845084] CS: 0010 DS: ES: CR0: 80050033
[ 75.860290] CR2: 7f7171c3b1f4 CR3: 03062003 CR4: 000206b0
[ 75.878136] Kernel panic - not syncing: Fatal exception
[ 75.891719] Kernel Offset: disabled
Elapsed
Re: [PATCH 3.18 104/105] IB/nes: Fix a compiler warning
On Mon, 2018-09-24 at 22:39 +, Sasha Levin wrote: > The reasoning behind it was similar to the "no warnings" reasoning of > upstream: there might be real issues hiding in the sea of "harmless" > warnings, so we want to get rid of all of them to catch real issues. I believe this to be a poor idea for -stable acceptance. It's impossible to know when gcc or any other compiler would decide to add any new warning.
Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling
Quoting Paul Moore (2018-09-24 20:46:57) > On Fri, Sep 21, 2018 at 10:39 AM Stephen Smalley wrote: > > On 09/20/2018 06:59 PM, Taras Kondratiuk wrote: > > > Quoting Stephen Smalley (2018-09-20 07:49:12) > > >> On 09/19/2018 10:41 PM, Taras Kondratiuk wrote: > > >>> Quoting Stephen Smalley (2018-09-19 12:00:33) > > On 09/19/2018 12:52 PM, Taras Kondratiuk wrote: > > ... > > > > IMO it would be more consistent if defcontext cover all "unlabeled" > > > groups. It seems unlikely to me that somebody who currently uses > > > defcontext can somehow rely on mapping invalid labels to unlabeled > > > instead of default context. > > > > Yes, and that seems more consistent with the current documentation in > > the mount man page for defcontext=. > > > > I'd be inclined to change selinux_inode_notifysecctx() to call > > security_context_to_sid_default() directly instead of using > > selinux_inode_setsecurity() and change security_context_to_sid_core() > > and sidtab_search_core() as suggested above to save and use the def_sid > > instead of SECINITSID_UNLABELED always (initializing the context def_sid > > to SECINITSID_UNLABELED as the default). selinux_inode_setsecurity() we > > should leave unchanged, or if we change it at all, it should be more > > like the handling in selinux_inode_setxattr(). The notifysecctx hook is > > invoked by the filesystem to notify the security module of the file's > > existing security context, so in that case we always want the _default > > behavior, whereas the setsecurity hook is invoked by the vfs or the > > filesystem to set the security context of a file to a new value, so in > > that case we would only use the _force interface if the caller had > > CAP_MAC_ADMIN. > > > > Paul, what say you? NB This would be a user-visible behavior change for > > mounts specifying defcontext= on xattr filesystems; files with invalid > > contexts will then show up with the defcontext value instead of the > > unlabeled context. If that's too risky, then we'd need a flag or > > something to security_context_to_sid_default() to distinguish the > > behaviors and only set it when called from selinux_inode_notifysecctx(). > > Visible changes like this are always worrisome, even though I think it > is safe to assume that the defcontext option is not widely used. I'd > feel much better if this change was opt-in. > > Which brings about it's own problems. We have the policy capability > functionality, but that is likely a poor fit for this as the policy > capabilities are usually controlled by the Linux distribution while > the mount options are set by the system's administrator when the > filesystem is mounted. We could add a toggle somewhere in selinuxfs, > but I really dislike that idea, and would prefer to find a different > solution if possible. I'm not sure how much flak we would get for > introducing a new mount option, but perhaps that is the best way to > handle this: defcontext would continue to behave as it does now, but > new option X would behave as mentioned in this thread. > > Thoughts? The new option X will also mean "default context", so it will be pretty hard to come up with a different but a sensible name. I'm afraid that having two options with hardly distinguishable semantics will be very confusing. What about a kernel config option that modifies the behavior of defcontext?
Re: [PATCH 3.18 104/105] IB/nes: Fix a compiler warning
On Mon, 2018-09-24 at 22:39 +, Sasha Levin wrote: > The reasoning behind it was similar to the "no warnings" reasoning of > upstream: there might be real issues hiding in the sea of "harmless" > warnings, so we want to get rid of all of them to catch real issues. I believe this to be a poor idea for -stable acceptance. It's impossible to know when gcc or any other compiler would decide to add any new warning.
Re: [RFC PATCH] selinux: add a fallback to defcontext for native labeling
Quoting Paul Moore (2018-09-24 20:46:57) > On Fri, Sep 21, 2018 at 10:39 AM Stephen Smalley wrote: > > On 09/20/2018 06:59 PM, Taras Kondratiuk wrote: > > > Quoting Stephen Smalley (2018-09-20 07:49:12) > > >> On 09/19/2018 10:41 PM, Taras Kondratiuk wrote: > > >>> Quoting Stephen Smalley (2018-09-19 12:00:33) > > On 09/19/2018 12:52 PM, Taras Kondratiuk wrote: > > ... > > > > IMO it would be more consistent if defcontext cover all "unlabeled" > > > groups. It seems unlikely to me that somebody who currently uses > > > defcontext can somehow rely on mapping invalid labels to unlabeled > > > instead of default context. > > > > Yes, and that seems more consistent with the current documentation in > > the mount man page for defcontext=. > > > > I'd be inclined to change selinux_inode_notifysecctx() to call > > security_context_to_sid_default() directly instead of using > > selinux_inode_setsecurity() and change security_context_to_sid_core() > > and sidtab_search_core() as suggested above to save and use the def_sid > > instead of SECINITSID_UNLABELED always (initializing the context def_sid > > to SECINITSID_UNLABELED as the default). selinux_inode_setsecurity() we > > should leave unchanged, or if we change it at all, it should be more > > like the handling in selinux_inode_setxattr(). The notifysecctx hook is > > invoked by the filesystem to notify the security module of the file's > > existing security context, so in that case we always want the _default > > behavior, whereas the setsecurity hook is invoked by the vfs or the > > filesystem to set the security context of a file to a new value, so in > > that case we would only use the _force interface if the caller had > > CAP_MAC_ADMIN. > > > > Paul, what say you? NB This would be a user-visible behavior change for > > mounts specifying defcontext= on xattr filesystems; files with invalid > > contexts will then show up with the defcontext value instead of the > > unlabeled context. If that's too risky, then we'd need a flag or > > something to security_context_to_sid_default() to distinguish the > > behaviors and only set it when called from selinux_inode_notifysecctx(). > > Visible changes like this are always worrisome, even though I think it > is safe to assume that the defcontext option is not widely used. I'd > feel much better if this change was opt-in. > > Which brings about it's own problems. We have the policy capability > functionality, but that is likely a poor fit for this as the policy > capabilities are usually controlled by the Linux distribution while > the mount options are set by the system's administrator when the > filesystem is mounted. We could add a toggle somewhere in selinuxfs, > but I really dislike that idea, and would prefer to find a different > solution if possible. I'm not sure how much flak we would get for > introducing a new mount option, but perhaps that is the best way to > handle this: defcontext would continue to behave as it does now, but > new option X would behave as mentioned in this thread. > > Thoughts? The new option X will also mean "default context", so it will be pretty hard to come up with a different but a sensible name. I'm afraid that having two options with hardly distinguishable semantics will be very confusing. What about a kernel config option that modifies the behavior of defcontext?
linux-next: Tree for Sep 25
Hi all, Changes since 20180924: Dropped trees: xarray, ida (temporarily) Non-merge commits (relative to Linus' tree): 5626 6053 files changed, 275592 insertions(+), 120719 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 288 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (02214bfc89c7 Merge tag 'media/v4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of Linus' tree) Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain not in Clang search path) Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE in arch's Makefile) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (031e6e6b4e12 arm64: hugetlb: Avoid unnecessary clearing in huge_ptep_set_access_flags) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (c716a25b9b70 powerpc/pkeys: Fix reading of ibm, processor-storage-keys property) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (f4a518797b40 net: mvneta: fix the remaining Rx descriptor unmapping issues) Merging bpf/master (fad0c40fab14 Merge branch 'bpf-sockmap-estab-fixes') Merging ipsec/master (32bf94fb5c2e xfrm: validate template mode) Merging netfilter/master (346fa83d1093 netfilter: conntrack: get rid of double sizeof) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2823c8716c68 b43: fix DMA error related regression with proprietary firmware) Merging mac80211/master (c42055105785 mac80211: fix TX status reporting for ieee80211s) Merging rdma-fixes/for-rc (b4a4957d3d1c IB/hfi1: Fix destroy_qp hang after a link down) Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the audio-component completion timeout) Merging sound-asoc-fixes/for-linus (85adbf9815ab Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4) Merging regulator-fixes/for-linus (69a3f680261f Merge branch 'regulator-4.19' into regulator-linus) Merging spi-fixes/for-linus (1f6b3b2c1ff4 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (9024143e700f PCI: dwc: Fix scheduling while atomic issues) Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4) Merging tty.current/tty-linus (7e620984b625 serial: imx: restore handshaking irq for imx1) Merging usb.current/usb-linus (3e3b81965cbf usb: typec: mux: Take care of driver module reference counting) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (f5fad711c06e USB: serial: simple: add Motorola Tetra MTP6550 id) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging staging.current/staging
linux-next: Tree for Sep 25
Hi all, Changes since 20180924: Dropped trees: xarray, ida (temporarily) Non-merge commits (relative to Linus' tree): 5626 6053 files changed, 275592 insertions(+), 120719 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 288 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (02214bfc89c7 Merge tag 'media/v4.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media) Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of Linus' tree) Merging kbuild-current/fixes (ef8c4ed9db80 kbuild: allow to use GCC toolchain not in Clang search path) Merging arc-current/for-curr (40660f1fcee8 ARC: build: Don't set CROSS_COMPILE in arch's Makefile) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (031e6e6b4e12 arm64: hugetlb: Avoid unnecessary clearing in huge_ptep_set_access_flags) Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response format) Merging powerpc-fixes/fixes (c716a25b9b70 powerpc/pkeys: Fix reading of ibm, processor-storage-keys property) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (f4a518797b40 net: mvneta: fix the remaining Rx descriptor unmapping issues) Merging bpf/master (fad0c40fab14 Merge branch 'bpf-sockmap-estab-fixes') Merging ipsec/master (32bf94fb5c2e xfrm: validate template mode) Merging netfilter/master (346fa83d1093 netfilter: conntrack: get rid of double sizeof) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (2823c8716c68 b43: fix DMA error related regression with proprietary firmware) Merging mac80211/master (c42055105785 mac80211: fix TX status reporting for ieee80211s) Merging rdma-fixes/for-rc (b4a4957d3d1c IB/hfi1: Fix destroy_qp hang after a link down) Merging sound-current/for-linus (b3a5402cbceb ALSA: hda: Fix the audio-component completion timeout) Merging sound-asoc-fixes/for-linus (85adbf9815ab Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4) Merging regulator-fixes/for-linus (69a3f680261f Merge branch 'regulator-4.19' into regulator-linus) Merging spi-fixes/for-linus (1f6b3b2c1ff4 Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (9024143e700f PCI: dwc: Fix scheduling while atomic issues) Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4) Merging tty.current/tty-linus (7e620984b625 serial: imx: restore handshaking irq for imx1) Merging usb.current/usb-linus (3e3b81965cbf usb: typec: mux: Take care of driver module reference counting) Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of dwc2_check_core_endianness) Merging usb-serial-fixes/usb-linus (f5fad711c06e USB: serial: simple: add Motorola Tetra MTP6550 id) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging staging.current/staging
Re: [PATCH 1/2] phy: zynqmp: Add phy driver for xilinx zynqmp phy core
Hi, On Wednesday 29 August 2018 07:37 PM, Anurag Kumar Vulisha wrote: > ZynqMP SoC has a Gigabit Transceiver with four lanes. All the high speed > peripherals such as USB, SATA, PCIE, Display Port and Ethernet SGMII can > rely on any of the four GT lanes for PHY layer. This patch adds driver > for that ZynqMP GT core. > > Signed-off-by: Anurag Kumar Vulisha > --- > drivers/phy/Kconfig|8 + > drivers/phy/Makefile |1 + > drivers/phy/phy-zynqmp.c | 1579 > > include/dt-bindings/phy/phy.h |2 + > include/linux/phy/phy-zynqmp.h | 52 ++ > 5 files changed, 1642 insertions(+) > create mode 100644 drivers/phy/phy-zynqmp.c > create mode 100644 include/linux/phy/phy-zynqmp.h > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 5c8d452..14cf3330 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -40,6 +40,14 @@ config PHY_XGENE > help > This option enables support for APM X-Gene SoC multi-purpose PHY. > > +config PHY_XILINX_ZYNQMP > + tristate "Xilinx ZynqMP PHY driver" > + depends on ARCH_ZYNQMP > + select GENERIC_PHY > + help > + Enable this to support ZynqMP High Speed Gigabit Transceiver > + that is part of ZynqMP SoC. > + > source "drivers/phy/allwinner/Kconfig" > source "drivers/phy/amlogic/Kconfig" > source "drivers/phy/broadcom/Kconfig" > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > index 84e3bd9..f2a8d27 100644 > --- a/drivers/phy/Makefile > +++ b/drivers/phy/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o > obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= phy-lpc18xx-usb-otg.o > obj-$(CONFIG_PHY_XGENE) += phy-xgene.o > obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o > +obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o > obj-$(CONFIG_ARCH_SUNXI) += allwinner/ > obj-$(CONFIG_ARCH_MESON) += amlogic/ > obj-$(CONFIG_LANTIQ) += lantiq/ > diff --git a/drivers/phy/phy-zynqmp.c b/drivers/phy/phy-zynqmp.c > new file mode 100644 > index 000..306cedd > --- /dev/null > +++ b/drivers/phy/phy-zynqmp.c > @@ -0,0 +1,1579 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * phy-zynqmp.c - PHY driver for Xilinx ZynqMP GT. > + * > + * Copyright (C) 2018 Xilinx Inc. > + * > + * Author: Anurag Kumar Vulisha > + * > + * This driver is tested for USB, SATA and Display Port currently. > + * Other controllers PCIe and SGMII should also work but that is > + * experimental as of now. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Inter Connect Matrix parameters */ > +#define ICM_CFG0 0x10010 > +#define ICM_CFG1 0x10014 > +#define ICM_CFG0_L0_MASK 0x07 > +#define ICM_CFG0_L1_MASK 0x70 > +#define ICM_CFG1_L2_MASK 0x07 > +#define ICM_CFG2_L3_MASK 0x70 > +#define ICM_CFG_SHIFT4 > + > +/* Inter Connect Matrix allowed protocols */ > +#define ICM_PROTOCOL_PD 0x0 > +#define ICM_PROTOCOL_PCIE0x1 > +#define ICM_PROTOCOL_SATA0x2 > +#define ICM_PROTOCOL_USB 0x3 > +#define ICM_PROTOCOL_DP 0x4 > +#define ICM_PROTOCOL_SGMII 0x5 > + > +/* Test Mode common reset control parameters */ > +#define TM_CMN_RST 0x10018 > +#define TM_CMN_RST_EN0x1 > +#define TM_CMN_RST_SET 0x2 > +#define TM_CMN_RST_MASK 0x3 > + > +/* Refclk selection parameters */ > +#define PLL_REF_SEL0 0x1 > +#define PLL_REF_OFFSET 0x4 > +#define PLL_FREQ_MASK0x1F > +#define PLL_STATUS_READ_OFFSET 0x4000 > +#define PLL_STATUS_LOCKED0x10 > + > +/* PLL SSC step size offsets */ > +#define L0_L0_REF_CLK_SEL0x2860 > +#define L0_PLL_SS_STEPS_0_LSB0x2368 > +#define L0_PLL_SS_STEPS_1_MSB0x236C > +#define L0_PLL_SS_STEP_SIZE_0_LSB0x2370 > +#define L0_PLL_SS_STEP_SIZE_10x2374 > +#define L0_PLL_SS_STEP_SIZE_20x2378 > +#define L0_PLL_SS_STEP_SIZE_3_MSB0x237C > +#define L0_PLL_STATUS_READ_1 0x23E4 > + > +/* SSC step size parameters */ > +#define STEP_SIZE_OFFSET 0x4000 > +#define STEP_SIZE_0_MASK 0xFF > +#define STEP_SIZE_1_MASK 0xFF > +#define STEP_SIZE_2_MASK 0xFF > +#define STEP_SIZE_3_MASK 0x3 > +#define STEP_SIZE_SHIFT 8 > +#define FORCE_STEP_SIZE 0x10 > +#define FORCE_STEPS 0x20 > +#define STEPS_OFFSET 0x4000 >
Re: [PATCH 1/2] phy: zynqmp: Add phy driver for xilinx zynqmp phy core
Hi, On Wednesday 29 August 2018 07:37 PM, Anurag Kumar Vulisha wrote: > ZynqMP SoC has a Gigabit Transceiver with four lanes. All the high speed > peripherals such as USB, SATA, PCIE, Display Port and Ethernet SGMII can > rely on any of the four GT lanes for PHY layer. This patch adds driver > for that ZynqMP GT core. > > Signed-off-by: Anurag Kumar Vulisha > --- > drivers/phy/Kconfig|8 + > drivers/phy/Makefile |1 + > drivers/phy/phy-zynqmp.c | 1579 > > include/dt-bindings/phy/phy.h |2 + > include/linux/phy/phy-zynqmp.h | 52 ++ > 5 files changed, 1642 insertions(+) > create mode 100644 drivers/phy/phy-zynqmp.c > create mode 100644 include/linux/phy/phy-zynqmp.h > > diff --git a/drivers/phy/Kconfig b/drivers/phy/Kconfig > index 5c8d452..14cf3330 100644 > --- a/drivers/phy/Kconfig > +++ b/drivers/phy/Kconfig > @@ -40,6 +40,14 @@ config PHY_XGENE > help > This option enables support for APM X-Gene SoC multi-purpose PHY. > > +config PHY_XILINX_ZYNQMP > + tristate "Xilinx ZynqMP PHY driver" > + depends on ARCH_ZYNQMP > + select GENERIC_PHY > + help > + Enable this to support ZynqMP High Speed Gigabit Transceiver > + that is part of ZynqMP SoC. > + > source "drivers/phy/allwinner/Kconfig" > source "drivers/phy/amlogic/Kconfig" > source "drivers/phy/broadcom/Kconfig" > diff --git a/drivers/phy/Makefile b/drivers/phy/Makefile > index 84e3bd9..f2a8d27 100644 > --- a/drivers/phy/Makefile > +++ b/drivers/phy/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_GENERIC_PHY) += phy-core.o > obj-$(CONFIG_PHY_LPC18XX_USB_OTG)+= phy-lpc18xx-usb-otg.o > obj-$(CONFIG_PHY_XGENE) += phy-xgene.o > obj-$(CONFIG_PHY_PISTACHIO_USB) += phy-pistachio-usb.o > +obj-$(CONFIG_PHY_XILINX_ZYNQMP) += phy-zynqmp.o > obj-$(CONFIG_ARCH_SUNXI) += allwinner/ > obj-$(CONFIG_ARCH_MESON) += amlogic/ > obj-$(CONFIG_LANTIQ) += lantiq/ > diff --git a/drivers/phy/phy-zynqmp.c b/drivers/phy/phy-zynqmp.c > new file mode 100644 > index 000..306cedd > --- /dev/null > +++ b/drivers/phy/phy-zynqmp.c > @@ -0,0 +1,1579 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * phy-zynqmp.c - PHY driver for Xilinx ZynqMP GT. > + * > + * Copyright (C) 2018 Xilinx Inc. > + * > + * Author: Anurag Kumar Vulisha > + * > + * This driver is tested for USB, SATA and Display Port currently. > + * Other controllers PCIe and SGMII should also work but that is > + * experimental as of now. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Inter Connect Matrix parameters */ > +#define ICM_CFG0 0x10010 > +#define ICM_CFG1 0x10014 > +#define ICM_CFG0_L0_MASK 0x07 > +#define ICM_CFG0_L1_MASK 0x70 > +#define ICM_CFG1_L2_MASK 0x07 > +#define ICM_CFG2_L3_MASK 0x70 > +#define ICM_CFG_SHIFT4 > + > +/* Inter Connect Matrix allowed protocols */ > +#define ICM_PROTOCOL_PD 0x0 > +#define ICM_PROTOCOL_PCIE0x1 > +#define ICM_PROTOCOL_SATA0x2 > +#define ICM_PROTOCOL_USB 0x3 > +#define ICM_PROTOCOL_DP 0x4 > +#define ICM_PROTOCOL_SGMII 0x5 > + > +/* Test Mode common reset control parameters */ > +#define TM_CMN_RST 0x10018 > +#define TM_CMN_RST_EN0x1 > +#define TM_CMN_RST_SET 0x2 > +#define TM_CMN_RST_MASK 0x3 > + > +/* Refclk selection parameters */ > +#define PLL_REF_SEL0 0x1 > +#define PLL_REF_OFFSET 0x4 > +#define PLL_FREQ_MASK0x1F > +#define PLL_STATUS_READ_OFFSET 0x4000 > +#define PLL_STATUS_LOCKED0x10 > + > +/* PLL SSC step size offsets */ > +#define L0_L0_REF_CLK_SEL0x2860 > +#define L0_PLL_SS_STEPS_0_LSB0x2368 > +#define L0_PLL_SS_STEPS_1_MSB0x236C > +#define L0_PLL_SS_STEP_SIZE_0_LSB0x2370 > +#define L0_PLL_SS_STEP_SIZE_10x2374 > +#define L0_PLL_SS_STEP_SIZE_20x2378 > +#define L0_PLL_SS_STEP_SIZE_3_MSB0x237C > +#define L0_PLL_STATUS_READ_1 0x23E4 > + > +/* SSC step size parameters */ > +#define STEP_SIZE_OFFSET 0x4000 > +#define STEP_SIZE_0_MASK 0xFF > +#define STEP_SIZE_1_MASK 0xFF > +#define STEP_SIZE_2_MASK 0xFF > +#define STEP_SIZE_3_MASK 0x3 > +#define STEP_SIZE_SHIFT 8 > +#define FORCE_STEP_SIZE 0x10 > +#define FORCE_STEPS 0x20 > +#define STEPS_OFFSET 0x4000 >
[PATCH v2 2/2] treewide: use bus_find_device_by_fwnode
Use bus_find_device_by_fwnode helper to find the device having a
specific firmware node on a bus.
---
drivers/hwtracing/coresight/of_coresight.c | 14 --
drivers/i2c/i2c-core-of.c | 9 ++---
drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 8 +---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 8 +---
drivers/nvmem/core.c | 7 +--
drivers/of/of_mdio.c | 8 +---
drivers/of/platform.c | 7 +--
drivers/spi/spi.c | 10 +++---
8 files changed, 14 insertions(+), 57 deletions(-)
diff --git a/drivers/hwtracing/coresight/of_coresight.c
b/drivers/hwtracing/coresight/of_coresight.c
index 6880bee..8193b50 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -17,12 +17,6 @@
#include
#include
-
-static int of_dev_node_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
static struct device *
of_coresight_get_endpoint_device(struct device_node *endpoint)
{
@@ -32,8 +26,8 @@ static int of_dev_node_match(struct device *dev, void *data)
* If we have a non-configurable replicator, it will be found on the
* platform bus.
*/
- dev = bus_find_device(_bus_type, NULL,
- endpoint, of_dev_node_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL,
+ >fwnode);
if (dev)
return dev;
@@ -41,8 +35,8 @@ static int of_dev_node_match(struct device *dev, void *data)
* We have a configurable component - circle through the AMBA bus
* looking for the device that matches the endpoint node.
*/
- return bus_find_device(_bustype, NULL,
- endpoint, of_dev_node_match);
+ return bus_find_device_by_fwnode(_bustype, NULL,
+ >fwnode);
}
static void of_coresight_get_ports(const struct device_node *node,
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 6cb7ad6..2b8ef8d 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -116,18 +116,13 @@ void of_i2c_register_devices(struct i2c_adapter *adap)
of_node_put(bus);
}
-static int of_dev_node_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
/* must call put_device() when done with returned i2c_client device */
struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
{
struct device *dev;
struct i2c_client *client;
- dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL, >fwnode);
if (!dev)
return NULL;
@@ -145,7 +140,7 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct
device_node *node)
struct device *dev;
struct i2c_adapter *adapter;
- dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL, >fwnode);
if (!dev)
return NULL;
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index 081aa91..b0d418e 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -4832,19 +4832,13 @@ static void hns_roce_v1_cleanup_eq_table(struct
hns_roce_dev *hr_dev)
};
MODULE_DEVICE_TABLE(acpi, hns_roce_acpi_match);
-static int hns_roce_node_match(struct device *dev, void *fwnode)
-{
- return dev->fwnode == fwnode;
-}
-
static struct
platform_device *hns_roce_find_pdev(struct fwnode_handle *fwnode)
{
struct device *dev;
/* get the 'device' corresponding to the matching 'fwnode' */
- dev = bus_find_device(_bus_type, NULL,
- fwnode, hns_roce_node_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL, fwnode);
/* get the platform device */
return dev ? to_platform_device(dev) : NULL;
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index 16294cd..d5d7c88 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -758,17 +758,11 @@ struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device
*dsaf_dev)
return (void *)misc_op;
}
-static int hns_dsaf_dev_match(struct device *dev, void *fwnode)
-{
- return dev->fwnode == fwnode;
-}
-
struct
platform_device *hns_dsaf_find_platform_device(struct fwnode_handle *fwnode)
{
struct device *dev;
- dev = bus_find_device(_bus_type, NULL,
- fwnode, hns_dsaf_dev_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL,
[PATCH v2 2/2] treewide: use bus_find_device_by_fwnode
Use bus_find_device_by_fwnode helper to find the device having a
specific firmware node on a bus.
---
drivers/hwtracing/coresight/of_coresight.c | 14 --
drivers/i2c/i2c-core-of.c | 9 ++---
drivers/infiniband/hw/hns/hns_roce_hw_v1.c | 8 +---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c | 8 +---
drivers/nvmem/core.c | 7 +--
drivers/of/of_mdio.c | 8 +---
drivers/of/platform.c | 7 +--
drivers/spi/spi.c | 10 +++---
8 files changed, 14 insertions(+), 57 deletions(-)
diff --git a/drivers/hwtracing/coresight/of_coresight.c
b/drivers/hwtracing/coresight/of_coresight.c
index 6880bee..8193b50 100644
--- a/drivers/hwtracing/coresight/of_coresight.c
+++ b/drivers/hwtracing/coresight/of_coresight.c
@@ -17,12 +17,6 @@
#include
#include
-
-static int of_dev_node_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
static struct device *
of_coresight_get_endpoint_device(struct device_node *endpoint)
{
@@ -32,8 +26,8 @@ static int of_dev_node_match(struct device *dev, void *data)
* If we have a non-configurable replicator, it will be found on the
* platform bus.
*/
- dev = bus_find_device(_bus_type, NULL,
- endpoint, of_dev_node_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL,
+ >fwnode);
if (dev)
return dev;
@@ -41,8 +35,8 @@ static int of_dev_node_match(struct device *dev, void *data)
* We have a configurable component - circle through the AMBA bus
* looking for the device that matches the endpoint node.
*/
- return bus_find_device(_bustype, NULL,
- endpoint, of_dev_node_match);
+ return bus_find_device_by_fwnode(_bustype, NULL,
+ >fwnode);
}
static void of_coresight_get_ports(const struct device_node *node,
diff --git a/drivers/i2c/i2c-core-of.c b/drivers/i2c/i2c-core-of.c
index 6cb7ad6..2b8ef8d 100644
--- a/drivers/i2c/i2c-core-of.c
+++ b/drivers/i2c/i2c-core-of.c
@@ -116,18 +116,13 @@ void of_i2c_register_devices(struct i2c_adapter *adap)
of_node_put(bus);
}
-static int of_dev_node_match(struct device *dev, void *data)
-{
- return dev->of_node == data;
-}
-
/* must call put_device() when done with returned i2c_client device */
struct i2c_client *of_find_i2c_device_by_node(struct device_node *node)
{
struct device *dev;
struct i2c_client *client;
- dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL, >fwnode);
if (!dev)
return NULL;
@@ -145,7 +140,7 @@ struct i2c_adapter *of_find_i2c_adapter_by_node(struct
device_node *node)
struct device *dev;
struct i2c_adapter *adapter;
- dev = bus_find_device(_bus_type, NULL, node, of_dev_node_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL, >fwnode);
if (!dev)
return NULL;
diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
index 081aa91..b0d418e 100644
--- a/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
+++ b/drivers/infiniband/hw/hns/hns_roce_hw_v1.c
@@ -4832,19 +4832,13 @@ static void hns_roce_v1_cleanup_eq_table(struct
hns_roce_dev *hr_dev)
};
MODULE_DEVICE_TABLE(acpi, hns_roce_acpi_match);
-static int hns_roce_node_match(struct device *dev, void *fwnode)
-{
- return dev->fwnode == fwnode;
-}
-
static struct
platform_device *hns_roce_find_pdev(struct fwnode_handle *fwnode)
{
struct device *dev;
/* get the 'device' corresponding to the matching 'fwnode' */
- dev = bus_find_device(_bus_type, NULL,
- fwnode, hns_roce_node_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL, fwnode);
/* get the platform device */
return dev ? to_platform_device(dev) : NULL;
}
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
index 16294cd..d5d7c88 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_misc.c
@@ -758,17 +758,11 @@ struct dsaf_misc_op *hns_misc_op_get(struct dsaf_device
*dsaf_dev)
return (void *)misc_op;
}
-static int hns_dsaf_dev_match(struct device *dev, void *fwnode)
-{
- return dev->fwnode == fwnode;
-}
-
struct
platform_device *hns_dsaf_find_platform_device(struct fwnode_handle *fwnode)
{
struct device *dev;
- dev = bus_find_device(_bus_type, NULL,
- fwnode, hns_dsaf_dev_match);
+ dev = bus_find_device_by_fwnode(_bus_type, NULL,
[PATCH v2 1/2] Driver core: add bus_find_device_by_fwnode
Some drivers need to find the device on a bus having a specific firmware
node. Currently, such drivers have their own implementations to do this.
Provide a helper similar to bus_find_device_by_name so that each driver
does not have to reinvent this.
Signed-off-by: Silesh C V
---
drivers/base/bus.c | 26 ++
include/linux/device.h | 3 +++
2 files changed, 29 insertions(+)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 8bfd27e..148b198 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -373,6 +374,31 @@ struct device *bus_find_device_by_name(struct bus_type
*bus,
}
EXPORT_SYMBOL_GPL(bus_find_device_by_name);
+static int match_fwnode(struct device *dev, void *data)
+{
+ struct fwnode_handle *fwnode = data;
+ struct device_node *of_node = to_of_node(fwnode);
+
+ if (of_node)
+ return dev->of_node == of_node;
+ else
+ return dev->fwnode == fwnode;
+}
+
+/**
+ * bus_find_device_by_fwnode - device iterator for locating a particular device
+ * having a specific firmware node
+ * @bus: bus type
+ * @start: Device to begin with
+ * @fwnode: firmware node of the device to match
+ */
+struct device *bus_find_device_by_fwnode(struct bus_type *bus, struct device
*start,
+ struct fwnode_handle *fwnode)
+{
+ return bus_find_device(bus, start, (void *)fwnode, match_fwnode);
+}
+EXPORT_SYMBOL_GPL(bus_find_device_by_fwnode);
+
/**
* subsys_find_device_by_id - find a device with a specific enumeration number
* @subsys: subsystem
diff --git a/include/linux/device.h b/include/linux/device.h
index 8f88254..09384f6 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -171,6 +171,9 @@ struct device *bus_find_device(struct bus_type *bus, struct
device *start,
struct device *bus_find_device_by_name(struct bus_type *bus,
struct device *start,
const char *name);
+struct device *bus_find_device_by_fwnode(struct bus_type *bus,
+ struct device *start,
+ struct fwnode_handle *fwnode);
struct device *subsys_find_device_by_id(struct bus_type *bus, unsigned int id,
struct device *hint);
int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
--
1.9.1
[PATCH v2 1/2] Driver core: add bus_find_device_by_fwnode
Some drivers need to find the device on a bus having a specific firmware
node. Currently, such drivers have their own implementations to do this.
Provide a helper similar to bus_find_device_by_name so that each driver
does not have to reinvent this.
Signed-off-by: Silesh C V
---
drivers/base/bus.c | 26 ++
include/linux/device.h | 3 +++
2 files changed, 29 insertions(+)
diff --git a/drivers/base/bus.c b/drivers/base/bus.c
index 8bfd27e..148b198 100644
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include "base.h"
#include "power/power.h"
@@ -373,6 +374,31 @@ struct device *bus_find_device_by_name(struct bus_type
*bus,
}
EXPORT_SYMBOL_GPL(bus_find_device_by_name);
+static int match_fwnode(struct device *dev, void *data)
+{
+ struct fwnode_handle *fwnode = data;
+ struct device_node *of_node = to_of_node(fwnode);
+
+ if (of_node)
+ return dev->of_node == of_node;
+ else
+ return dev->fwnode == fwnode;
+}
+
+/**
+ * bus_find_device_by_fwnode - device iterator for locating a particular device
+ * having a specific firmware node
+ * @bus: bus type
+ * @start: Device to begin with
+ * @fwnode: firmware node of the device to match
+ */
+struct device *bus_find_device_by_fwnode(struct bus_type *bus, struct device
*start,
+ struct fwnode_handle *fwnode)
+{
+ return bus_find_device(bus, start, (void *)fwnode, match_fwnode);
+}
+EXPORT_SYMBOL_GPL(bus_find_device_by_fwnode);
+
/**
* subsys_find_device_by_id - find a device with a specific enumeration number
* @subsys: subsystem
diff --git a/include/linux/device.h b/include/linux/device.h
index 8f88254..09384f6 100644
--- a/include/linux/device.h
+++ b/include/linux/device.h
@@ -171,6 +171,9 @@ struct device *bus_find_device(struct bus_type *bus, struct
device *start,
struct device *bus_find_device_by_name(struct bus_type *bus,
struct device *start,
const char *name);
+struct device *bus_find_device_by_fwnode(struct bus_type *bus,
+ struct device *start,
+ struct fwnode_handle *fwnode);
struct device *subsys_find_device_by_id(struct bus_type *bus, unsigned int id,
struct device *hint);
int bus_for_each_drv(struct bus_type *bus, struct device_driver *start,
--
1.9.1
Re: [PATCH] ARM: dts: gta04: add serial console wakeup irq
Hi Tony, On Mon, 24 Sep 2018 15:03:45 -0700 Tony Lindgren wrote: > * Andreas Kemnade [180923 08:12]: > > This enables the possibility to have more aggressive runtime pm > > by providing proper wakeup irq for the serial console. > > Thanks applying to omap-for-v4.20/dt. > > FYI, you can now grep wake /proc/interrupts and see the > wakeirq counts increase when they trigger. Might be handy > for debugging PM stuff. > thanks for that information, you also had a patch for checking pm which was explicitely marked as not-to-merge. Is there any up-to-date version of it? Well, for debugging I check first average currents via bq27000 attached to omap_hdq. omap_hdq gets stuck after first transaction after idling uarts which does not happen when CM_AUTOIDLE1_CORE.AUTO_HDQ is cleared. Reloading the omap_hdq module to try to fix things makes w1 really freak out (patch already sent for that). Well, will do some rtfm and hopefully come back with a patch. afaicr there was something special... The result are power management problem in /dev/brain ;-) Regards, Andreas pgpzzP9fixB_3.pgp Description: OpenPGP digital signature
Re: [PATCH] ARM: dts: gta04: add serial console wakeup irq
Hi Tony, On Mon, 24 Sep 2018 15:03:45 -0700 Tony Lindgren wrote: > * Andreas Kemnade [180923 08:12]: > > This enables the possibility to have more aggressive runtime pm > > by providing proper wakeup irq for the serial console. > > Thanks applying to omap-for-v4.20/dt. > > FYI, you can now grep wake /proc/interrupts and see the > wakeirq counts increase when they trigger. Might be handy > for debugging PM stuff. > thanks for that information, you also had a patch for checking pm which was explicitely marked as not-to-merge. Is there any up-to-date version of it? Well, for debugging I check first average currents via bq27000 attached to omap_hdq. omap_hdq gets stuck after first transaction after idling uarts which does not happen when CM_AUTOIDLE1_CORE.AUTO_HDQ is cleared. Reloading the omap_hdq module to try to fix things makes w1 really freak out (patch already sent for that). Well, will do some rtfm and hopefully come back with a patch. afaicr there was something special... The result are power management problem in /dev/brain ;-) Regards, Andreas pgpzzP9fixB_3.pgp Description: OpenPGP digital signature
[PATCH v4] ARM: dts: dra7: Fix up unaligned access setting for PCIe EP
Bit positions of PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE and
PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE in CTRL_CORE_SMA_SW_7 are
incorrectly documented in the TRM. In fact, the bit positions are
swapped. Update the DT bindings for PCIe EP to reflect the same.
Fixes: d23f3839fe97 ("ARM: dts: DRA7: Add pcie1 dt node for EP mode")
Cc: sta...@vger.kernel.org
Signed-off-by: Vignesh R
---
This patch is split from v3 here:
https://lore.kernel.org/patchwork/cover/967020/
Patch can be applied standalone and has no dependencies on other patches
in v3.
arch/arm/boot/dts/dra7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1050da6c6d35..fc50d6a8e51a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -355,7 +355,7 @@
ti,hwmods = "pcie1";
phys = <_phy>;
phy-names = "pcie-phy0";
- ti,syscon-unaligned-access = <_conf1 0x14
2>;
+ ti,syscon-unaligned-access = <_conf1 0x14
1>;
status = "disabled";
};
};
--
2.19.0
[PATCH v4] ARM: dts: dra7: Fix up unaligned access setting for PCIe EP
Bit positions of PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE and
PCIE_SS1_AXI2OCP_LEGACY_MODE_ENABLE in CTRL_CORE_SMA_SW_7 are
incorrectly documented in the TRM. In fact, the bit positions are
swapped. Update the DT bindings for PCIe EP to reflect the same.
Fixes: d23f3839fe97 ("ARM: dts: DRA7: Add pcie1 dt node for EP mode")
Cc: sta...@vger.kernel.org
Signed-off-by: Vignesh R
---
This patch is split from v3 here:
https://lore.kernel.org/patchwork/cover/967020/
Patch can be applied standalone and has no dependencies on other patches
in v3.
arch/arm/boot/dts/dra7.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 1050da6c6d35..fc50d6a8e51a 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -355,7 +355,7 @@
ti,hwmods = "pcie1";
phys = <_phy>;
phy-names = "pcie-phy0";
- ti,syscon-unaligned-access = <_conf1 0x14
2>;
+ ti,syscon-unaligned-access = <_conf1 0x14
1>;
status = "disabled";
};
};
--
2.19.0
RE: [PATCH] sdhci: arasan: Add runtime PM support
Ping!
> -Original Message-
> From: Manish Narani [mailto:manish.nar...@xilinx.com]
> Sent: Tuesday, September 18, 2018 8:34 PM
> To: adrian.hun...@intel.com; Michal Simek ;
> ulf.hans...@linaro.org
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Manish Narani
> Subject: [PATCH] sdhci: arasan: Add runtime PM support
>
> Add runtime PM support in Arasan SDHCI driver.
>
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 80
> +-
> 1 file changed, 78 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-
> arasan.c
> index a40bcc2..370ada5 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -30,6 +31,7 @@
> #include "cqhci.h"
> #include "sdhci-pltfm.h"
>
> +#define SDHCI_ARASAN_AUTOSUSPEND_DELAY 2000 /* ms */
> #define SDHCI_ARASAN_VENDOR_REGISTER 0x78
> #define SDHCI_ARASAN_CQE_BASE_ADDR 0x200
> #define VENDOR_ENHANCED_STROBE BIT(0)
> @@ -363,6 +365,70 @@ static const struct sdhci_pltfm_data
> sdhci_arasan_cqe_pdata = {
> SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN,
> };
>
> +#ifdef CONFIG_PM
> +static int sdhci_arasan_runtime_suspend(struct device *dev) {
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> + int ret;
> +
> + if (sdhci_arasan->has_cqe) {
> + ret = cqhci_suspend(host->mmc);
> + if (ret)
> + return ret;
> + }
> +
> + ret = sdhci_runtime_suspend_host(host);
> + if (ret)
> + return ret;
> +
> + if (host->tuning_mode != SDHCI_TUNING_MODE_3)
> + mmc_retune_needed(host->mmc);
> +
> + clk_disable(pltfm_host->clk);
> + clk_disable(sdhci_arasan->clk_ahb);
> +
> + return 0;
> +}
> +
> +static int sdhci_arasan_runtime_resume(struct device *dev) {
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> + int ret;
> +
> + ret = clk_enable(sdhci_arasan->clk_ahb);
> + if (ret) {
> + dev_err(dev, "Cannot enable AHB clock.\n");
> + return ret;
> + }
> +
> + ret = clk_enable(pltfm_host->clk);
> + if (ret) {
> + dev_err(dev, "Cannot enable SD clock.\n");
> + return ret;
> + }
> +
> + ret = sdhci_runtime_resume_host(host);
> + if (ret)
> + goto out;
> +
> + if (sdhci_arasan->has_cqe)
> + return cqhci_resume(host->mmc);
> +
> + return 0;
> +out:
> + clk_disable(pltfm_host->clk);
> + clk_disable(sdhci_arasan->clk_ahb);
> +
> + return ret;
> +}
> +#endif /* ! CONFIG_PM */
> +
> #ifdef CONFIG_PM_SLEEP
> /**
> * sdhci_arasan_suspend - Suspend method for the driver @@ -455,8 +521,10
> @@ static int sdhci_arasan_resume(struct device *dev) } #endif /* !
> CONFIG_PM_SLEEP */
>
> -static SIMPLE_DEV_PM_OPS(sdhci_arasan_dev_pm_ops,
> sdhci_arasan_suspend,
> - sdhci_arasan_resume);
> +static const struct dev_pm_ops sdhci_arasan_dev_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(sdhci_arasan_suspend,
> sdhci_arasan_resume)
> + SET_RUNTIME_PM_OPS(sdhci_arasan_runtime_suspend,
> +sdhci_arasan_runtime_resume, NULL) };
>
> static const struct of_device_id sdhci_arasan_of_match[] = {
> /* SoC-specific compatible strings w/ soc_ctl_map */ @@ -821,6
> +889,14 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> if (ret)
> goto err_add_host;
>
> + pm_runtime_set_active(>dev);
> + pm_runtime_enable(>dev);
> + pm_runtime_set_autosuspend_delay(>dev,
> +
> SDHCI_ARASAN_AUTOSUSPEND_DELAY);
> + pm_runtime_mark_last_busy(>dev);
> + pm_runtime_use_autosuspend(>dev);
> + pm_runtime_forbid(>dev);
> +
> return 0;
>
> err_add_host:
> --
> 2.1.1
RE: [PATCH] sdhci: arasan: Add runtime PM support
Ping!
> -Original Message-
> From: Manish Narani [mailto:manish.nar...@xilinx.com]
> Sent: Tuesday, September 18, 2018 8:34 PM
> To: adrian.hun...@intel.com; Michal Simek ;
> ulf.hans...@linaro.org
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org; Manish Narani
> Subject: [PATCH] sdhci: arasan: Add runtime PM support
>
> Add runtime PM support in Arasan SDHCI driver.
>
> Signed-off-by: Manish Narani
> ---
> drivers/mmc/host/sdhci-of-arasan.c | 80
> +-
> 1 file changed, 78 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-of-arasan.c b/drivers/mmc/host/sdhci-of-
> arasan.c
> index a40bcc2..370ada5 100644
> --- a/drivers/mmc/host/sdhci-of-arasan.c
> +++ b/drivers/mmc/host/sdhci-of-arasan.c
> @@ -23,6 +23,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -30,6 +31,7 @@
> #include "cqhci.h"
> #include "sdhci-pltfm.h"
>
> +#define SDHCI_ARASAN_AUTOSUSPEND_DELAY 2000 /* ms */
> #define SDHCI_ARASAN_VENDOR_REGISTER 0x78
> #define SDHCI_ARASAN_CQE_BASE_ADDR 0x200
> #define VENDOR_ENHANCED_STROBE BIT(0)
> @@ -363,6 +365,70 @@ static const struct sdhci_pltfm_data
> sdhci_arasan_cqe_pdata = {
> SDHCI_QUIRK2_CLOCK_DIV_ZERO_BROKEN,
> };
>
> +#ifdef CONFIG_PM
> +static int sdhci_arasan_runtime_suspend(struct device *dev) {
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> + int ret;
> +
> + if (sdhci_arasan->has_cqe) {
> + ret = cqhci_suspend(host->mmc);
> + if (ret)
> + return ret;
> + }
> +
> + ret = sdhci_runtime_suspend_host(host);
> + if (ret)
> + return ret;
> +
> + if (host->tuning_mode != SDHCI_TUNING_MODE_3)
> + mmc_retune_needed(host->mmc);
> +
> + clk_disable(pltfm_host->clk);
> + clk_disable(sdhci_arasan->clk_ahb);
> +
> + return 0;
> +}
> +
> +static int sdhci_arasan_runtime_resume(struct device *dev) {
> + struct platform_device *pdev = to_platform_device(dev);
> + struct sdhci_host *host = platform_get_drvdata(pdev);
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_arasan_data *sdhci_arasan =
> sdhci_pltfm_priv(pltfm_host);
> + int ret;
> +
> + ret = clk_enable(sdhci_arasan->clk_ahb);
> + if (ret) {
> + dev_err(dev, "Cannot enable AHB clock.\n");
> + return ret;
> + }
> +
> + ret = clk_enable(pltfm_host->clk);
> + if (ret) {
> + dev_err(dev, "Cannot enable SD clock.\n");
> + return ret;
> + }
> +
> + ret = sdhci_runtime_resume_host(host);
> + if (ret)
> + goto out;
> +
> + if (sdhci_arasan->has_cqe)
> + return cqhci_resume(host->mmc);
> +
> + return 0;
> +out:
> + clk_disable(pltfm_host->clk);
> + clk_disable(sdhci_arasan->clk_ahb);
> +
> + return ret;
> +}
> +#endif /* ! CONFIG_PM */
> +
> #ifdef CONFIG_PM_SLEEP
> /**
> * sdhci_arasan_suspend - Suspend method for the driver @@ -455,8 +521,10
> @@ static int sdhci_arasan_resume(struct device *dev) } #endif /* !
> CONFIG_PM_SLEEP */
>
> -static SIMPLE_DEV_PM_OPS(sdhci_arasan_dev_pm_ops,
> sdhci_arasan_suspend,
> - sdhci_arasan_resume);
> +static const struct dev_pm_ops sdhci_arasan_dev_pm_ops = {
> + SET_SYSTEM_SLEEP_PM_OPS(sdhci_arasan_suspend,
> sdhci_arasan_resume)
> + SET_RUNTIME_PM_OPS(sdhci_arasan_runtime_suspend,
> +sdhci_arasan_runtime_resume, NULL) };
>
> static const struct of_device_id sdhci_arasan_of_match[] = {
> /* SoC-specific compatible strings w/ soc_ctl_map */ @@ -821,6
> +889,14 @@ static int sdhci_arasan_probe(struct platform_device *pdev)
> if (ret)
> goto err_add_host;
>
> + pm_runtime_set_active(>dev);
> + pm_runtime_enable(>dev);
> + pm_runtime_set_autosuspend_delay(>dev,
> +
> SDHCI_ARASAN_AUTOSUSPEND_DELAY);
> + pm_runtime_mark_last_busy(>dev);
> + pm_runtime_use_autosuspend(>dev);
> + pm_runtime_forbid(>dev);
> +
> return 0;
>
> err_add_host:
> --
> 2.1.1
Re: [PATCH] of: unittest: Don't dereference args.np after test errors
Hi Frank,
On 09/24/2018 09:19 PM, Frank Rowand wrote:
Hi Guenter,
On 09/23/18 09:33, Guenter Roeck wrote:
If a devicetree parse function fails, it is quite likely that args.np
is invalid. Trying to dereference it will then cause the system to crash.
This was seen when trying to run devicetree unittests on a g3beige
qemu system. This system has the OF_IMAP_OLDWORLD_MAC flag set in
of_irq_workarounds and expects an 'old style' structure of irq
nodes. Trying to parse the test nodes fails and results in the
following crash.
OF: /testcase-data/phandle-tests/consumer-b: arguments longer than property
Unable to handle kernel paging request for data at address 0x00bc616e
Faulting instruction address: 0xc092437c
Oops: Kernel access of bad area, sig: 11 [#1]
BE PREEMPT PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #1
NIP: c092437c LR: c0925098 CTR: c0925088
REGS: cf8dfb40 TRAP: 0300 Not tainted (4.19.0-rc4-yocto-standard+)
MSR: 1032 CR: 82004044 XER:
DAR: 00bc616e DSISR: 4000
GPR00: c0925098 cf8dfbf0 cf8e c14098c7 c14098c7 c1409c50 0066 0002
GPR08: 0063 00bc614e c0b483e9 000a 82004048 0008 c0b36d80
GPR16: c0ac c0b4233c c14098c7 c0b13c14 05ff 000a c0b483e4 c0b00a30
GPR24: cecfe324 cecfe324 c0acc434 c0ac8420 c1409c50 05ff c1409c50 c14098c7
NIP [c092437c] device_node_gen_full_name+0x30/0x15c
LR [c0925098] device_node_string+0x190/0x3c8
Call Trace:
[cf8dfbf0] [c0733704] of_find_property+0x5c/0x74 (unreliable)
[cf8dfc30] [c0925098] device_node_string+0x190/0x3c8
[cf8dfca0] [c092690c] pointer+0x274/0x4d4
[cf8dfcd0] [c0926e20] vsnprintf+0x2b4/0x5ec
[cf8dfd30] [c0927170] vscnprintf+0x18/0x48
[cf8dfd40] [c008eb70] vprintk_store+0x4c/0x22c
[cf8dfd70] [c008f1c4] vprintk_emit+0x94/0x270
[cf8dfda0] [c008fb60] printk+0x5c/0x6c
[cf8dfde0] [c0bd1ec0] of_unittest+0x2670/0x2b48
[cf8dfe80] [c0004ba8] do_one_initcall+0xac/0x320
[cf8dfee0] [c0b8975c] kernel_init_freeable+0x328/0x3f0
[cf8dff30] [c00050c4] kernel_init+0x24/0x118
[cf8dff40] [c0014278] ret_from_kernel_thread+0x14/0x1c
To avoid this and similar problems, don't try to dereference args.np
after devicetree parse failures, and display the name of the parsed node
instead. With this, we get error messages such as
dt-test ### FAIL of_unittest_parse_interrupts():791 index 0 -
data error on node /testcase-data/interrupts/interrupts0 rc=-22
This may not display the intended node name, but it is better than a crash.
Thanks for finding and debugging the root cause of the problem.
As the patch comment notes, the changes do not fix the root cause, but
instead avoid the crash. I'd like to deal with the root cause instead.
I've never encountered OF_IMAP_OLDWORLD_MAC and need to dig deeper to
understand exactly how having it set leads to the error returns from
of_parse_phandle_with_args(). Thus my off-the-top-of-my-head first
observation is likely to be incorrect. But I'd like to point out
what I suspect is likely to be a more useful direction for the fix.
I'll use a bit of artful logic to claim that the root cause is that
of_parse_phandle_with_args() does not behave as unittests expect when
OF_IMAP_OLDWORLD_MAC is set.
If the of_parse_phandle_with_args() calls are not going to perform the
test that unittest expects to be performing, then it is pointless to
do the tests. The fix then is to not do those tests. For example,
at the top of of_unittest_parse_phandle_with_args(), simply do:
if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
return;
I thought about submitting that as second patch, but wanted to wait
for feedback before doing that. I'll be more than happy to drop this
patch and replace it with the above.
I did not look to see whether the other test areas you found can be
as easily avoided, without avoiding tests that are still valid when
OF_IMAP_OLDWORLD_MAC is set, but I am hoping so.
While looking at the patch, I noticed that the current
of_unittest_parse_phandle_with_args() also does not call of_node_put()
in the cases where of_count_phandle_with_args() does not return an
error. I'll add fixing that to my todo list.
And as you pointed out, of_unittest_parse_phandle_with_args() should
not be blindly using the contents of args when an error occurred. I'll
also put fixing that on my todo list.
That was the intent of this patch, but I'll be happy to leave it up to you
to find a better solution. I did not check if there are situations where
args.np is still usable, or if it makes a difference if args.np is
preinitialized with NULL, so it might well be that a better fix is
possible.
Thanks,
Guenter
-Frank
Fixes: 53a42093d96ef ("of: Add device tree selftests")
Signed-off-by: Guenter Roeck
---
drivers/of/unittest.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 722537e14848..5942ddce1b9f 100644
---
Re: [PATCH] of: unittest: Don't dereference args.np after test errors
Hi Frank,
On 09/24/2018 09:19 PM, Frank Rowand wrote:
Hi Guenter,
On 09/23/18 09:33, Guenter Roeck wrote:
If a devicetree parse function fails, it is quite likely that args.np
is invalid. Trying to dereference it will then cause the system to crash.
This was seen when trying to run devicetree unittests on a g3beige
qemu system. This system has the OF_IMAP_OLDWORLD_MAC flag set in
of_irq_workarounds and expects an 'old style' structure of irq
nodes. Trying to parse the test nodes fails and results in the
following crash.
OF: /testcase-data/phandle-tests/consumer-b: arguments longer than property
Unable to handle kernel paging request for data at address 0x00bc616e
Faulting instruction address: 0xc092437c
Oops: Kernel access of bad area, sig: 11 [#1]
BE PREEMPT PowerMac
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #1
NIP: c092437c LR: c0925098 CTR: c0925088
REGS: cf8dfb40 TRAP: 0300 Not tainted (4.19.0-rc4-yocto-standard+)
MSR: 1032 CR: 82004044 XER:
DAR: 00bc616e DSISR: 4000
GPR00: c0925098 cf8dfbf0 cf8e c14098c7 c14098c7 c1409c50 0066 0002
GPR08: 0063 00bc614e c0b483e9 000a 82004048 0008 c0b36d80
GPR16: c0ac c0b4233c c14098c7 c0b13c14 05ff 000a c0b483e4 c0b00a30
GPR24: cecfe324 cecfe324 c0acc434 c0ac8420 c1409c50 05ff c1409c50 c14098c7
NIP [c092437c] device_node_gen_full_name+0x30/0x15c
LR [c0925098] device_node_string+0x190/0x3c8
Call Trace:
[cf8dfbf0] [c0733704] of_find_property+0x5c/0x74 (unreliable)
[cf8dfc30] [c0925098] device_node_string+0x190/0x3c8
[cf8dfca0] [c092690c] pointer+0x274/0x4d4
[cf8dfcd0] [c0926e20] vsnprintf+0x2b4/0x5ec
[cf8dfd30] [c0927170] vscnprintf+0x18/0x48
[cf8dfd40] [c008eb70] vprintk_store+0x4c/0x22c
[cf8dfd70] [c008f1c4] vprintk_emit+0x94/0x270
[cf8dfda0] [c008fb60] printk+0x5c/0x6c
[cf8dfde0] [c0bd1ec0] of_unittest+0x2670/0x2b48
[cf8dfe80] [c0004ba8] do_one_initcall+0xac/0x320
[cf8dfee0] [c0b8975c] kernel_init_freeable+0x328/0x3f0
[cf8dff30] [c00050c4] kernel_init+0x24/0x118
[cf8dff40] [c0014278] ret_from_kernel_thread+0x14/0x1c
To avoid this and similar problems, don't try to dereference args.np
after devicetree parse failures, and display the name of the parsed node
instead. With this, we get error messages such as
dt-test ### FAIL of_unittest_parse_interrupts():791 index 0 -
data error on node /testcase-data/interrupts/interrupts0 rc=-22
This may not display the intended node name, but it is better than a crash.
Thanks for finding and debugging the root cause of the problem.
As the patch comment notes, the changes do not fix the root cause, but
instead avoid the crash. I'd like to deal with the root cause instead.
I've never encountered OF_IMAP_OLDWORLD_MAC and need to dig deeper to
understand exactly how having it set leads to the error returns from
of_parse_phandle_with_args(). Thus my off-the-top-of-my-head first
observation is likely to be incorrect. But I'd like to point out
what I suspect is likely to be a more useful direction for the fix.
I'll use a bit of artful logic to claim that the root cause is that
of_parse_phandle_with_args() does not behave as unittests expect when
OF_IMAP_OLDWORLD_MAC is set.
If the of_parse_phandle_with_args() calls are not going to perform the
test that unittest expects to be performing, then it is pointless to
do the tests. The fix then is to not do those tests. For example,
at the top of of_unittest_parse_phandle_with_args(), simply do:
if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
return;
I thought about submitting that as second patch, but wanted to wait
for feedback before doing that. I'll be more than happy to drop this
patch and replace it with the above.
I did not look to see whether the other test areas you found can be
as easily avoided, without avoiding tests that are still valid when
OF_IMAP_OLDWORLD_MAC is set, but I am hoping so.
While looking at the patch, I noticed that the current
of_unittest_parse_phandle_with_args() also does not call of_node_put()
in the cases where of_count_phandle_with_args() does not return an
error. I'll add fixing that to my todo list.
And as you pointed out, of_unittest_parse_phandle_with_args() should
not be blindly using the contents of args when an error occurred. I'll
also put fixing that on my todo list.
That was the intent of this patch, but I'll be happy to leave it up to you
to find a better solution. I did not check if there are situations where
args.np is still usable, or if it makes a difference if args.np is
preinitialized with NULL, so it might well be that a better fix is
possible.
Thanks,
Guenter
-Frank
Fixes: 53a42093d96ef ("of: Add device tree selftests")
Signed-off-by: Guenter Roeck
---
drivers/of/unittest.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
index 722537e14848..5942ddce1b9f 100644
---
Re: [PATCH] of: unittest: Don't dereference args.np after test errors
On 09/24/18 21:19, Frank Rowand wrote:
> Hi Guenter,
>
> On 09/23/18 09:33, Guenter Roeck wrote:
>> If a devicetree parse function fails, it is quite likely that args.np
>> is invalid. Trying to dereference it will then cause the system to crash.
>>
>> This was seen when trying to run devicetree unittests on a g3beige
>> qemu system. This system has the OF_IMAP_OLDWORLD_MAC flag set in
>> of_irq_workarounds and expects an 'old style' structure of irq
>> nodes. Trying to parse the test nodes fails and results in the
>> following crash.
>>
>> OF: /testcase-data/phandle-tests/consumer-b: arguments longer than property
>> Unable to handle kernel paging request for data at address 0x00bc616e
>> Faulting instruction address: 0xc092437c
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> BE PREEMPT PowerMac
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #1
>> NIP: c092437c LR: c0925098 CTR: c0925088
>> REGS: cf8dfb40 TRAP: 0300 Not tainted (4.19.0-rc4-yocto-standard+)
>> MSR: 1032 CR: 82004044 XER:
>> DAR: 00bc616e DSISR: 4000
>> GPR00: c0925098 cf8dfbf0 cf8e c14098c7 c14098c7 c1409c50 0066
>> 0002
>> GPR08: 0063 00bc614e c0b483e9 000a 82004048 0008
>> c0b36d80
>> GPR16: c0ac c0b4233c c14098c7 c0b13c14 05ff 000a c0b483e4
>> c0b00a30
>> GPR24: cecfe324 cecfe324 c0acc434 c0ac8420 c1409c50 05ff c1409c50
>> c14098c7
>> NIP [c092437c] device_node_gen_full_name+0x30/0x15c
>> LR [c0925098] device_node_string+0x190/0x3c8
>> Call Trace:
>> [cf8dfbf0] [c0733704] of_find_property+0x5c/0x74 (unreliable)
>> [cf8dfc30] [c0925098] device_node_string+0x190/0x3c8
>> [cf8dfca0] [c092690c] pointer+0x274/0x4d4
>> [cf8dfcd0] [c0926e20] vsnprintf+0x2b4/0x5ec
>> [cf8dfd30] [c0927170] vscnprintf+0x18/0x48
>> [cf8dfd40] [c008eb70] vprintk_store+0x4c/0x22c
>> [cf8dfd70] [c008f1c4] vprintk_emit+0x94/0x270
>> [cf8dfda0] [c008fb60] printk+0x5c/0x6c
>> [cf8dfde0] [c0bd1ec0] of_unittest+0x2670/0x2b48
>> [cf8dfe80] [c0004ba8] do_one_initcall+0xac/0x320
>> [cf8dfee0] [c0b8975c] kernel_init_freeable+0x328/0x3f0
>> [cf8dff30] [c00050c4] kernel_init+0x24/0x118
>> [cf8dff40] [c0014278] ret_from_kernel_thread+0x14/0x1c
>>
>> To avoid this and similar problems, don't try to dereference args.np
>> after devicetree parse failures, and display the name of the parsed node
>> instead. With this, we get error messages such as
>>
>> dt-test ### FAIL of_unittest_parse_interrupts():791 index 0 -
>> data error on node /testcase-data/interrupts/interrupts0 rc=-22
>>
>> This may not display the intended node name, but it is better than a crash.
>
> Thanks for finding and debugging the root cause of the problem.
>
> As the patch comment notes, the changes do not fix the root cause, but
> instead avoid the crash. I'd like to deal with the root cause instead.
>
> I've never encountered OF_IMAP_OLDWORLD_MAC and need to dig deeper to
> understand exactly how having it set leads to the error returns from
> of_parse_phandle_with_args(). Thus my off-the-top-of-my-head first
> observation is likely to be incorrect. But I'd like to point out
> what I suspect is likely to be a more useful direction for the fix.
>
> I'll use a bit of artful logic to claim that the root cause is that
> of_parse_phandle_with_args() does not behave as unittests expect when
> OF_IMAP_OLDWORLD_MAC is set.
>
> If the of_parse_phandle_with_args() calls are not going to perform the
> test that unittest expects to be performing, then it is pointless to
> do the tests. The fix then is to not do those tests. For example,
> at the top of of_unittest_parse_phandle_with_args(), simply do:
>
> if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
> return;
I forgot to mention another rationale for this approach. This will result
in the number of failed tests to remain at zero.
-Frank
> I did not look to see whether the other test areas you found can be
> as easily avoided, without avoiding tests that are still valid when
> OF_IMAP_OLDWORLD_MAC is set, but I am hoping so.
>
> While looking at the patch, I noticed that the current
> of_unittest_parse_phandle_with_args() also does not call of_node_put()
> in the cases where of_count_phandle_with_args() does not return an
> error. I'll add fixing that to my todo list.
>
> And as you pointed out, of_unittest_parse_phandle_with_args() should
> not be blindly using the contents of args when an error occurred. I'll
> also put fixing that on my todo list.
>
> -Frank
>
>
>
>>
>> Fixes: 53a42093d96ef ("of: Add device tree selftests")
>> Signed-off-by: Guenter Roeck
>> ---
>> drivers/of/unittest.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
>> index 722537e14848..5942ddce1b9f 100644
>> --- a/drivers/of/unittest.c
>> +++ b/drivers/of/unittest.c
>> @@ -424,7 +424,7 @@ static void __init
>>
Re: [PATCH] of: unittest: Don't dereference args.np after test errors
On 09/24/18 21:19, Frank Rowand wrote:
> Hi Guenter,
>
> On 09/23/18 09:33, Guenter Roeck wrote:
>> If a devicetree parse function fails, it is quite likely that args.np
>> is invalid. Trying to dereference it will then cause the system to crash.
>>
>> This was seen when trying to run devicetree unittests on a g3beige
>> qemu system. This system has the OF_IMAP_OLDWORLD_MAC flag set in
>> of_irq_workarounds and expects an 'old style' structure of irq
>> nodes. Trying to parse the test nodes fails and results in the
>> following crash.
>>
>> OF: /testcase-data/phandle-tests/consumer-b: arguments longer than property
>> Unable to handle kernel paging request for data at address 0x00bc616e
>> Faulting instruction address: 0xc092437c
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> BE PREEMPT PowerMac
>> Modules linked in:
>> CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #1
>> NIP: c092437c LR: c0925098 CTR: c0925088
>> REGS: cf8dfb40 TRAP: 0300 Not tainted (4.19.0-rc4-yocto-standard+)
>> MSR: 1032 CR: 82004044 XER:
>> DAR: 00bc616e DSISR: 4000
>> GPR00: c0925098 cf8dfbf0 cf8e c14098c7 c14098c7 c1409c50 0066
>> 0002
>> GPR08: 0063 00bc614e c0b483e9 000a 82004048 0008
>> c0b36d80
>> GPR16: c0ac c0b4233c c14098c7 c0b13c14 05ff 000a c0b483e4
>> c0b00a30
>> GPR24: cecfe324 cecfe324 c0acc434 c0ac8420 c1409c50 05ff c1409c50
>> c14098c7
>> NIP [c092437c] device_node_gen_full_name+0x30/0x15c
>> LR [c0925098] device_node_string+0x190/0x3c8
>> Call Trace:
>> [cf8dfbf0] [c0733704] of_find_property+0x5c/0x74 (unreliable)
>> [cf8dfc30] [c0925098] device_node_string+0x190/0x3c8
>> [cf8dfca0] [c092690c] pointer+0x274/0x4d4
>> [cf8dfcd0] [c0926e20] vsnprintf+0x2b4/0x5ec
>> [cf8dfd30] [c0927170] vscnprintf+0x18/0x48
>> [cf8dfd40] [c008eb70] vprintk_store+0x4c/0x22c
>> [cf8dfd70] [c008f1c4] vprintk_emit+0x94/0x270
>> [cf8dfda0] [c008fb60] printk+0x5c/0x6c
>> [cf8dfde0] [c0bd1ec0] of_unittest+0x2670/0x2b48
>> [cf8dfe80] [c0004ba8] do_one_initcall+0xac/0x320
>> [cf8dfee0] [c0b8975c] kernel_init_freeable+0x328/0x3f0
>> [cf8dff30] [c00050c4] kernel_init+0x24/0x118
>> [cf8dff40] [c0014278] ret_from_kernel_thread+0x14/0x1c
>>
>> To avoid this and similar problems, don't try to dereference args.np
>> after devicetree parse failures, and display the name of the parsed node
>> instead. With this, we get error messages such as
>>
>> dt-test ### FAIL of_unittest_parse_interrupts():791 index 0 -
>> data error on node /testcase-data/interrupts/interrupts0 rc=-22
>>
>> This may not display the intended node name, but it is better than a crash.
>
> Thanks for finding and debugging the root cause of the problem.
>
> As the patch comment notes, the changes do not fix the root cause, but
> instead avoid the crash. I'd like to deal with the root cause instead.
>
> I've never encountered OF_IMAP_OLDWORLD_MAC and need to dig deeper to
> understand exactly how having it set leads to the error returns from
> of_parse_phandle_with_args(). Thus my off-the-top-of-my-head first
> observation is likely to be incorrect. But I'd like to point out
> what I suspect is likely to be a more useful direction for the fix.
>
> I'll use a bit of artful logic to claim that the root cause is that
> of_parse_phandle_with_args() does not behave as unittests expect when
> OF_IMAP_OLDWORLD_MAC is set.
>
> If the of_parse_phandle_with_args() calls are not going to perform the
> test that unittest expects to be performing, then it is pointless to
> do the tests. The fix then is to not do those tests. For example,
> at the top of of_unittest_parse_phandle_with_args(), simply do:
>
> if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
> return;
I forgot to mention another rationale for this approach. This will result
in the number of failed tests to remain at zero.
-Frank
> I did not look to see whether the other test areas you found can be
> as easily avoided, without avoiding tests that are still valid when
> OF_IMAP_OLDWORLD_MAC is set, but I am hoping so.
>
> While looking at the patch, I noticed that the current
> of_unittest_parse_phandle_with_args() also does not call of_node_put()
> in the cases where of_count_phandle_with_args() does not return an
> error. I'll add fixing that to my todo list.
>
> And as you pointed out, of_unittest_parse_phandle_with_args() should
> not be blindly using the contents of args when an error occurred. I'll
> also put fixing that on my todo list.
>
> -Frank
>
>
>
>>
>> Fixes: 53a42093d96ef ("of: Add device tree selftests")
>> Signed-off-by: Guenter Roeck
>> ---
>> drivers/of/unittest.c | 12 ++--
>> 1 file changed, 6 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
>> index 722537e14848..5942ddce1b9f 100644
>> --- a/drivers/of/unittest.c
>> +++ b/drivers/of/unittest.c
>> @@ -424,7 +424,7 @@ static void __init
>>
[0-Day CI notification] 0-Day CI test service will be unavailable from Sep 30 to Oct 8
Hi all, this is Philip who maintains the 0-Day CI test service. Thanks for subscribing to the service. We will have site level power down during China national holiday, so the service will be unavailable from Asia Pacific Time Sep 30 5PM to Oct 8 5PM. We will recover it as soon as we can. Sorry for any inconvenience caused during this period. Thanks
[0-Day CI notification] 0-Day CI test service will be unavailable from Sep 30 to Oct 8
Hi all, this is Philip who maintains the 0-Day CI test service. Thanks for subscribing to the service. We will have site level power down during China national holiday, so the service will be unavailable from Asia Pacific Time Sep 30 5PM to Oct 8 5PM. We will recover it as soon as we can. Sorry for any inconvenience caused during this period. Thanks
Re: [PATCH] of: unittest: Don't dereference args.np after test errors
Hi Guenter,
On 09/23/18 09:33, Guenter Roeck wrote:
> If a devicetree parse function fails, it is quite likely that args.np
> is invalid. Trying to dereference it will then cause the system to crash.
>
> This was seen when trying to run devicetree unittests on a g3beige
> qemu system. This system has the OF_IMAP_OLDWORLD_MAC flag set in
> of_irq_workarounds and expects an 'old style' structure of irq
> nodes. Trying to parse the test nodes fails and results in the
> following crash.
>
> OF: /testcase-data/phandle-tests/consumer-b: arguments longer than property
> Unable to handle kernel paging request for data at address 0x00bc616e
> Faulting instruction address: 0xc092437c
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PREEMPT PowerMac
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #1
> NIP: c092437c LR: c0925098 CTR: c0925088
> REGS: cf8dfb40 TRAP: 0300 Not tainted (4.19.0-rc4-yocto-standard+)
> MSR: 1032 CR: 82004044 XER:
> DAR: 00bc616e DSISR: 4000
> GPR00: c0925098 cf8dfbf0 cf8e c14098c7 c14098c7 c1409c50 0066 0002
> GPR08: 0063 00bc614e c0b483e9 000a 82004048 0008 c0b36d80
> GPR16: c0ac c0b4233c c14098c7 c0b13c14 05ff 000a c0b483e4 c0b00a30
> GPR24: cecfe324 cecfe324 c0acc434 c0ac8420 c1409c50 05ff c1409c50 c14098c7
> NIP [c092437c] device_node_gen_full_name+0x30/0x15c
> LR [c0925098] device_node_string+0x190/0x3c8
> Call Trace:
> [cf8dfbf0] [c0733704] of_find_property+0x5c/0x74 (unreliable)
> [cf8dfc30] [c0925098] device_node_string+0x190/0x3c8
> [cf8dfca0] [c092690c] pointer+0x274/0x4d4
> [cf8dfcd0] [c0926e20] vsnprintf+0x2b4/0x5ec
> [cf8dfd30] [c0927170] vscnprintf+0x18/0x48
> [cf8dfd40] [c008eb70] vprintk_store+0x4c/0x22c
> [cf8dfd70] [c008f1c4] vprintk_emit+0x94/0x270
> [cf8dfda0] [c008fb60] printk+0x5c/0x6c
> [cf8dfde0] [c0bd1ec0] of_unittest+0x2670/0x2b48
> [cf8dfe80] [c0004ba8] do_one_initcall+0xac/0x320
> [cf8dfee0] [c0b8975c] kernel_init_freeable+0x328/0x3f0
> [cf8dff30] [c00050c4] kernel_init+0x24/0x118
> [cf8dff40] [c0014278] ret_from_kernel_thread+0x14/0x1c
>
> To avoid this and similar problems, don't try to dereference args.np
> after devicetree parse failures, and display the name of the parsed node
> instead. With this, we get error messages such as
>
> dt-test ### FAIL of_unittest_parse_interrupts():791 index 0 -
> data error on node /testcase-data/interrupts/interrupts0 rc=-22
>
> This may not display the intended node name, but it is better than a crash.
Thanks for finding and debugging the root cause of the problem.
As the patch comment notes, the changes do not fix the root cause, but
instead avoid the crash. I'd like to deal with the root cause instead.
I've never encountered OF_IMAP_OLDWORLD_MAC and need to dig deeper to
understand exactly how having it set leads to the error returns from
of_parse_phandle_with_args(). Thus my off-the-top-of-my-head first
observation is likely to be incorrect. But I'd like to point out
what I suspect is likely to be a more useful direction for the fix.
I'll use a bit of artful logic to claim that the root cause is that
of_parse_phandle_with_args() does not behave as unittests expect when
OF_IMAP_OLDWORLD_MAC is set.
If the of_parse_phandle_with_args() calls are not going to perform the
test that unittest expects to be performing, then it is pointless to
do the tests. The fix then is to not do those tests. For example,
at the top of of_unittest_parse_phandle_with_args(), simply do:
if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
return;
I did not look to see whether the other test areas you found can be
as easily avoided, without avoiding tests that are still valid when
OF_IMAP_OLDWORLD_MAC is set, but I am hoping so.
While looking at the patch, I noticed that the current
of_unittest_parse_phandle_with_args() also does not call of_node_put()
in the cases where of_count_phandle_with_args() does not return an
error. I'll add fixing that to my todo list.
And as you pointed out, of_unittest_parse_phandle_with_args() should
not be blindly using the contents of args when an error occurred. I'll
also put fixing that on my todo list.
-Frank
>
> Fixes: 53a42093d96ef ("of: Add device tree selftests")
> Signed-off-by: Guenter Roeck
> ---
> drivers/of/unittest.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 722537e14848..5942ddce1b9f 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -424,7 +424,7 @@ static void __init
> of_unittest_parse_phandle_with_args(void)
> }
>
> unittest(passed, "index %i - data error on node %pOF rc=%i\n",
> - i, args.np, rc);
> + i, np, rc);
> }
>
> /* Check for missing list property */
> @@ -554,8 +554,8 @@ static void __init
>
Re: [PATCH] of: unittest: Don't dereference args.np after test errors
Hi Guenter,
On 09/23/18 09:33, Guenter Roeck wrote:
> If a devicetree parse function fails, it is quite likely that args.np
> is invalid. Trying to dereference it will then cause the system to crash.
>
> This was seen when trying to run devicetree unittests on a g3beige
> qemu system. This system has the OF_IMAP_OLDWORLD_MAC flag set in
> of_irq_workarounds and expects an 'old style' structure of irq
> nodes. Trying to parse the test nodes fails and results in the
> following crash.
>
> OF: /testcase-data/phandle-tests/consumer-b: arguments longer than property
> Unable to handle kernel paging request for data at address 0x00bc616e
> Faulting instruction address: 0xc092437c
> Oops: Kernel access of bad area, sig: 11 [#1]
> BE PREEMPT PowerMac
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.0-rc4-yocto-standard+ #1
> NIP: c092437c LR: c0925098 CTR: c0925088
> REGS: cf8dfb40 TRAP: 0300 Not tainted (4.19.0-rc4-yocto-standard+)
> MSR: 1032 CR: 82004044 XER:
> DAR: 00bc616e DSISR: 4000
> GPR00: c0925098 cf8dfbf0 cf8e c14098c7 c14098c7 c1409c50 0066 0002
> GPR08: 0063 00bc614e c0b483e9 000a 82004048 0008 c0b36d80
> GPR16: c0ac c0b4233c c14098c7 c0b13c14 05ff 000a c0b483e4 c0b00a30
> GPR24: cecfe324 cecfe324 c0acc434 c0ac8420 c1409c50 05ff c1409c50 c14098c7
> NIP [c092437c] device_node_gen_full_name+0x30/0x15c
> LR [c0925098] device_node_string+0x190/0x3c8
> Call Trace:
> [cf8dfbf0] [c0733704] of_find_property+0x5c/0x74 (unreliable)
> [cf8dfc30] [c0925098] device_node_string+0x190/0x3c8
> [cf8dfca0] [c092690c] pointer+0x274/0x4d4
> [cf8dfcd0] [c0926e20] vsnprintf+0x2b4/0x5ec
> [cf8dfd30] [c0927170] vscnprintf+0x18/0x48
> [cf8dfd40] [c008eb70] vprintk_store+0x4c/0x22c
> [cf8dfd70] [c008f1c4] vprintk_emit+0x94/0x270
> [cf8dfda0] [c008fb60] printk+0x5c/0x6c
> [cf8dfde0] [c0bd1ec0] of_unittest+0x2670/0x2b48
> [cf8dfe80] [c0004ba8] do_one_initcall+0xac/0x320
> [cf8dfee0] [c0b8975c] kernel_init_freeable+0x328/0x3f0
> [cf8dff30] [c00050c4] kernel_init+0x24/0x118
> [cf8dff40] [c0014278] ret_from_kernel_thread+0x14/0x1c
>
> To avoid this and similar problems, don't try to dereference args.np
> after devicetree parse failures, and display the name of the parsed node
> instead. With this, we get error messages such as
>
> dt-test ### FAIL of_unittest_parse_interrupts():791 index 0 -
> data error on node /testcase-data/interrupts/interrupts0 rc=-22
>
> This may not display the intended node name, but it is better than a crash.
Thanks for finding and debugging the root cause of the problem.
As the patch comment notes, the changes do not fix the root cause, but
instead avoid the crash. I'd like to deal with the root cause instead.
I've never encountered OF_IMAP_OLDWORLD_MAC and need to dig deeper to
understand exactly how having it set leads to the error returns from
of_parse_phandle_with_args(). Thus my off-the-top-of-my-head first
observation is likely to be incorrect. But I'd like to point out
what I suspect is likely to be a more useful direction for the fix.
I'll use a bit of artful logic to claim that the root cause is that
of_parse_phandle_with_args() does not behave as unittests expect when
OF_IMAP_OLDWORLD_MAC is set.
If the of_parse_phandle_with_args() calls are not going to perform the
test that unittest expects to be performing, then it is pointless to
do the tests. The fix then is to not do those tests. For example,
at the top of of_unittest_parse_phandle_with_args(), simply do:
if (of_irq_workarounds & OF_IMAP_OLDWORLD_MAC)
return;
I did not look to see whether the other test areas you found can be
as easily avoided, without avoiding tests that are still valid when
OF_IMAP_OLDWORLD_MAC is set, but I am hoping so.
While looking at the patch, I noticed that the current
of_unittest_parse_phandle_with_args() also does not call of_node_put()
in the cases where of_count_phandle_with_args() does not return an
error. I'll add fixing that to my todo list.
And as you pointed out, of_unittest_parse_phandle_with_args() should
not be blindly using the contents of args when an error occurred. I'll
also put fixing that on my todo list.
-Frank
>
> Fixes: 53a42093d96ef ("of: Add device tree selftests")
> Signed-off-by: Guenter Roeck
> ---
> drivers/of/unittest.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/of/unittest.c b/drivers/of/unittest.c
> index 722537e14848..5942ddce1b9f 100644
> --- a/drivers/of/unittest.c
> +++ b/drivers/of/unittest.c
> @@ -424,7 +424,7 @@ static void __init
> of_unittest_parse_phandle_with_args(void)
> }
>
> unittest(passed, "index %i - data error on node %pOF rc=%i\n",
> - i, args.np, rc);
> + i, np, rc);
> }
>
> /* Check for missing list property */
> @@ -554,8 +554,8 @@ static void __init
>
Re: Portable DT Connectors with regard to FPGAs
On Mon, Sep 24, 2018 at 03:32:44PM -0500, Alan Tull wrote: > My interest here was in having some discussion on whether connectors > are a good match for handling FPGAs. > > The relevant use model is where a user applies a DT overlay targeting > an FPGA region after the kernel has booted. That overlay initiates > FPGA programming and then adds nodes for the new FPGA hardware. This > is discussed more completely in the FPGA manager DT binding document > [1]. The main deal here is that I'd like to be able to add nodes > in/below a FPGA region node to support devices in the FPGA (and be > able also to remove them if we are going to reconfigure the FPGA.) > > Previous discussions about DT connectors focused on the types of > things likely to be on a physical connector. GPIO and SPI got named as > good examples for discussion while MMIO specifically was dismissed > [2]. That's problematic for embedded FPGAs for example since the FPGA > is on a mmio bus and hardware that is programmed into the FPGA lives > on that mmio bus similar to any embedded peripherals. So there's a > question - are mmio busses intended to be left un-connectorizable? I don't see any particular reason that a connector couldn't be used for mmio devices. I think you'd want to treat the connection point as a bridge on the mmio bus - that can have a 'ranges' property mapping the connected device into the parent bus's address space (as an identity mapping or otherwise). > > Alan > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/fpga/fpga-region.txt > > [2] https://lkml.org/lkml/2016/7/20/560 > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: Portable DT Connectors with regard to FPGAs
On Mon, Sep 24, 2018 at 03:32:44PM -0500, Alan Tull wrote: > My interest here was in having some discussion on whether connectors > are a good match for handling FPGAs. > > The relevant use model is where a user applies a DT overlay targeting > an FPGA region after the kernel has booted. That overlay initiates > FPGA programming and then adds nodes for the new FPGA hardware. This > is discussed more completely in the FPGA manager DT binding document > [1]. The main deal here is that I'd like to be able to add nodes > in/below a FPGA region node to support devices in the FPGA (and be > able also to remove them if we are going to reconfigure the FPGA.) > > Previous discussions about DT connectors focused on the types of > things likely to be on a physical connector. GPIO and SPI got named as > good examples for discussion while MMIO specifically was dismissed > [2]. That's problematic for embedded FPGAs for example since the FPGA > is on a mmio bus and hardware that is programmed into the FPGA lives > on that mmio bus similar to any embedded peripherals. So there's a > question - are mmio busses intended to be left un-connectorizable? I don't see any particular reason that a connector couldn't be used for mmio devices. I think you'd want to treat the connection point as a bridge on the mmio bus - that can have a 'ranges' property mapping the connected device into the parent bus's address space (as an identity mapping or otherwise). > > Alan > > [1] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/fpga/fpga-region.txt > > [2] https://lkml.org/lkml/2016/7/20/560 > -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson signature.asc Description: PGP signature
Re: [PATCH 4.9 111/111] MIPS: VDSO: Drop gic_get_usm_range() usage
Hi,
Guenter Roeck 於 2018年9月25日 週二 上午9:36寫道：
>
> On Mon, Sep 24, 2018 at 01:53:18PM +0200, Greg Kroah-Hartman wrote:
> > 4.9-stable review patch. If anyone has any objections, please let me know.
> >
>
> This patch breaks v4.4.y and v4.9.y builds.
> It includes asm/mips-cps.h which doesn't exist in those releases.
I am sorry for my fault, thanks for your report.
Since the patch b025d51873d5fe6 "MIPS: CM: Specify register size when
generating accessors" which created asm/mips-cps.h is not a bug-fixed
patch, hence I will not backport this header.
Hi Greg,
Could you please help to revert this commit? This commit was intended
to fix dependency of 70d7783 "MIPS: VDSO: Match data page cache
colouring when D$ aliases", but I saw 70d7783 was merged before this
commit; therefore, I don't think it is necessary to keep this commit.
I apology for any inconvenience caused, and I will be more careful next time.
SZ Lin (林上智)
>
> Building mips:malta_defconfig:smp:initrd ... failed
>
> Error log:
> arch/mips/kernel/vdso.c:23:26: fatal error: asm/mips-cps.h: No such file or
> directory
>
> Guenter
>
> > --
> >
> > From: Paul Burton
> >
> > commit 00578cd864d45ae4b8fa3f684f8d6f783dd8d15d upstream.
> >
> > We don't really need gic_get_usm_range() to abstract discovery of the
> > address of the GIC user-visible section now that we have access to its
> > base address globally.
> >
> > Switch to calculating it ourselves, which will allow us to stop
> > requiring the irqchip driver to care about a counter exposed to userland
> > for use via the VDSO.
> >
> > Signed-off-by: Paul Burton
> > Cc: Jason Cooper
> > Cc: Marc Zyngier
> > Cc: Thomas Gleixner
> > Cc: linux-m...@linux-mips.org
> > Patchwork: https://patchwork.linux-mips.org/patch/17040/
> > Signed-off-by: Ralf Baechle
> > Signed-off-by: SZ Lin (林上智)
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > arch/mips/kernel/vdso.c | 15 +--
> > 1 file changed, 5 insertions(+), 10 deletions(-)
> >
> > --- a/arch/mips/kernel/vdso.c
> > +++ b/arch/mips/kernel/vdso.c
> > @@ -13,7 +13,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -21,6 +20,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -101,9 +101,8 @@ int arch_setup_additional_pages(struct l
> > {
> > struct mips_vdso_image *image = current->thread.abi->vdso;
> > struct mm_struct *mm = current->mm;
> > - unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr;
> > + unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr,
> > gic_pfn;
> > struct vm_area_struct *vma;
> > - struct resource gic_res;
> > int ret;
> >
> > if (down_write_killable(>mmap_sem))
> > @@ -127,7 +126,7 @@ int arch_setup_additional_pages(struct l
> >* only map a page even though the total area is 64K, as we only need
> >* the counter registers at the start.
> >*/
> > - gic_size = gic_present ? PAGE_SIZE : 0;
> > + gic_size = mips_gic_present() ? PAGE_SIZE : 0;
> > vvar_size = gic_size + PAGE_SIZE;
> > size = vvar_size + image->size;
> >
> > @@ -168,13 +167,9 @@ int arch_setup_additional_pages(struct l
> >
> > /* Map GIC user page. */
> > if (gic_size) {
> > - ret = gic_get_usm_range(_res);
> > - if (ret)
> > - goto out;
> > + gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >>
> > PAGE_SHIFT;
> >
> > - ret = io_remap_pfn_range(vma, base,
> > - gic_res.start >> PAGE_SHIFT,
> > - gic_size,
> > + ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
> >pgprot_noncached(PAGE_READONLY));
> > if (ret)
> > goto out;
> >
> >
Re: [PATCH 4.9 111/111] MIPS: VDSO: Drop gic_get_usm_range() usage
Hi,
Guenter Roeck 於 2018年9月25日 週二 上午9:36寫道：
>
> On Mon, Sep 24, 2018 at 01:53:18PM +0200, Greg Kroah-Hartman wrote:
> > 4.9-stable review patch. If anyone has any objections, please let me know.
> >
>
> This patch breaks v4.4.y and v4.9.y builds.
> It includes asm/mips-cps.h which doesn't exist in those releases.
I am sorry for my fault, thanks for your report.
Since the patch b025d51873d5fe6 "MIPS: CM: Specify register size when
generating accessors" which created asm/mips-cps.h is not a bug-fixed
patch, hence I will not backport this header.
Hi Greg,
Could you please help to revert this commit? This commit was intended
to fix dependency of 70d7783 "MIPS: VDSO: Match data page cache
colouring when D$ aliases", but I saw 70d7783 was merged before this
commit; therefore, I don't think it is necessary to keep this commit.
I apology for any inconvenience caused, and I will be more careful next time.
SZ Lin (林上智)
>
> Building mips:malta_defconfig:smp:initrd ... failed
>
> Error log:
> arch/mips/kernel/vdso.c:23:26: fatal error: asm/mips-cps.h: No such file or
> directory
>
> Guenter
>
> > --
> >
> > From: Paul Burton
> >
> > commit 00578cd864d45ae4b8fa3f684f8d6f783dd8d15d upstream.
> >
> > We don't really need gic_get_usm_range() to abstract discovery of the
> > address of the GIC user-visible section now that we have access to its
> > base address globally.
> >
> > Switch to calculating it ourselves, which will allow us to stop
> > requiring the irqchip driver to care about a counter exposed to userland
> > for use via the VDSO.
> >
> > Signed-off-by: Paul Burton
> > Cc: Jason Cooper
> > Cc: Marc Zyngier
> > Cc: Thomas Gleixner
> > Cc: linux-m...@linux-mips.org
> > Patchwork: https://patchwork.linux-mips.org/patch/17040/
> > Signed-off-by: Ralf Baechle
> > Signed-off-by: SZ Lin (林上智)
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > arch/mips/kernel/vdso.c | 15 +--
> > 1 file changed, 5 insertions(+), 10 deletions(-)
> >
> > --- a/arch/mips/kernel/vdso.c
> > +++ b/arch/mips/kernel/vdso.c
> > @@ -13,7 +13,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> > #include
> > @@ -21,6 +20,7 @@
> > #include
> >
> > #include
> > +#include
> > #include
> > #include
> >
> > @@ -101,9 +101,8 @@ int arch_setup_additional_pages(struct l
> > {
> > struct mips_vdso_image *image = current->thread.abi->vdso;
> > struct mm_struct *mm = current->mm;
> > - unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr;
> > + unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr,
> > gic_pfn;
> > struct vm_area_struct *vma;
> > - struct resource gic_res;
> > int ret;
> >
> > if (down_write_killable(>mmap_sem))
> > @@ -127,7 +126,7 @@ int arch_setup_additional_pages(struct l
> >* only map a page even though the total area is 64K, as we only need
> >* the counter registers at the start.
> >*/
> > - gic_size = gic_present ? PAGE_SIZE : 0;
> > + gic_size = mips_gic_present() ? PAGE_SIZE : 0;
> > vvar_size = gic_size + PAGE_SIZE;
> > size = vvar_size + image->size;
> >
> > @@ -168,13 +167,9 @@ int arch_setup_additional_pages(struct l
> >
> > /* Map GIC user page. */
> > if (gic_size) {
> > - ret = gic_get_usm_range(_res);
> > - if (ret)
> > - goto out;
> > + gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >>
> > PAGE_SHIFT;
> >
> > - ret = io_remap_pfn_range(vma, base,
> > - gic_res.start >> PAGE_SHIFT,
> > - gic_size,
> > + ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
> >pgprot_noncached(PAGE_READONLY));
> > if (ret)
> > goto out;
> >
> >
Re: [PATCH] sparc64: viohs: Remove VLA usage
From: Kees Cook Date: Mon, 24 Sep 2018 20:17:55 -0700 > On Wed, Sep 5, 2018 at 3:03 PM, Kees Cook wrote: >> In the quest to remove all stack VLA usage from the kernel[1], this >> allocates a fixed size array for the maximum number of cookies and >> adds a runtime sanity check. >> >> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1 >> rq...@mail.gmail.com >> >> Signed-off-by: Kees Cook > > Friendly ping. Dave, can you take this? I'll try to get to this soon, kinda backlogged at the moment. Sorry.
Re: [PATCH] sparc64: viohs: Remove VLA usage
From: Kees Cook Date: Mon, 24 Sep 2018 20:17:55 -0700 > On Wed, Sep 5, 2018 at 3:03 PM, Kees Cook wrote: >> In the quest to remove all stack VLA usage from the kernel[1], this >> allocates a fixed size array for the maximum number of cookies and >> adds a runtime sanity check. >> >> [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1 >> rq...@mail.gmail.com >> >> Signed-off-by: Kees Cook > > Friendly ping. Dave, can you take this? I'll try to get to this soon, kinda backlogged at the moment. Sorry.
Re: [PATCH] sparc64: viohs: Remove VLA usage
On Wed, Sep 5, 2018 at 3:03 PM, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this > allocates a fixed size array for the maximum number of cookies and > adds a runtime sanity check. > > [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1 > rq...@mail.gmail.com > > Signed-off-by: Kees Cook Friendly ping. Dave, can you take this? Thanks! -Kees > --- > arch/sparc/kernel/viohs.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/sparc/kernel/viohs.c b/arch/sparc/kernel/viohs.c > index 635d67ffc9a3..7db5aabe9708 100644 > --- a/arch/sparc/kernel/viohs.c > +++ b/arch/sparc/kernel/viohs.c > @@ -180,11 +180,17 @@ static int send_dreg(struct vio_driver_state *vio) > struct vio_dring_register pkt; > char all[sizeof(struct vio_dring_register) + > (sizeof(struct ldc_trans_cookie) * > - dr->ncookies)]; > + VIO_MAX_RING_COOKIES)]; > } u; > + size_t bytes = sizeof(struct vio_dring_register) + > + (sizeof(struct ldc_trans_cookie) * > + dr->ncookies); > int i; > > - memset(, 0, sizeof(u)); > + if (WARN_ON(bytes > sizeof(u))) > + return -EINVAL; > + > + memset(, 0, bytes); > init_tag(, VIO_TYPE_CTRL, VIO_SUBTYPE_INFO, VIO_DRING_REG); > u.pkt.dring_ident = 0; > u.pkt.num_descr = dr->num_entries; > @@ -206,7 +212,7 @@ static int send_dreg(struct vio_driver_state *vio) >(unsigned long long) u.pkt.cookies[i].cookie_size); > } > > - return send_ctrl(vio, , sizeof(u)); > + return send_ctrl(vio, , bytes); > } > > static int send_rdx(struct vio_driver_state *vio) > -- > 2.17.1 > > > -- > Kees Cook > Pixel Security -- Kees Cook Pixel Security
Re: [PATCH] sparc64: viohs: Remove VLA usage
On Wed, Sep 5, 2018 at 3:03 PM, Kees Cook wrote: > In the quest to remove all stack VLA usage from the kernel[1], this > allocates a fixed size array for the maximum number of cookies and > adds a runtime sanity check. > > [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1 > rq...@mail.gmail.com > > Signed-off-by: Kees Cook Friendly ping. Dave, can you take this? Thanks! -Kees > --- > arch/sparc/kernel/viohs.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) > > diff --git a/arch/sparc/kernel/viohs.c b/arch/sparc/kernel/viohs.c > index 635d67ffc9a3..7db5aabe9708 100644 > --- a/arch/sparc/kernel/viohs.c > +++ b/arch/sparc/kernel/viohs.c > @@ -180,11 +180,17 @@ static int send_dreg(struct vio_driver_state *vio) > struct vio_dring_register pkt; > char all[sizeof(struct vio_dring_register) + > (sizeof(struct ldc_trans_cookie) * > - dr->ncookies)]; > + VIO_MAX_RING_COOKIES)]; > } u; > + size_t bytes = sizeof(struct vio_dring_register) + > + (sizeof(struct ldc_trans_cookie) * > + dr->ncookies); > int i; > > - memset(, 0, sizeof(u)); > + if (WARN_ON(bytes > sizeof(u))) > + return -EINVAL; > + > + memset(, 0, bytes); > init_tag(, VIO_TYPE_CTRL, VIO_SUBTYPE_INFO, VIO_DRING_REG); > u.pkt.dring_ident = 0; > u.pkt.num_descr = dr->num_entries; > @@ -206,7 +212,7 @@ static int send_dreg(struct vio_driver_state *vio) >(unsigned long long) u.pkt.cookies[i].cookie_size); > } > > - return send_ctrl(vio, , sizeof(u)); > + return send_ctrl(vio, , bytes); > } > > static int send_rdx(struct vio_driver_state *vio) > -- > 2.17.1 > > > -- > Kees Cook > Pixel Security -- Kees Cook Pixel Security
[PATCH 1/2] iio: magnetometer: Add DT support for PNI RM3100
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with MagI2C Interface.
PNI is not in the vendors' list, so this patch is also adding it.
Signed-off-by: Song Qiang
---
Changes in v2:
- Remove bus specific part in compatible string.
.../bindings/iio/magnetometer/pni,rm3100.txt | 20 +++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
new file mode 100644
index ..4677690fc5d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
@@ -0,0 +1,20 @@
+* PNI RM3100 3-axis magnetometer sensor
+
+Required properties:
+
+- compatible : should be "pni,rm3100"
+- reg : the I2C address or SPI chip select number of the sensor.
+
+Optional properties:
+
+- interrupts: data ready (DRDY) from the chip.
+ The interrupts can be triggered on rising edges.
+
+Example:
+
+rm3100: rm3100@20 {
+ compatible = "pni,rm3100";
+ reg = <0x20>;
+ interrupt-parent = <>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 41f0b97eb933..5bf3395fe9ae 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -288,6 +288,7 @@ pine64 Pine64
pixcir PIXCIR MICROELECTRONICS Co., Ltd
plathome Plat'Home Co., Ltd.
plda PLDA
+pni PNI
portwell Portwell Inc.
poslab Poslab Technology Co., Ltd.
powervrPowerVR (deprecated, use img)
--
2.17.1
[PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with MagI2C Interface.
Following functions are available:
- Single-shot measurement from
/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
- Triggerd buffer measurement.
- Both i2c and spi interface are supported.
- Both interrupt and polling measurement is supported, depands on if
the 'interrupts' in DT is declared.
Signed-off-by: Song Qiang
---
Changes in v2:
- Add scale channel.
- Add EXPORT_SYMBOL_GPL() to export regmap confuguration
structures.
- Add sampling frequency available attribute.
- Clean up headers and License declarations.
- Change axis number to 3.
- Remove bus specific part in compatible string.
- Remove le32_to_cpu().
- Check cycle count registers at *_probe().
- Format comments.
- Spell check.
- Change prefix from RM_* to RM3100_*.
- Check all error return paths.
- Add devm_add_action() to avoid race condition when remove.
MAINTAINERS| 7 +
drivers/iio/magnetometer/Kconfig | 29 ++
drivers/iio/magnetometer/Makefile | 4 +
drivers/iio/magnetometer/rm3100-core.c | 470 +
drivers/iio/magnetometer/rm3100-i2c.c | 58 +++
drivers/iio/magnetometer/rm3100-spi.c | 64
drivers/iio/magnetometer/rm3100.h | 73
7 files changed, 705 insertions(+)
create mode 100644 drivers/iio/magnetometer/rm3100-core.c
create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
create mode 100644 drivers/iio/magnetometer/rm3100.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 967ce8cdd1cc..14eeeb072403 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11393,6 +11393,13 @@ M: "Rafael J. Wysocki"
S: Maintained
F: drivers/pnp/
+PNI RM3100 IIO DRIVER
+M: Song Qiang
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/magnetometer/rm3100*
+F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
+
POSIX CLOCKS and TIMERS
M: Thomas Gleixner
L: linux-kernel@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index ed9d776d01af..f130b866a4fc 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
- hmc5843_core (core functions)
- hmc5843_spi (support for HMC5983)
+config SENSORS_RM3100
+ tristate
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+
+config SENSORS_RM3100_I2C
+ tristate "PNI RM3100 9-Axis Magnetometer (I2C)"
+ depends on I2C
+ select SENSORS_RM3100
+ select REGMAP_I2C
+ help
+ Say Y here to add support for the PNI RM3100 9-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-i2c.
+
+config SENSORS_RM3100_SPI
+ tristate "PNI RM3100 9-Axis Magnetometer (SPI)"
+ depends on SPI_MASTER
+ select SENSORS_RM3100
+ select REGMAP_SPI
+ help
+ Say Y here to add support for the PNI RM3100 9-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-spi.
+
endmenu
diff --git a/drivers/iio/magnetometer/Makefile
b/drivers/iio/magnetometer/Makefile
index 664b2f866472..ba1bc34b82fa 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -24,3 +24,7 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
obj-$(CONFIG_SENSORS_HMC5843) += hmc5843_core.o
obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
+
+obj-$(CONFIG_SENSORS_RM3100) += rm3100-core.o
+obj-$(CONFIG_SENSORS_RM3100_I2C) += rm3100-i2c.o
+obj-$(CONFIG_SENSORS_RM3100_SPI) += rm3100-spi.o
diff --git a/drivers/iio/magnetometer/rm3100-core.c
b/drivers/iio/magnetometer/rm3100-core.c
new file mode 100644
index ..5d28b53b7a04
--- /dev/null
+++ b/drivers/iio/magnetometer/rm3100-core.c
@@ -0,0 +1,470 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PNI RM3100 3-axis geomagnetic sensor driver core.
+ *
+ * Copyright (C) 2018 Song Qiang
+ *
+ * User Manual available at
+ *
[PATCH 1/2] iio: magnetometer: Add DT support for PNI RM3100
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with MagI2C Interface.
PNI is not in the vendors' list, so this patch is also adding it.
Signed-off-by: Song Qiang
---
Changes in v2:
- Remove bus specific part in compatible string.
.../bindings/iio/magnetometer/pni,rm3100.txt | 20 +++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
2 files changed, 21 insertions(+)
create mode 100644
Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
diff --git a/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
new file mode 100644
index ..4677690fc5d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
@@ -0,0 +1,20 @@
+* PNI RM3100 3-axis magnetometer sensor
+
+Required properties:
+
+- compatible : should be "pni,rm3100"
+- reg : the I2C address or SPI chip select number of the sensor.
+
+Optional properties:
+
+- interrupts: data ready (DRDY) from the chip.
+ The interrupts can be triggered on rising edges.
+
+Example:
+
+rm3100: rm3100@20 {
+ compatible = "pni,rm3100";
+ reg = <0x20>;
+ interrupt-parent = <>;
+ interrupts = <4 IRQ_TYPE_EDGE_RISING>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 41f0b97eb933..5bf3395fe9ae 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -288,6 +288,7 @@ pine64 Pine64
pixcir PIXCIR MICROELECTRONICS Co., Ltd
plathome Plat'Home Co., Ltd.
plda PLDA
+pni PNI
portwell Portwell Inc.
poslab Poslab Technology Co., Ltd.
powervrPowerVR (deprecated, use img)
--
2.17.1
[PATCH 2/2] iio: magnetometer: Add driver support for PNI RM3100
PNI RM3100 is a high resolution, large signal immunity magnetometer,
composed of 3 single sensors and a processing chip with MagI2C Interface.
Following functions are available:
- Single-shot measurement from
/sys/bus/iio/devices/iio:deviceX/in_magn_{axis}_raw
- Triggerd buffer measurement.
- Both i2c and spi interface are supported.
- Both interrupt and polling measurement is supported, depands on if
the 'interrupts' in DT is declared.
Signed-off-by: Song Qiang
---
Changes in v2:
- Add scale channel.
- Add EXPORT_SYMBOL_GPL() to export regmap confuguration
structures.
- Add sampling frequency available attribute.
- Clean up headers and License declarations.
- Change axis number to 3.
- Remove bus specific part in compatible string.
- Remove le32_to_cpu().
- Check cycle count registers at *_probe().
- Format comments.
- Spell check.
- Change prefix from RM_* to RM3100_*.
- Check all error return paths.
- Add devm_add_action() to avoid race condition when remove.
MAINTAINERS| 7 +
drivers/iio/magnetometer/Kconfig | 29 ++
drivers/iio/magnetometer/Makefile | 4 +
drivers/iio/magnetometer/rm3100-core.c | 470 +
drivers/iio/magnetometer/rm3100-i2c.c | 58 +++
drivers/iio/magnetometer/rm3100-spi.c | 64
drivers/iio/magnetometer/rm3100.h | 73
7 files changed, 705 insertions(+)
create mode 100644 drivers/iio/magnetometer/rm3100-core.c
create mode 100644 drivers/iio/magnetometer/rm3100-i2c.c
create mode 100644 drivers/iio/magnetometer/rm3100-spi.c
create mode 100644 drivers/iio/magnetometer/rm3100.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 967ce8cdd1cc..14eeeb072403 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11393,6 +11393,13 @@ M: "Rafael J. Wysocki"
S: Maintained
F: drivers/pnp/
+PNI RM3100 IIO DRIVER
+M: Song Qiang
+L: linux-...@vger.kernel.org
+S: Maintained
+F: drivers/iio/magnetometer/rm3100*
+F: Documentation/devicetree/bindings/iio/magnetometer/pni,rm3100.txt
+
POSIX CLOCKS and TIMERS
M: Thomas Gleixner
L: linux-kernel@vger.kernel.org
diff --git a/drivers/iio/magnetometer/Kconfig b/drivers/iio/magnetometer/Kconfig
index ed9d776d01af..f130b866a4fc 100644
--- a/drivers/iio/magnetometer/Kconfig
+++ b/drivers/iio/magnetometer/Kconfig
@@ -175,4 +175,33 @@ config SENSORS_HMC5843_SPI
- hmc5843_core (core functions)
- hmc5843_spi (support for HMC5983)
+config SENSORS_RM3100
+ tristate
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+
+config SENSORS_RM3100_I2C
+ tristate "PNI RM3100 9-Axis Magnetometer (I2C)"
+ depends on I2C
+ select SENSORS_RM3100
+ select REGMAP_I2C
+ help
+ Say Y here to add support for the PNI RM3100 9-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-i2c.
+
+config SENSORS_RM3100_SPI
+ tristate "PNI RM3100 9-Axis Magnetometer (SPI)"
+ depends on SPI_MASTER
+ select SENSORS_RM3100
+ select REGMAP_SPI
+ help
+ Say Y here to add support for the PNI RM3100 9-Axis Magnetometer.
+
+ This driver can also be compiled as a module.
+ To compile this driver as a module, choose M here: the module
+ will be called rm3100-spi.
+
endmenu
diff --git a/drivers/iio/magnetometer/Makefile
b/drivers/iio/magnetometer/Makefile
index 664b2f866472..ba1bc34b82fa 100644
--- a/drivers/iio/magnetometer/Makefile
+++ b/drivers/iio/magnetometer/Makefile
@@ -24,3 +24,7 @@ obj-$(CONFIG_IIO_ST_MAGN_SPI_3AXIS) += st_magn_spi.o
obj-$(CONFIG_SENSORS_HMC5843) += hmc5843_core.o
obj-$(CONFIG_SENSORS_HMC5843_I2C) += hmc5843_i2c.o
obj-$(CONFIG_SENSORS_HMC5843_SPI) += hmc5843_spi.o
+
+obj-$(CONFIG_SENSORS_RM3100) += rm3100-core.o
+obj-$(CONFIG_SENSORS_RM3100_I2C) += rm3100-i2c.o
+obj-$(CONFIG_SENSORS_RM3100_SPI) += rm3100-spi.o
diff --git a/drivers/iio/magnetometer/rm3100-core.c
b/drivers/iio/magnetometer/rm3100-core.c
new file mode 100644
index ..5d28b53b7a04
--- /dev/null
+++ b/drivers/iio/magnetometer/rm3100-core.c
@@ -0,0 +1,470 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * PNI RM3100 3-axis geomagnetic sensor driver core.
+ *
+ * Copyright (C) 2018 Song Qiang
+ *
+ * User Manual available at
+ *
Re: [PATCH 4.18 164/235] pinctrl: pinmux: Return selector to the pinctrl driver
On Mon, Sep 24, 2018 at 06:07:10PM -0500, Dan Rue wrote:
> On Mon, Sep 24, 2018 at 01:52:30PM +0200, Greg Kroah-Hartman wrote:
> > 4.18-stable review patch. If anyone has any objections, please let me know.
>
> I bisected a boot failure on an x15 (arm) board to this commit on
> 4.18.10-rc1. I'm also seeing issues on 4.14 and 4.18 with arm64 boards
> hikey and dragonboard 410c, but I have not investigated them yet (they
> could be unrelated).
>
> I see there are fixes to this commit that have not been backported.
> Namely:
>
> 823dd71f58eb ("pinctrl: ingenic: Fix group & function error checking")
> a203728ac6bb ("pinctrl: core: Return selector to the pinctrl driver")
>
> However, I tried adding those two in but I still see the boot failure on
> x15.
Dropping 9c5cd7b6ca4e ("pinctrl: pinmux: Return selector to the pinctrl
driver") does appear to fix the boot issues I'm seeing on x15 and hikey.
Dan
>
> Dan
>
> >
> > --
> >
> > From: Tony Lindgren
> >
> > [ Upstream commit f913cfce4ee49a3382a9ff95696f49a46e56e974 ]
> >
> > We must return the selector from pinmux_generic_add_function() so
> > pin controller device drivers can remove the right group if needed
> > for deferred probe for example. And we now must make sure that a
> > proper name is passed so we can use it to check if the entry already
> > exists.
> >
> > Note that fixes are also needed for the pin controller drivers to
> > use the selector value.
> >
> > Fixes: a76edc89b100 ("pinctrl: core: Add generic pinctrl functions for
> > managing groups")
> > Reported-by: H. Nikolaus Schaller
> > Cc: Christ van Willegen
> > Cc: Haojian Zhuang
> > Cc: Jacopo Mondi
> > Cc: Paul Cercueil
> > Cc: Sean Wang
> > Signed-off-by: Tony Lindgren
> > Tested-By: H. Nikolaus Schaller
> > Reviewed-by: Andy Shevchenko
> > Signed-off-by: Linus Walleij
> > Signed-off-by: Sasha Levin
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > drivers/pinctrl/pinmux.c | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > --- a/drivers/pinctrl/pinmux.c
> > +++ b/drivers/pinctrl/pinmux.c
> > @@ -308,7 +308,6 @@ static int pinmux_func_name_to_selector(
> > selector++;
> > }
> >
> > - dev_err(pctldev->dev, "function '%s' not supported\n", function);
> > return -EINVAL;
> > }
> >
> > @@ -775,6 +774,16 @@ int pinmux_generic_add_function(struct p
> > void *data)
> > {
> > struct function_desc *function;
> > + int selector;
> > +
> > + if (!name)
> > + return -EINVAL;
> > +
> > + selector = pinmux_func_name_to_selector(pctldev, name);
> > + if (selector >= 0)
> > + return selector;
> > +
> > + selector = pctldev->num_functions;
> >
> > function = devm_kzalloc(pctldev->dev, sizeof(*function), GFP_KERNEL);
> > if (!function)
> > @@ -785,12 +794,11 @@ int pinmux_generic_add_function(struct p
> > function->num_group_names = num_groups;
> > function->data = data;
> >
> > - radix_tree_insert(>pin_function_tree, pctldev->num_functions,
> > - function);
> > + radix_tree_insert(>pin_function_tree, selector, function);
> >
> > pctldev->num_functions++;
> >
> > - return 0;
> > + return selector;
> > }
> > EXPORT_SYMBOL_GPL(pinmux_generic_add_function);
> >
> >
> >
Re: [PATCH 4.18 164/235] pinctrl: pinmux: Return selector to the pinctrl driver
On Mon, Sep 24, 2018 at 06:07:10PM -0500, Dan Rue wrote:
> On Mon, Sep 24, 2018 at 01:52:30PM +0200, Greg Kroah-Hartman wrote:
> > 4.18-stable review patch. If anyone has any objections, please let me know.
>
> I bisected a boot failure on an x15 (arm) board to this commit on
> 4.18.10-rc1. I'm also seeing issues on 4.14 and 4.18 with arm64 boards
> hikey and dragonboard 410c, but I have not investigated them yet (they
> could be unrelated).
>
> I see there are fixes to this commit that have not been backported.
> Namely:
>
> 823dd71f58eb ("pinctrl: ingenic: Fix group & function error checking")
> a203728ac6bb ("pinctrl: core: Return selector to the pinctrl driver")
>
> However, I tried adding those two in but I still see the boot failure on
> x15.
Dropping 9c5cd7b6ca4e ("pinctrl: pinmux: Return selector to the pinctrl
driver") does appear to fix the boot issues I'm seeing on x15 and hikey.
Dan
>
> Dan
>
> >
> > --
> >
> > From: Tony Lindgren
> >
> > [ Upstream commit f913cfce4ee49a3382a9ff95696f49a46e56e974 ]
> >
> > We must return the selector from pinmux_generic_add_function() so
> > pin controller device drivers can remove the right group if needed
> > for deferred probe for example. And we now must make sure that a
> > proper name is passed so we can use it to check if the entry already
> > exists.
> >
> > Note that fixes are also needed for the pin controller drivers to
> > use the selector value.
> >
> > Fixes: a76edc89b100 ("pinctrl: core: Add generic pinctrl functions for
> > managing groups")
> > Reported-by: H. Nikolaus Schaller
> > Cc: Christ van Willegen
> > Cc: Haojian Zhuang
> > Cc: Jacopo Mondi
> > Cc: Paul Cercueil
> > Cc: Sean Wang
> > Signed-off-by: Tony Lindgren
> > Tested-By: H. Nikolaus Schaller
> > Reviewed-by: Andy Shevchenko
> > Signed-off-by: Linus Walleij
> > Signed-off-by: Sasha Levin
> > Signed-off-by: Greg Kroah-Hartman
> > ---
> > drivers/pinctrl/pinmux.c | 16
> > 1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > --- a/drivers/pinctrl/pinmux.c
> > +++ b/drivers/pinctrl/pinmux.c
> > @@ -308,7 +308,6 @@ static int pinmux_func_name_to_selector(
> > selector++;
> > }
> >
> > - dev_err(pctldev->dev, "function '%s' not supported\n", function);
> > return -EINVAL;
> > }
> >
> > @@ -775,6 +774,16 @@ int pinmux_generic_add_function(struct p
> > void *data)
> > {
> > struct function_desc *function;
> > + int selector;
> > +
> > + if (!name)
> > + return -EINVAL;
> > +
> > + selector = pinmux_func_name_to_selector(pctldev, name);
> > + if (selector >= 0)
> > + return selector;
> > +
> > + selector = pctldev->num_functions;
> >
> > function = devm_kzalloc(pctldev->dev, sizeof(*function), GFP_KERNEL);
> > if (!function)
> > @@ -785,12 +794,11 @@ int pinmux_generic_add_function(struct p
> > function->num_group_names = num_groups;
> > function->data = data;
> >
> > - radix_tree_insert(>pin_function_tree, pctldev->num_functions,
> > - function);
> > + radix_tree_insert(>pin_function_tree, selector, function);
> >
> > pctldev->num_functions++;
> >
> > - return 0;
> > + return selector;
> > }
> > EXPORT_SYMBOL_GPL(pinmux_generic_add_function);
> >
> >
> >
Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion
On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote:
> On Mon, Sep 24, 2018 at 3:27 PM Nathan Chancellor
> wrote:
> >
> > On Mon, Sep 24, 2018 at 03:24:36PM -0700, Nick Desaulniers wrote:
> > > On Mon, Sep 24, 2018 at 12:57 PM Nathan Chancellor
> > > wrote:
> > > >
> > > > Clang warns when one enumerated type is implicitly converted to another.
> > > >
> > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit conversion
> > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
> > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > qp_init_attr.init_attr.create_flags =
> > > > MLX4_IB_SRIOV_TUNNEL_QP;
> > > > ~
> > > > ^~~
> > > >
> > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit conversion
> > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
> > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > qp_init_attr.init_attr.create_flags = MLX4_IB_SRIOV_SQP;
> > > > ~ ^
> > > >
> > > > The type mlx4_ib_qp_flags explicitly provides supplemental values to the
> > > > type ib_qp_create_flags. Make that clear to Clang by changing the
> > > > create_flags type to u32.
> > > >
> > > > Reported-by: Nick Desaulniers
> > > > Signed-off-by: Nathan Chancellor
> > > > include/rdma/ib_verbs.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> > > > index e463d3007a35..f6f4d9e3c8ed 100644
> > > > +++ b/include/rdma/ib_verbs.h
> > > > @@ -1149,7 +1149,7 @@ struct ib_qp_init_attr {
> > > > struct ib_qp_capcap;
> > > > enum ib_sig_typesq_sig_type;
> > > > enum ib_qp_type qp_type;
> > > > - enum ib_qp_create_flags create_flags;
> > > > + u32 create_flags;
> > >
> > > I think it might be better to just have explicit casts at the
> > > assignment. What do the maintainers think?
> > >
> >
> > That's fine with me, I tend to explicitly cast if it is only one
> > location but it certainly makes sense in this case as well. I'll
> > wait for the maintainers to weigh in before sending a v2.
>
> Yeah, I mean my opinion on this might seem arbitrary, but based on the
> pattern and the comment in ib_qp_create_flags, those enum values are
> reserved to be "subclassed" in a sense, so they should always be in
> sync or this code will have bigger problems.
One should not use an 'enum' type name for bitfield storage, as once
you start or'ing things together the values no longer fall on the
enum. Some compilers and tools even give warnings in this case, ie
enum x foo = X_A | X_B;
Is an assignment from 'int' to an 'enum x' with an implicit cast.
For this reason, usually bitfield enum declarations should be
anonymous.
Jason
Re: [PATCH] IB/mlx4: Avoid implicit enumerated type conversion
On Mon, Sep 24, 2018 at 03:29:38PM -0700, Nick Desaulniers wrote:
> On Mon, Sep 24, 2018 at 3:27 PM Nathan Chancellor
> wrote:
> >
> > On Mon, Sep 24, 2018 at 03:24:36PM -0700, Nick Desaulniers wrote:
> > > On Mon, Sep 24, 2018 at 12:57 PM Nathan Chancellor
> > > wrote:
> > > >
> > > > Clang warns when one enumerated type is implicitly converted to another.
> > > >
> > > > drivers/infiniband/hw/mlx4/mad.c:1811:41: warning: implicit conversion
> > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
> > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > qp_init_attr.init_attr.create_flags =
> > > > MLX4_IB_SRIOV_TUNNEL_QP;
> > > > ~
> > > > ^~~
> > > >
> > > > drivers/infiniband/hw/mlx4/mad.c:1819:41: warning: implicit conversion
> > > > from enumeration type 'enum mlx4_ib_qp_flags' to different enumeration
> > > > type 'enum ib_qp_create_flags' [-Wenum-conversion]
> > > > qp_init_attr.init_attr.create_flags = MLX4_IB_SRIOV_SQP;
> > > > ~ ^
> > > >
> > > > The type mlx4_ib_qp_flags explicitly provides supplemental values to the
> > > > type ib_qp_create_flags. Make that clear to Clang by changing the
> > > > create_flags type to u32.
> > > >
> > > > Reported-by: Nick Desaulniers
> > > > Signed-off-by: Nathan Chancellor
> > > > include/rdma/ib_verbs.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/include/rdma/ib_verbs.h b/include/rdma/ib_verbs.h
> > > > index e463d3007a35..f6f4d9e3c8ed 100644
> > > > +++ b/include/rdma/ib_verbs.h
> > > > @@ -1149,7 +1149,7 @@ struct ib_qp_init_attr {
> > > > struct ib_qp_capcap;
> > > > enum ib_sig_typesq_sig_type;
> > > > enum ib_qp_type qp_type;
> > > > - enum ib_qp_create_flags create_flags;
> > > > + u32 create_flags;
> > >
> > > I think it might be better to just have explicit casts at the
> > > assignment. What do the maintainers think?
> > >
> >
> > That's fine with me, I tend to explicitly cast if it is only one
> > location but it certainly makes sense in this case as well. I'll
> > wait for the maintainers to weigh in before sending a v2.
>
> Yeah, I mean my opinion on this might seem arbitrary, but based on the
> pattern and the comment in ib_qp_create_flags, those enum values are
> reserved to be "subclassed" in a sense, so they should always be in
> sync or this code will have bigger problems.
One should not use an 'enum' type name for bitfield storage, as once
you start or'ing things together the values no longer fall on the
enum. Some compilers and tools even give warnings in this case, ie
enum x foo = X_A | X_B;
Is an assignment from 'int' to an 'enum x' with an implicit cast.
For this reason, usually bitfield enum declarations should be
anonymous.
Jason
Re: [RFC PATCH 0/9] Improve zone lock scalability using Daniel Jordan's list work
On Fri, Sep 21, 2018 at 10:45:36AM -0700, Daniel Jordan wrote: > On Tue, Sep 11, 2018 at 01:36:07PM +0800, Aaron Lu wrote: > > Daniel Jordan and others proposed an innovative technique to make > > multiple threads concurrently use list_del() at any position of the > > list and list_add() at head position of the list without taking a lock > > in this year's MM summit[0]. > > > > People think this technique may be useful to improve zone lock > > scalability so here is my try. > > Nice, this uses the smp_list_* functions well in spite of the limitations you > encountered with them here. > > > Performance wise on 56 cores/112 threads Intel Skylake 2 sockets server > > using will-it-scale/page_fault1 process mode(higher is better): > > > > kernelperformance zone lock contention > > patch1 9219349 76.99% > > patch7 2461133 -73.3% 54.46%(another 34.66% on smp_list_add()) > > patch811712766 +27.0% 68.14% > > patch911386980 +23.5% 67.18% > > Is "zone lock contention" the percentage that readers and writers combined > spent waiting? I'm curious to see read and write wait time broken out, since > it seems there are writers (very likely on the allocation side) spoiling the > parallelism we get with the read lock. lock contention is combined, read side consumes about 31% while write side consumes 35%. Write side definitely is blocking read side. I also tried not taking lock in read mode on free path to avoid free path blocking on allocation path, but that caused other unplesant consequences for allocation path, namely the free_list head->next can be NULL when allocating pages due to free path can be adding pages to the list using smp_list_add/splice so I had to use free_list head->prev instead to fetch pages on allocation path. Also, the fetched page can be merged in the mean time on free path so need to confirm if it is really usable, etc. This complicated allocation path and didn't deliver good results so I gave up this idea. > If the contention is from allocation, I wonder whether it's feasible to make > that path use SMP list functions. Something like smp_list_cut_position > combined with using page clusters from [*] to cut off a chunk of list. Many > details to keep in mind there, though, like having to unset PageBuddy in that > list chunk when other tasks can be concurrently merging pages that are part of > it. As you put here, the PageBuddy flag is a problem. If I cut off a batch of pages from free_list and then dropping the lock, these pages will have PageBuddy flag set and free path can attempt a merge with any of these pages and cause problems. PageBuddy flag can not be cleared with lock held since that would require accessing 'struct page's for these pages and it is the most time consuming part among all operations that happened on allocation path under zone lock. This is doable in your referenced no_merge+cluster_alloc approach because we skipped merge most of the time. And when merge really needs to happen like in compaction, cluser_alloc will be disabled. > Or maybe what's needed is a more scalable data structure than an array of > lists, since contention on the heads seems to be the limiting factor. A > simple > list that keeps the pages in most-recently-used order (except when adding to > the list tail) is good for cache warmth, but I wonder how helpful that is when > all CPUs can allocate from the front. Having multiple places to put pages of > a > given order/mt would ease the contention. Agree. > > Though lock contention reduced a lot for patch7, the performance dropped > > considerably due to severe cache bouncing on free list head among > > multiple threads doing page free at the same time, because every page free > > will need to add the page to the free list head. > > Could be beneficial to take an MCS-style approach in smp_list_splice/add so > that multiple waiters aren't bouncing the same cacheline around. This is > something I'm planning to try on lru_lock. That's a good idea. If that is done, we can at least parallelise free path and gain something by not paying the penalty of cache bouncing on list head. > > Daniel > > [*] https://lkml.kernel.org/r/20180509085450.3524-1-aaron...@intel.com And thanks a lot for the comments!
Re: [RFC PATCH 0/9] Improve zone lock scalability using Daniel Jordan's list work
On Fri, Sep 21, 2018 at 10:45:36AM -0700, Daniel Jordan wrote: > On Tue, Sep 11, 2018 at 01:36:07PM +0800, Aaron Lu wrote: > > Daniel Jordan and others proposed an innovative technique to make > > multiple threads concurrently use list_del() at any position of the > > list and list_add() at head position of the list without taking a lock > > in this year's MM summit[0]. > > > > People think this technique may be useful to improve zone lock > > scalability so here is my try. > > Nice, this uses the smp_list_* functions well in spite of the limitations you > encountered with them here. > > > Performance wise on 56 cores/112 threads Intel Skylake 2 sockets server > > using will-it-scale/page_fault1 process mode(higher is better): > > > > kernelperformance zone lock contention > > patch1 9219349 76.99% > > patch7 2461133 -73.3% 54.46%(another 34.66% on smp_list_add()) > > patch811712766 +27.0% 68.14% > > patch911386980 +23.5% 67.18% > > Is "zone lock contention" the percentage that readers and writers combined > spent waiting? I'm curious to see read and write wait time broken out, since > it seems there are writers (very likely on the allocation side) spoiling the > parallelism we get with the read lock. lock contention is combined, read side consumes about 31% while write side consumes 35%. Write side definitely is blocking read side. I also tried not taking lock in read mode on free path to avoid free path blocking on allocation path, but that caused other unplesant consequences for allocation path, namely the free_list head->next can be NULL when allocating pages due to free path can be adding pages to the list using smp_list_add/splice so I had to use free_list head->prev instead to fetch pages on allocation path. Also, the fetched page can be merged in the mean time on free path so need to confirm if it is really usable, etc. This complicated allocation path and didn't deliver good results so I gave up this idea. > If the contention is from allocation, I wonder whether it's feasible to make > that path use SMP list functions. Something like smp_list_cut_position > combined with using page clusters from [*] to cut off a chunk of list. Many > details to keep in mind there, though, like having to unset PageBuddy in that > list chunk when other tasks can be concurrently merging pages that are part of > it. As you put here, the PageBuddy flag is a problem. If I cut off a batch of pages from free_list and then dropping the lock, these pages will have PageBuddy flag set and free path can attempt a merge with any of these pages and cause problems. PageBuddy flag can not be cleared with lock held since that would require accessing 'struct page's for these pages and it is the most time consuming part among all operations that happened on allocation path under zone lock. This is doable in your referenced no_merge+cluster_alloc approach because we skipped merge most of the time. And when merge really needs to happen like in compaction, cluser_alloc will be disabled. > Or maybe what's needed is a more scalable data structure than an array of > lists, since contention on the heads seems to be the limiting factor. A > simple > list that keeps the pages in most-recently-used order (except when adding to > the list tail) is good for cache warmth, but I wonder how helpful that is when > all CPUs can allocate from the front. Having multiple places to put pages of > a > given order/mt would ease the contention. Agree. > > Though lock contention reduced a lot for patch7, the performance dropped > > considerably due to severe cache bouncing on free list head among > > multiple threads doing page free at the same time, because every page free > > will need to add the page to the free list head. > > Could be beneficial to take an MCS-style approach in smp_list_splice/add so > that multiple waiters aren't bouncing the same cacheline around. This is > something I'm planning to try on lru_lock. That's a good idea. If that is done, we can at least parallelise free path and gain something by not paying the penalty of cache bouncing on list head. > > Daniel > > [*] https://lkml.kernel.org/r/20180509085450.3524-1-aaron...@intel.com And thanks a lot for the comments!
Re: [PATCH 1/5] RISC-V: Build tishift only on 64-bit
Christoph Hellwig 於 2018年9月21日 週五 下午2:58寫道： > > On Tue, Sep 18, 2018 at 05:19:13PM +0800, Zong Li wrote: > > Only RV64 supports 128 integer size. > > > > Signed-off-by: Zong Li > > This looks fine. Just curious, what do we even need 128-bit integers > for on riscv64? Did you see any issues if you drop it entirely? You can refer to this issue, but I didn't try it. https://github.com/riscv/riscv-linux/issues/136
Re: [PATCH 1/5] RISC-V: Build tishift only on 64-bit
Christoph Hellwig 於 2018年9月21日 週五 下午2:58寫道： > > On Tue, Sep 18, 2018 at 05:19:13PM +0800, Zong Li wrote: > > Only RV64 supports 128 integer size. > > > > Signed-off-by: Zong Li > > This looks fine. Just curious, what do we even need 128-bit integers > for on riscv64? Did you see any issues if you drop it entirely? You can refer to this issue, but I didn't try it. https://github.com/riscv/riscv-linux/issues/136
Re: Code of Conduct: Let's revamp it.
In your employment contract there exists a provision where you sign over your rights to any and all intellectual property, patents, copyrights developed during your term of employment. Said clause makes it clear that what you've furnished is a work-for-hire and owned by the company or the entity you have contracted with. It should be clear why that is not the case with regards to kernel contributions by third parties. Unlike the FSF etc, Linus never required nor sought copyright assignments: thus you still own your code. You were not paid valuable consideration by the licensees for the code. There exists no interest to bind your hand. You never even suggested to said licensees that you would forfeit your right to revoke. Furthermore, they were incapable of relying on said in-existent utterances. You may revoke at your pleasure. And they shall be bound by the will of your countenance. On 2018-09-24 19:45, Bernd Petrovitsch wrote: BTW you cannot do that at your workplace either because in all sane software development companies you cease all (transferable) rights of your written to the company paying you (and the rest is usually not enough to get anything revoked). I don't see why that should be any different with GPLv2 patches for the Kernel sent to public mailinglists with the intent of inclusion. Please get back to the issue and circumstances at hand and do not try to divert people with "not intended for the public" or "semi-public" or any other off-topic stuff which is clearly not the case here. Or - even better - shut up, unsubscribe and go away, thank you. MfG, Bernd, NAL but I talked to a lot of them;-) PS: Sorry for troll feeding:-(
Re: Code of Conduct: Let's revamp it.
In your employment contract there exists a provision where you sign over your rights to any and all intellectual property, patents, copyrights developed during your term of employment. Said clause makes it clear that what you've furnished is a work-for-hire and owned by the company or the entity you have contracted with. It should be clear why that is not the case with regards to kernel contributions by third parties. Unlike the FSF etc, Linus never required nor sought copyright assignments: thus you still own your code. You were not paid valuable consideration by the licensees for the code. There exists no interest to bind your hand. You never even suggested to said licensees that you would forfeit your right to revoke. Furthermore, they were incapable of relying on said in-existent utterances. You may revoke at your pleasure. And they shall be bound by the will of your countenance. On 2018-09-24 19:45, Bernd Petrovitsch wrote: BTW you cannot do that at your workplace either because in all sane software development companies you cease all (transferable) rights of your written to the company paying you (and the rest is usually not enough to get anything revoked). I don't see why that should be any different with GPLv2 patches for the Kernel sent to public mailinglists with the intent of inclusion. Please get back to the issue and circumstances at hand and do not try to divert people with "not intended for the public" or "semi-public" or any other off-topic stuff which is clearly not the case here. Or - even better - shut up, unsubscribe and go away, thank you. MfG, Bernd, NAL but I talked to a lot of them;-) PS: Sorry for troll feeding:-(
[PATCH v4 2/3] spi: mediatek: add spi slave for Mediatek MT2712
This patch adds basic spi slave for MT2712.
Signed-off-by: Leilk Liu
---
drivers/spi/Kconfig| 10 +
drivers/spi/Makefile |1 +
drivers/spi/spi-slave-mt27xx.c | 554
3 files changed, 565 insertions(+)
create mode 100644 drivers/spi/spi-slave-mt27xx.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 671d078..60b13c6 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -596,6 +596,16 @@ config SPI_SIRF
help
SPI driver for CSR SiRFprimaII SoCs
+config SPI_SLAVE_MT27XX
+ tristate "MediaTek SPI slave device"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on SPI_SLAVE
+ help
+ This selects the MediaTek(R) SPI slave device driver.
+ If you want to use MediaTek(R) SPI slave interface,
+ say Y or M here.If you are not sure, say N.
+ SPI slave drivers for Mediatek MT27XX series ARM SoCs.
+
config SPI_SPRD_ADI
tristate "Spreadtrum ADI controller"
depends on ARCH_SPRD || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index a90d559..3b469fa 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
+obj-$(CONFIG_SPI_SLAVE_MT27XX) += spi-slave-mt27xx.o
obj-$(CONFIG_SPI_SPRD_ADI) += spi-sprd-adi.o
obj-$(CONFIG_SPI_STM32)+= spi-stm32.o
obj-$(CONFIG_SPI_ST_SSC4) += spi-st-ssc4.o
diff --git a/drivers/spi/spi-slave-mt27xx.c b/drivers/spi/spi-slave-mt27xx.c
new file mode 100644
index 000..d1075433
--- /dev/null
+++ b/drivers/spi/spi-slave-mt27xx.c
@@ -0,0 +1,554 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2018 MediaTek Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SPIS_IRQ_EN_REG0x0
+#define SPIS_IRQ_CLR_REG 0x4
+#define SPIS_IRQ_ST_REG0x8
+#define SPIS_IRQ_MASK_REG 0xc
+#define SPIS_CFG_REG 0x10
+#define SPIS_RX_DATA_REG 0x14
+#define SPIS_TX_DATA_REG 0x18
+#define SPIS_RX_DST_REG0x1c
+#define SPIS_TX_SRC_REG0x20
+#define SPIS_DMA_CFG_REG 0x30
+#define SPIS_SOFT_RST_REG 0x40
+
+/* SPIS_IRQ_EN_REG */
+#define DMA_DONE_ENBIT(7)
+#define DATA_DONE_EN BIT(2)
+#define RSTA_DONE_EN BIT(1)
+#define CMD_INVALID_EN BIT(0)
+
+/* SPIS_IRQ_ST_REG */
+#define DMA_DONE_STBIT(7)
+#define DATA_DONE_ST BIT(2)
+#define RSTA_DONE_ST BIT(1)
+#define CMD_INVALID_ST BIT(0)
+
+/* SPIS_IRQ_MASK_REG */
+#define DMA_DONE_MASK BIT(7)
+#define DATA_DONE_MASK BIT(2)
+#define RSTA_DONE_MASK BIT(1)
+#define CMD_INVALID_MASK BIT(0)
+
+/* SPIS_CFG_REG */
+#define SPIS_TX_ENDIAN BIT(7)
+#define SPIS_RX_ENDIAN BIT(6)
+#define SPIS_TXMSBFBIT(5)
+#define SPIS_RXMSBFBIT(4)
+#define SPIS_CPHA BIT(3)
+#define SPIS_CPOL BIT(2)
+#define SPIS_TX_EN BIT(1)
+#define SPIS_RX_EN BIT(0)
+
+/* SPIS_DMA_CFG_REG */
+#define TX_DMA_TRIG_EN BIT(31)
+#define TX_DMA_EN BIT(30)
+#define RX_DMA_EN BIT(29)
+#define TX_DMA_LEN 0xf
+
+/* SPIS_SOFT_RST_REG */
+#define SPIS_DMA_ADDR_EN BIT(1)
+#define SPIS_SOFT_RST BIT(0)
+
+#define MTK_SPI_SLAVE_MAX_FIFO_SIZE 512U
+
+struct mtk_spi_slave {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *spi_clk;
+ struct completion xfer_done;
+ struct spi_transfer *cur_transfer;
+ bool slave_aborted;
+};
+
+static const struct of_device_id mtk_spi_slave_of_match[] = {
+ { .compatible = "mediatek,mt2712-spi-slave", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mtk_spi_slave_of_match);
+
+static void mtk_spi_slave_disable_dma(struct mtk_spi_slave *mdata)
+{
+ u32 reg_val;
+
+ reg_val = readl(mdata->base + SPIS_DMA_CFG_REG);
+ reg_val &= ~RX_DMA_EN;
+ reg_val &= ~TX_DMA_EN;
+ writel(reg_val, mdata->base + SPIS_DMA_CFG_REG);
+}
+
+static void mtk_spi_slave_disable_xfer(struct mtk_spi_slave *mdata)
+{
+ u32 reg_val;
+
+ reg_val = readl(mdata->base + SPIS_CFG_REG);
+ reg_val &= ~SPIS_TX_EN;
+ reg_val &= ~SPIS_RX_EN;
+ writel(reg_val, mdata->base + SPIS_CFG_REG);
+}
+
+static int mtk_spi_slave_wait_for_completion(struct mtk_spi_slave *mdata)
+{
+ if (wait_for_completion_interruptible(>xfer_done) ||
+ mdata->slave_aborted) {
+ dev_err(mdata->dev, "interrupted\n");
+ return -EINTR;
+ }
+
+ return 0;
+}
+
+static int
[PATCH v4 0/3] Add Mediatek SPI slave driver
>From 7f2423debd91771a1d3a5ca02cd3990f1417bcb8 Mon Sep 17 00:00:00 2001 From: Leilk Liu Date: Tue, 25 Sep 2018 10:11:44 +0800 Subject: Subject: [PATCH v4 0/3] Add Mediatek SPI slave driver v4: 1. Fix Mark Brown review comment about kconfig & driver. v3: 1. Fix Rob Herring review comment about bindings. 2. remove unused variables in driver. v2: 1. Fix Sean Wang review comment. 2. remove unused register and offset define. 3. update bindings file with assigned-clocks and assigned-clocks-parents. v1: This series are based on 4.19-rc1 and provide three patches to add mediatek spi slave driver. Leilk Liu (3): spi: mediatek: add bindings for Mediatek MT2712 soc platform spi: mediatek: add spi slave for Mediatek MT2712 arm64: dts: Add spi slave dts .../devicetree/bindings/spi/spi-slave-mt27xx.txt | 32 ++ arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 11 + drivers/spi/Kconfig| 10 + drivers/spi/Makefile | 1 + drivers/spi/spi-slave-mt27xx.c | 554 + 5 files changed, 608 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt create mode 100644 drivers/spi/spi-slave-mt27xx.c -- 1.9.1
[PATCH v4 2/3] spi: mediatek: add spi slave for Mediatek MT2712
This patch adds basic spi slave for MT2712.
Signed-off-by: Leilk Liu
---
drivers/spi/Kconfig| 10 +
drivers/spi/Makefile |1 +
drivers/spi/spi-slave-mt27xx.c | 554
3 files changed, 565 insertions(+)
create mode 100644 drivers/spi/spi-slave-mt27xx.c
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index 671d078..60b13c6 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -596,6 +596,16 @@ config SPI_SIRF
help
SPI driver for CSR SiRFprimaII SoCs
+config SPI_SLAVE_MT27XX
+ tristate "MediaTek SPI slave device"
+ depends on ARCH_MEDIATEK || COMPILE_TEST
+ depends on SPI_SLAVE
+ help
+ This selects the MediaTek(R) SPI slave device driver.
+ If you want to use MediaTek(R) SPI slave interface,
+ say Y or M here.If you are not sure, say N.
+ SPI slave drivers for Mediatek MT27XX series ARM SoCs.
+
config SPI_SPRD_ADI
tristate "Spreadtrum ADI controller"
depends on ARCH_SPRD || COMPILE_TEST
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index a90d559..3b469fa 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -88,6 +88,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
+obj-$(CONFIG_SPI_SLAVE_MT27XX) += spi-slave-mt27xx.o
obj-$(CONFIG_SPI_SPRD_ADI) += spi-sprd-adi.o
obj-$(CONFIG_SPI_STM32)+= spi-stm32.o
obj-$(CONFIG_SPI_ST_SSC4) += spi-st-ssc4.o
diff --git a/drivers/spi/spi-slave-mt27xx.c b/drivers/spi/spi-slave-mt27xx.c
new file mode 100644
index 000..d1075433
--- /dev/null
+++ b/drivers/spi/spi-slave-mt27xx.c
@@ -0,0 +1,554 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (c) 2018 MediaTek Inc.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SPIS_IRQ_EN_REG0x0
+#define SPIS_IRQ_CLR_REG 0x4
+#define SPIS_IRQ_ST_REG0x8
+#define SPIS_IRQ_MASK_REG 0xc
+#define SPIS_CFG_REG 0x10
+#define SPIS_RX_DATA_REG 0x14
+#define SPIS_TX_DATA_REG 0x18
+#define SPIS_RX_DST_REG0x1c
+#define SPIS_TX_SRC_REG0x20
+#define SPIS_DMA_CFG_REG 0x30
+#define SPIS_SOFT_RST_REG 0x40
+
+/* SPIS_IRQ_EN_REG */
+#define DMA_DONE_ENBIT(7)
+#define DATA_DONE_EN BIT(2)
+#define RSTA_DONE_EN BIT(1)
+#define CMD_INVALID_EN BIT(0)
+
+/* SPIS_IRQ_ST_REG */
+#define DMA_DONE_STBIT(7)
+#define DATA_DONE_ST BIT(2)
+#define RSTA_DONE_ST BIT(1)
+#define CMD_INVALID_ST BIT(0)
+
+/* SPIS_IRQ_MASK_REG */
+#define DMA_DONE_MASK BIT(7)
+#define DATA_DONE_MASK BIT(2)
+#define RSTA_DONE_MASK BIT(1)
+#define CMD_INVALID_MASK BIT(0)
+
+/* SPIS_CFG_REG */
+#define SPIS_TX_ENDIAN BIT(7)
+#define SPIS_RX_ENDIAN BIT(6)
+#define SPIS_TXMSBFBIT(5)
+#define SPIS_RXMSBFBIT(4)
+#define SPIS_CPHA BIT(3)
+#define SPIS_CPOL BIT(2)
+#define SPIS_TX_EN BIT(1)
+#define SPIS_RX_EN BIT(0)
+
+/* SPIS_DMA_CFG_REG */
+#define TX_DMA_TRIG_EN BIT(31)
+#define TX_DMA_EN BIT(30)
+#define RX_DMA_EN BIT(29)
+#define TX_DMA_LEN 0xf
+
+/* SPIS_SOFT_RST_REG */
+#define SPIS_DMA_ADDR_EN BIT(1)
+#define SPIS_SOFT_RST BIT(0)
+
+#define MTK_SPI_SLAVE_MAX_FIFO_SIZE 512U
+
+struct mtk_spi_slave {
+ struct device *dev;
+ void __iomem *base;
+ struct clk *spi_clk;
+ struct completion xfer_done;
+ struct spi_transfer *cur_transfer;
+ bool slave_aborted;
+};
+
+static const struct of_device_id mtk_spi_slave_of_match[] = {
+ { .compatible = "mediatek,mt2712-spi-slave", },
+ {}
+};
+MODULE_DEVICE_TABLE(of, mtk_spi_slave_of_match);
+
+static void mtk_spi_slave_disable_dma(struct mtk_spi_slave *mdata)
+{
+ u32 reg_val;
+
+ reg_val = readl(mdata->base + SPIS_DMA_CFG_REG);
+ reg_val &= ~RX_DMA_EN;
+ reg_val &= ~TX_DMA_EN;
+ writel(reg_val, mdata->base + SPIS_DMA_CFG_REG);
+}
+
+static void mtk_spi_slave_disable_xfer(struct mtk_spi_slave *mdata)
+{
+ u32 reg_val;
+
+ reg_val = readl(mdata->base + SPIS_CFG_REG);
+ reg_val &= ~SPIS_TX_EN;
+ reg_val &= ~SPIS_RX_EN;
+ writel(reg_val, mdata->base + SPIS_CFG_REG);
+}
+
+static int mtk_spi_slave_wait_for_completion(struct mtk_spi_slave *mdata)
+{
+ if (wait_for_completion_interruptible(>xfer_done) ||
+ mdata->slave_aborted) {
+ dev_err(mdata->dev, "interrupted\n");
+ return -EINTR;
+ }
+
+ return 0;
+}
+
+static int
[PATCH v4 0/3] Add Mediatek SPI slave driver
>From 7f2423debd91771a1d3a5ca02cd3990f1417bcb8 Mon Sep 17 00:00:00 2001 From: Leilk Liu Date: Tue, 25 Sep 2018 10:11:44 +0800 Subject: Subject: [PATCH v4 0/3] Add Mediatek SPI slave driver v4: 1. Fix Mark Brown review comment about kconfig & driver. v3: 1. Fix Rob Herring review comment about bindings. 2. remove unused variables in driver. v2: 1. Fix Sean Wang review comment. 2. remove unused register and offset define. 3. update bindings file with assigned-clocks and assigned-clocks-parents. v1: This series are based on 4.19-rc1 and provide three patches to add mediatek spi slave driver. Leilk Liu (3): spi: mediatek: add bindings for Mediatek MT2712 soc platform spi: mediatek: add spi slave for Mediatek MT2712 arm64: dts: Add spi slave dts .../devicetree/bindings/spi/spi-slave-mt27xx.txt | 32 ++ arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 11 + drivers/spi/Kconfig| 10 + drivers/spi/Makefile | 1 + drivers/spi/spi-slave-mt27xx.c | 554 + 5 files changed, 608 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt create mode 100644 drivers/spi/spi-slave-mt27xx.c -- 1.9.1
[PATCH v4 1/3] spi: mediatek: add bindings for Mediatek MT2712 soc platform
This patch adds a DT binding documentation for the MT2712 soc.
Signed-off-by: Leilk Liu
---
.../devicetree/bindings/spi/spi-slave-mt27xx.txt | 32
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
b/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
new file mode 100644
index 000..09cb2c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
@@ -0,0 +1,32 @@
+Binding for MTK SPI Slave controller
+
+Required properties:
+- compatible: should be one of the following.
+- mediatek,mt2712-spi-slave: for mt2712 platforms
+- reg: Address and length of the register set for the device.
+- interrupts: Should contain spi interrupt.
+- clocks: phandles to input clocks.
+ It's clock gate, and should be < CLK_INFRA_AO_SPI1>.
+- clock-names: should be "spi" for the clock gate.
+
+Optional properties:
+- assigned-clocks: it's mux clock, should be < CLK_TOP_SPISLV_SEL>.
+- assigned-clock-parents: parent of mux clock.
+ It's PLL, and should be on of the following.
+ - < CLK_TOP_UNIVPLL1_D2>: specify parent clock 312MHZ.
+ It's the default one.
+ - < CLK_TOP_UNIVPLL1_D4>: specify parent clock 156MHZ.
+ - < CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ.
+ - < CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ.
+
+Example:
+- SoC Specific Portion:
+spis1: spi@10013000 {
+ compatible = "mediatek,mt2712-spi-slave";
+ reg = <0 0x10013000 0 0x100>;
+ interrupts = ;
+ clocks = < CLK_INFRA_AO_SPI1>;
+ clock-names = "spi";
+ assigned-clocks = < CLK_TOP_SPISLV_SEL>;
+ assigned-clock-parents = < CLK_TOP_UNIVPLL1_D2>;
+};
--
1.7.9.5
[PATCH v4 1/3] spi: mediatek: add bindings for Mediatek MT2712 soc platform
This patch adds a DT binding documentation for the MT2712 soc.
Signed-off-by: Leilk Liu
---
.../devicetree/bindings/spi/spi-slave-mt27xx.txt | 32
1 file changed, 32 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
diff --git a/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
b/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
new file mode 100644
index 000..09cb2c4
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt
@@ -0,0 +1,32 @@
+Binding for MTK SPI Slave controller
+
+Required properties:
+- compatible: should be one of the following.
+- mediatek,mt2712-spi-slave: for mt2712 platforms
+- reg: Address and length of the register set for the device.
+- interrupts: Should contain spi interrupt.
+- clocks: phandles to input clocks.
+ It's clock gate, and should be < CLK_INFRA_AO_SPI1>.
+- clock-names: should be "spi" for the clock gate.
+
+Optional properties:
+- assigned-clocks: it's mux clock, should be < CLK_TOP_SPISLV_SEL>.
+- assigned-clock-parents: parent of mux clock.
+ It's PLL, and should be on of the following.
+ - < CLK_TOP_UNIVPLL1_D2>: specify parent clock 312MHZ.
+ It's the default one.
+ - < CLK_TOP_UNIVPLL1_D4>: specify parent clock 156MHZ.
+ - < CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ.
+ - < CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ.
+
+Example:
+- SoC Specific Portion:
+spis1: spi@10013000 {
+ compatible = "mediatek,mt2712-spi-slave";
+ reg = <0 0x10013000 0 0x100>;
+ interrupts = ;
+ clocks = < CLK_INFRA_AO_SPI1>;
+ clock-names = "spi";
+ assigned-clocks = < CLK_TOP_SPISLV_SEL>;
+ assigned-clock-parents = < CLK_TOP_UNIVPLL1_D2>;
+};
--
1.7.9.5
[PATCH v4 3/3] arm64: dts: Add spi slave dts
This patch adds MT2712 spi slave into device tree.
Signed-off-by: Leilk Liu
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 75cc0f7..ee627a7 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -301,6 +301,17 @@
status = "disabled";
};
+ spis1: spi@10013000 {
+ compatible = "mediatek,mt2712-spi-slave";
+ reg = <0 0x10013000 0 0x100>;
+ interrupts = ;
+ clocks = < CLK_INFRA_AO_SPI1>;
+ clock-names = "spi";
+ assigned-clocks = < CLK_TOP_SPISLV_SEL>;
+ assigned-clock-parents = < CLK_TOP_UNIVPLL1_D2>;
+ status = "disabled";
+ };
+
apmixedsys: syscon@10209000 {
compatible = "mediatek,mt2712-apmixedsys", "syscon";
reg = <0 0x10209000 0 0x1000>;
--
1.7.9.5
[PATCH v4 3/3] arm64: dts: Add spi slave dts
This patch adds MT2712 spi slave into device tree.
Signed-off-by: Leilk Liu
---
arch/arm64/boot/dts/mediatek/mt2712e.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
index 75cc0f7..ee627a7 100644
--- a/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt2712e.dtsi
@@ -301,6 +301,17 @@
status = "disabled";
};
+ spis1: spi@10013000 {
+ compatible = "mediatek,mt2712-spi-slave";
+ reg = <0 0x10013000 0 0x100>;
+ interrupts = ;
+ clocks = < CLK_INFRA_AO_SPI1>;
+ clock-names = "spi";
+ assigned-clocks = < CLK_TOP_SPISLV_SEL>;
+ assigned-clock-parents = < CLK_TOP_UNIVPLL1_D2>;
+ status = "disabled";
+ };
+
apmixedsys: syscon@10209000 {
compatible = "mediatek,mt2712-apmixedsys", "syscon";
reg = <0 0x10209000 0 0x1000>;
--
1.7.9.5
Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines
Christoph Hellwig 於 2018年9月21日 週五 下午3:00寫道： > > On Tue, Sep 18, 2018 at 05:19:15PM +0800, Zong Li wrote: > > Add umoddi3 and udivmoddi4 support for 32-bit. > > This probably wants a better explanation of why you need them. > > > index 000..69f2d36 > > --- /dev/null > > +++ b/lib/udivmoddi4.c > > @@ -0,0 +1,291 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > Who wrote this code, where does it come from? The RV32 need the umoddi3 to do modulo when the operands are long long type, like other libraries implementation such as ucmpdi2, lshrdi3 and so on. I encounter the undefined reference 'umoddi3' when I use the in house dma driver, although it is in house driver, but I think that umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for flexible extension in the future.
Re: [PATCH 3/5] lib: Add umoddi3 and udivmoddi4 of GCC library routines
Christoph Hellwig 於 2018年9月21日 週五 下午3:00寫道： > > On Tue, Sep 18, 2018 at 05:19:15PM +0800, Zong Li wrote: > > Add umoddi3 and udivmoddi4 support for 32-bit. > > This probably wants a better explanation of why you need them. > > > index 000..69f2d36 > > --- /dev/null > > +++ b/lib/udivmoddi4.c > > @@ -0,0 +1,291 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > Who wrote this code, where does it come from? The RV32 need the umoddi3 to do modulo when the operands are long long type, like other libraries implementation such as ucmpdi2, lshrdi3 and so on. I encounter the undefined reference 'umoddi3' when I use the in house dma driver, although it is in house driver, but I think that umoddi3 is a common function for RV32. The udivmoddi4 and umoddi3 are copies from libgcc in gcc. There are other functions use the udivmoddi4 in libgcc, so I separate the umoddi3 and udivmoddi4 for flexible extension in the future.
[PATCH V2] mm/hugetlb: Add mmap() encodings for 32MB and 512MB page sizes
ARM64 architecture also supports 32MB and 512MB HugeTLB page sizes.
This just adds mmap() system call argument encoding for them.
Signed-off-by: Anshuman Khandual
---
Changes in V2:
- Updated SHM and MFD definitions per Mike
include/uapi/asm-generic/hugetlb_encode.h | 2 ++
include/uapi/linux/memfd.h| 2 ++
include/uapi/linux/mman.h | 2 ++
include/uapi/linux/shm.h | 2 ++
4 files changed, 8 insertions(+)
diff --git a/include/uapi/asm-generic/hugetlb_encode.h
b/include/uapi/asm-generic/hugetlb_encode.h
index e4732d3..b0f8e87 100644
--- a/include/uapi/asm-generic/hugetlb_encode.h
+++ b/include/uapi/asm-generic/hugetlb_encode.h
@@ -26,7 +26,9 @@
#define HUGETLB_FLAG_ENCODE_2MB(21 <<
HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_8MB(23 <<
HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_16MB (24 << HUGETLB_FLAG_ENCODE_SHIFT)
+#define HUGETLB_FLAG_ENCODE_32MB (25 << HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_256MB (28 << HUGETLB_FLAG_ENCODE_SHIFT)
+#define HUGETLB_FLAG_ENCODE_512MB (29 << HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_1GB(30 <<
HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_2GB(31 <<
HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_16GB (34 << HUGETLB_FLAG_ENCODE_SHIFT)
diff --git a/include/uapi/linux/memfd.h b/include/uapi/linux/memfd.h
index 015a4c0..7a8a267 100644
--- a/include/uapi/linux/memfd.h
+++ b/include/uapi/linux/memfd.h
@@ -25,7 +25,9 @@
#define MFD_HUGE_2MB HUGETLB_FLAG_ENCODE_2MB
#define MFD_HUGE_8MB HUGETLB_FLAG_ENCODE_8MB
#define MFD_HUGE_16MB HUGETLB_FLAG_ENCODE_16MB
+#define MFD_HUGE_32MB HUGETLB_FLAG_ENCODE_32MB
#define MFD_HUGE_256MB HUGETLB_FLAG_ENCODE_256MB
+#define MFD_HUGE_512MB HUGETLB_FLAG_ENCODE_512MB
#define MFD_HUGE_1GB HUGETLB_FLAG_ENCODE_1GB
#define MFD_HUGE_2GB HUGETLB_FLAG_ENCODE_2GB
#define MFD_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
index bfd5938..d0f515d 100644
--- a/include/uapi/linux/mman.h
+++ b/include/uapi/linux/mman.h
@@ -28,7 +28,9 @@
#define MAP_HUGE_2MB HUGETLB_FLAG_ENCODE_2MB
#define MAP_HUGE_8MB HUGETLB_FLAG_ENCODE_8MB
#define MAP_HUGE_16MB HUGETLB_FLAG_ENCODE_16MB
+#define MAP_HUGE_32MB HUGETLB_FLAG_ENCODE_32MB
#define MAP_HUGE_256MB HUGETLB_FLAG_ENCODE_256MB
+#define MAP_HUGE_512MB HUGETLB_FLAG_ENCODE_512MB
#define MAP_HUGE_1GB HUGETLB_FLAG_ENCODE_1GB
#define MAP_HUGE_2GB HUGETLB_FLAG_ENCODE_2GB
#define MAP_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index dde1344..6507ad0 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -65,7 +65,9 @@ struct shmid_ds {
#define SHM_HUGE_2MB HUGETLB_FLAG_ENCODE_2MB
#define SHM_HUGE_8MB HUGETLB_FLAG_ENCODE_8MB
#define SHM_HUGE_16MB HUGETLB_FLAG_ENCODE_16MB
+#define SHM_HUGE_32MB HUGETLB_FLAG_ENCODE_32MB
#define SHM_HUGE_256MB HUGETLB_FLAG_ENCODE_256MB
+#define SHM_HUGE_512MB HUGETLB_FLAG_ENCODE_512MB
#define SHM_HUGE_1GB HUGETLB_FLAG_ENCODE_1GB
#define SHM_HUGE_2GB HUGETLB_FLAG_ENCODE_2GB
#define SHM_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
--
2.7.4
[PATCH V2] mm/hugetlb: Add mmap() encodings for 32MB and 512MB page sizes
ARM64 architecture also supports 32MB and 512MB HugeTLB page sizes.
This just adds mmap() system call argument encoding for them.
Signed-off-by: Anshuman Khandual
---
Changes in V2:
- Updated SHM and MFD definitions per Mike
include/uapi/asm-generic/hugetlb_encode.h | 2 ++
include/uapi/linux/memfd.h| 2 ++
include/uapi/linux/mman.h | 2 ++
include/uapi/linux/shm.h | 2 ++
4 files changed, 8 insertions(+)
diff --git a/include/uapi/asm-generic/hugetlb_encode.h
b/include/uapi/asm-generic/hugetlb_encode.h
index e4732d3..b0f8e87 100644
--- a/include/uapi/asm-generic/hugetlb_encode.h
+++ b/include/uapi/asm-generic/hugetlb_encode.h
@@ -26,7 +26,9 @@
#define HUGETLB_FLAG_ENCODE_2MB(21 <<
HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_8MB(23 <<
HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_16MB (24 << HUGETLB_FLAG_ENCODE_SHIFT)
+#define HUGETLB_FLAG_ENCODE_32MB (25 << HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_256MB (28 << HUGETLB_FLAG_ENCODE_SHIFT)
+#define HUGETLB_FLAG_ENCODE_512MB (29 << HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_1GB(30 <<
HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_2GB(31 <<
HUGETLB_FLAG_ENCODE_SHIFT)
#define HUGETLB_FLAG_ENCODE_16GB (34 << HUGETLB_FLAG_ENCODE_SHIFT)
diff --git a/include/uapi/linux/memfd.h b/include/uapi/linux/memfd.h
index 015a4c0..7a8a267 100644
--- a/include/uapi/linux/memfd.h
+++ b/include/uapi/linux/memfd.h
@@ -25,7 +25,9 @@
#define MFD_HUGE_2MB HUGETLB_FLAG_ENCODE_2MB
#define MFD_HUGE_8MB HUGETLB_FLAG_ENCODE_8MB
#define MFD_HUGE_16MB HUGETLB_FLAG_ENCODE_16MB
+#define MFD_HUGE_32MB HUGETLB_FLAG_ENCODE_32MB
#define MFD_HUGE_256MB HUGETLB_FLAG_ENCODE_256MB
+#define MFD_HUGE_512MB HUGETLB_FLAG_ENCODE_512MB
#define MFD_HUGE_1GB HUGETLB_FLAG_ENCODE_1GB
#define MFD_HUGE_2GB HUGETLB_FLAG_ENCODE_2GB
#define MFD_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
diff --git a/include/uapi/linux/mman.h b/include/uapi/linux/mman.h
index bfd5938..d0f515d 100644
--- a/include/uapi/linux/mman.h
+++ b/include/uapi/linux/mman.h
@@ -28,7 +28,9 @@
#define MAP_HUGE_2MB HUGETLB_FLAG_ENCODE_2MB
#define MAP_HUGE_8MB HUGETLB_FLAG_ENCODE_8MB
#define MAP_HUGE_16MB HUGETLB_FLAG_ENCODE_16MB
+#define MAP_HUGE_32MB HUGETLB_FLAG_ENCODE_32MB
#define MAP_HUGE_256MB HUGETLB_FLAG_ENCODE_256MB
+#define MAP_HUGE_512MB HUGETLB_FLAG_ENCODE_512MB
#define MAP_HUGE_1GB HUGETLB_FLAG_ENCODE_1GB
#define MAP_HUGE_2GB HUGETLB_FLAG_ENCODE_2GB
#define MAP_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
diff --git a/include/uapi/linux/shm.h b/include/uapi/linux/shm.h
index dde1344..6507ad0 100644
--- a/include/uapi/linux/shm.h
+++ b/include/uapi/linux/shm.h
@@ -65,7 +65,9 @@ struct shmid_ds {
#define SHM_HUGE_2MB HUGETLB_FLAG_ENCODE_2MB
#define SHM_HUGE_8MB HUGETLB_FLAG_ENCODE_8MB
#define SHM_HUGE_16MB HUGETLB_FLAG_ENCODE_16MB
+#define SHM_HUGE_32MB HUGETLB_FLAG_ENCODE_32MB
#define SHM_HUGE_256MB HUGETLB_FLAG_ENCODE_256MB
+#define SHM_HUGE_512MB HUGETLB_FLAG_ENCODE_512MB
#define SHM_HUGE_1GB HUGETLB_FLAG_ENCODE_1GB
#define SHM_HUGE_2GB HUGETLB_FLAG_ENCODE_2GB
#define SHM_HUGE_16GB HUGETLB_FLAG_ENCODE_16GB
--
2.7.4
Re: [RFC 00/20] ns: Introduce Time Namespace
On Tue, Sep 25, 2018 at 12:02:32AM +0200, Eric W. Biederman wrote: > Andrey Vagin writes: > > > On Fri, Sep 21, 2018 at 02:27:29PM +0200, Eric W. Biederman wrote: > >> Dmitry Safonov writes: > >> > >> > Discussions around time virtualization are there for a long time. > >> > The first attempt to implement time namespace was in 2006 by Jeff Dike. > >> > From that time, the topic appears on and off in various discussions. > >> > > >> > There are two main use cases for time namespaces: > >> > 1. change date and time inside a container; > >> > 2. adjust clocks for a container restored from a checkpoint. > >> > > >> > “It seems like this might be one of the last major obstacles keeping > >> > migration from being used in production systems, given that not all > >> > containers and connections can be migrated as long as a time dependency > >> > is capable of messing it up.” (by github.com/dav-ell) > >> > > >> > The kernel provides access to several clocks: CLOCK_REALTIME, > >> > CLOCK_MONOTONIC, CLOCK_BOOTTIME. Last two clocks are monotonous, but the > >> > start points for them are not defined and are different for each running > >> > system. When a container is migrated from one node to another, all > >> > clocks have to be restored into consistent states; in other words, they > >> > have to continue running from the same points where they have been > >> > dumped. > >> > > >> > The main idea behind this patch set is adding per-namespace offsets for > >> > system clocks. When a process in a non-root time namespace requests > >> > time of a clock, a namespace offset is added to the current value of > >> > this clock on a host and the sum is returned. > >> > > >> > All offsets are placed on a separate page, this allows up to map it as > >> > part of vvar into user processes and use offsets from vdso calls. > >> > > >> > Now offsets are implemented for CLOCK_MONOTONIC and CLOCK_BOOTTIME > >> > clocks. > >> > > >> > Questions to discuss: > >> > > >> > * Clone flags exhaustion. Currently there is only one unused clone flag > >> > bit left, and it may be worth to use it to extend arguments of the clone > >> > system call. > >> > > >> > * Realtime clock implementation details: > >> > Is having a simple offset enough? > >> > What to do when date and time is changed on the host? > >> > Is there a need to adjust vfs modification and creation times? > >> > Implementation for adjtime() syscall. > >> > >> Overall I support this effort. In my quick skim this code looked good. > > > > Hi Eric, > > > > Thank you for the feedback. > > > >> > >> My feeling is that we need to be able to support running ntpd and > >> support one namespace doing googles smoothing of leap seconds while > >> another namespace takes the leap second. > >> > >> What I was imagining when I was last thinking about this was one > >> instance of struct timekeeper aka tk_core per time namespace. That > >> structure already keeps offsets for all of the various clocks from > >> the kerne internal time sources. What would be needed would be to > >> pass in an appropriate time namespace pointer. > >> > >> I could be completely wrong as I have not take the time to completely > >> trace through the code. Have you looked at pushing the time namespace > >> down as far as tk_core? > >> > >> What I think would be the big advantage (besides ntp working) is that > >> the bulk of the code could be reused. Allowing testing of the kernel's > >> time code by setting up a new time namespace. So a person in production > >> could setup a time namespace with the time set ahead a little bit and > >> be able to verify that the kernel handles the upcoming leap second > >> properly. > >> > > > > It is an interesting idea, but I have a few questions: > > > > 1. Does it mean that timekeeping_update() will be called for each > > namespace? This functions is called periodically, it updates times on the > > timekeeper structure, updates vsyscall_gtod_data, etc. What will be an > > overhead of this? > > I don't know if periodically is a proper characterization. There may be > a code path that does that. But from what I can see timekeeping_update > is the guts of settimeofday (and a few related functions). > > So it appears to make sense for timekeeping_update to be per namespace. > > Hmm. Looking at what is updated in the vsyscall_gtod_data it does > look like you would have to periodically update things, but I don't know > big that period would be. As long as the period is reasonably large, > or the time namespaces were sufficiently deschronized it should not > be a problem. But that is the class of problem that could make > my ideal impractical if there is measuarable overhead. > > Where were you seeing timekeeping_update being called periodically? timekeeping_update() is called HZ times per-second: [ 67.912858] timekeeping_update.cold.26+0x5/0xa [ 67.913332] timekeeping_advance+0x361/0x5c0 [ 67.913857] ? tick_sched_do_timer+0x55/0x70 [
Re: [RFC 00/20] ns: Introduce Time Namespace
On Tue, Sep 25, 2018 at 12:02:32AM +0200, Eric W. Biederman wrote: > Andrey Vagin writes: > > > On Fri, Sep 21, 2018 at 02:27:29PM +0200, Eric W. Biederman wrote: > >> Dmitry Safonov writes: > >> > >> > Discussions around time virtualization are there for a long time. > >> > The first attempt to implement time namespace was in 2006 by Jeff Dike. > >> > From that time, the topic appears on and off in various discussions. > >> > > >> > There are two main use cases for time namespaces: > >> > 1. change date and time inside a container; > >> > 2. adjust clocks for a container restored from a checkpoint. > >> > > >> > “It seems like this might be one of the last major obstacles keeping > >> > migration from being used in production systems, given that not all > >> > containers and connections can be migrated as long as a time dependency > >> > is capable of messing it up.” (by github.com/dav-ell) > >> > > >> > The kernel provides access to several clocks: CLOCK_REALTIME, > >> > CLOCK_MONOTONIC, CLOCK_BOOTTIME. Last two clocks are monotonous, but the > >> > start points for them are not defined and are different for each running > >> > system. When a container is migrated from one node to another, all > >> > clocks have to be restored into consistent states; in other words, they > >> > have to continue running from the same points where they have been > >> > dumped. > >> > > >> > The main idea behind this patch set is adding per-namespace offsets for > >> > system clocks. When a process in a non-root time namespace requests > >> > time of a clock, a namespace offset is added to the current value of > >> > this clock on a host and the sum is returned. > >> > > >> > All offsets are placed on a separate page, this allows up to map it as > >> > part of vvar into user processes and use offsets from vdso calls. > >> > > >> > Now offsets are implemented for CLOCK_MONOTONIC and CLOCK_BOOTTIME > >> > clocks. > >> > > >> > Questions to discuss: > >> > > >> > * Clone flags exhaustion. Currently there is only one unused clone flag > >> > bit left, and it may be worth to use it to extend arguments of the clone > >> > system call. > >> > > >> > * Realtime clock implementation details: > >> > Is having a simple offset enough? > >> > What to do when date and time is changed on the host? > >> > Is there a need to adjust vfs modification and creation times? > >> > Implementation for adjtime() syscall. > >> > >> Overall I support this effort. In my quick skim this code looked good. > > > > Hi Eric, > > > > Thank you for the feedback. > > > >> > >> My feeling is that we need to be able to support running ntpd and > >> support one namespace doing googles smoothing of leap seconds while > >> another namespace takes the leap second. > >> > >> What I was imagining when I was last thinking about this was one > >> instance of struct timekeeper aka tk_core per time namespace. That > >> structure already keeps offsets for all of the various clocks from > >> the kerne internal time sources. What would be needed would be to > >> pass in an appropriate time namespace pointer. > >> > >> I could be completely wrong as I have not take the time to completely > >> trace through the code. Have you looked at pushing the time namespace > >> down as far as tk_core? > >> > >> What I think would be the big advantage (besides ntp working) is that > >> the bulk of the code could be reused. Allowing testing of the kernel's > >> time code by setting up a new time namespace. So a person in production > >> could setup a time namespace with the time set ahead a little bit and > >> be able to verify that the kernel handles the upcoming leap second > >> properly. > >> > > > > It is an interesting idea, but I have a few questions: > > > > 1. Does it mean that timekeeping_update() will be called for each > > namespace? This functions is called periodically, it updates times on the > > timekeeper structure, updates vsyscall_gtod_data, etc. What will be an > > overhead of this? > > I don't know if periodically is a proper characterization. There may be > a code path that does that. But from what I can see timekeeping_update > is the guts of settimeofday (and a few related functions). > > So it appears to make sense for timekeeping_update to be per namespace. > > Hmm. Looking at what is updated in the vsyscall_gtod_data it does > look like you would have to periodically update things, but I don't know > big that period would be. As long as the period is reasonably large, > or the time namespaces were sufficiently deschronized it should not > be a problem. But that is the class of problem that could make > my ideal impractical if there is measuarable overhead. > > Where were you seeing timekeeping_update being called periodically? timekeeping_update() is called HZ times per-second: [ 67.912858] timekeeping_update.cold.26+0x5/0xa [ 67.913332] timekeeping_advance+0x361/0x5c0 [ 67.913857] ? tick_sched_do_timer+0x55/0x70 [
Re: [PATCH 4.9 111/111] MIPS: VDSO: Drop gic_get_usm_range() usage
On Mon, Sep 24, 2018 at 01:53:18PM +0200, Greg Kroah-Hartman wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
This patch breaks v4.4.y and v4.9.y builds.
It includes asm/mips-cps.h which doesn't exist in those releases.
Building mips:malta_defconfig:smp:initrd ... failed
Error log:
arch/mips/kernel/vdso.c:23:26: fatal error: asm/mips-cps.h: No such file or
directory
Guenter
> --
>
> From: Paul Burton
>
> commit 00578cd864d45ae4b8fa3f684f8d6f783dd8d15d upstream.
>
> We don't really need gic_get_usm_range() to abstract discovery of the
> address of the GIC user-visible section now that we have access to its
> base address globally.
>
> Switch to calculating it ourselves, which will allow us to stop
> requiring the irqchip driver to care about a counter exposed to userland
> for use via the VDSO.
>
> Signed-off-by: Paul Burton
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Thomas Gleixner
> Cc: linux-m...@linux-mips.org
> Patchwork: https://patchwork.linux-mips.org/patch/17040/
> Signed-off-by: Ralf Baechle
> Signed-off-by: SZ Lin (林上智)
> Signed-off-by: Greg Kroah-Hartman
> ---
> arch/mips/kernel/vdso.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> --- a/arch/mips/kernel/vdso.c
> +++ b/arch/mips/kernel/vdso.c
> @@ -13,7 +13,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -21,6 +20,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> @@ -101,9 +101,8 @@ int arch_setup_additional_pages(struct l
> {
> struct mips_vdso_image *image = current->thread.abi->vdso;
> struct mm_struct *mm = current->mm;
> - unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr;
> + unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr,
> gic_pfn;
> struct vm_area_struct *vma;
> - struct resource gic_res;
> int ret;
>
> if (down_write_killable(>mmap_sem))
> @@ -127,7 +126,7 @@ int arch_setup_additional_pages(struct l
>* only map a page even though the total area is 64K, as we only need
>* the counter registers at the start.
>*/
> - gic_size = gic_present ? PAGE_SIZE : 0;
> + gic_size = mips_gic_present() ? PAGE_SIZE : 0;
> vvar_size = gic_size + PAGE_SIZE;
> size = vvar_size + image->size;
>
> @@ -168,13 +167,9 @@ int arch_setup_additional_pages(struct l
>
> /* Map GIC user page. */
> if (gic_size) {
> - ret = gic_get_usm_range(_res);
> - if (ret)
> - goto out;
> + gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >>
> PAGE_SHIFT;
>
> - ret = io_remap_pfn_range(vma, base,
> - gic_res.start >> PAGE_SHIFT,
> - gic_size,
> + ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
>pgprot_noncached(PAGE_READONLY));
> if (ret)
> goto out;
>
>
Re: [PATCH 4.9 111/111] MIPS: VDSO: Drop gic_get_usm_range() usage
On Mon, Sep 24, 2018 at 01:53:18PM +0200, Greg Kroah-Hartman wrote:
> 4.9-stable review patch. If anyone has any objections, please let me know.
>
This patch breaks v4.4.y and v4.9.y builds.
It includes asm/mips-cps.h which doesn't exist in those releases.
Building mips:malta_defconfig:smp:initrd ... failed
Error log:
arch/mips/kernel/vdso.c:23:26: fatal error: asm/mips-cps.h: No such file or
directory
Guenter
> --
>
> From: Paul Burton
>
> commit 00578cd864d45ae4b8fa3f684f8d6f783dd8d15d upstream.
>
> We don't really need gic_get_usm_range() to abstract discovery of the
> address of the GIC user-visible section now that we have access to its
> base address globally.
>
> Switch to calculating it ourselves, which will allow us to stop
> requiring the irqchip driver to care about a counter exposed to userland
> for use via the VDSO.
>
> Signed-off-by: Paul Burton
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Thomas Gleixner
> Cc: linux-m...@linux-mips.org
> Patchwork: https://patchwork.linux-mips.org/patch/17040/
> Signed-off-by: Ralf Baechle
> Signed-off-by: SZ Lin (林上智)
> Signed-off-by: Greg Kroah-Hartman
> ---
> arch/mips/kernel/vdso.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
>
> --- a/arch/mips/kernel/vdso.c
> +++ b/arch/mips/kernel/vdso.c
> @@ -13,7 +13,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> #include
> @@ -21,6 +20,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> @@ -101,9 +101,8 @@ int arch_setup_additional_pages(struct l
> {
> struct mips_vdso_image *image = current->thread.abi->vdso;
> struct mm_struct *mm = current->mm;
> - unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr;
> + unsigned long gic_size, vvar_size, size, base, data_addr, vdso_addr,
> gic_pfn;
> struct vm_area_struct *vma;
> - struct resource gic_res;
> int ret;
>
> if (down_write_killable(>mmap_sem))
> @@ -127,7 +126,7 @@ int arch_setup_additional_pages(struct l
>* only map a page even though the total area is 64K, as we only need
>* the counter registers at the start.
>*/
> - gic_size = gic_present ? PAGE_SIZE : 0;
> + gic_size = mips_gic_present() ? PAGE_SIZE : 0;
> vvar_size = gic_size + PAGE_SIZE;
> size = vvar_size + image->size;
>
> @@ -168,13 +167,9 @@ int arch_setup_additional_pages(struct l
>
> /* Map GIC user page. */
> if (gic_size) {
> - ret = gic_get_usm_range(_res);
> - if (ret)
> - goto out;
> + gic_pfn = virt_to_phys(mips_gic_base + MIPS_GIC_USER_OFS) >>
> PAGE_SHIFT;
>
> - ret = io_remap_pfn_range(vma, base,
> - gic_res.start >> PAGE_SHIFT,
> - gic_size,
> + ret = io_remap_pfn_range(vma, base, gic_pfn, gic_size,
>pgprot_noncached(PAGE_READONLY));
> if (ret)
> goto out;
>
>
[PATCH] ASoC: soc-utils: Rename dummy_dma_ops to snd_dummy_ops
The symbols 'dummy_dma_ops' is declared with different data types by
sound/soc/soc-utils.c and arch/arm64/include/asm/dma-mapping.h. This
leads to conflicts when soc-utils.c (indirectly) includes dma-mapping.h:
sound/soc/soc-utils.c:282:33: error: conflicting types for 'dummy_dma_ops'
static const struct snd_pcm_ops dummy_dma_ops = {
^
...
arch/arm64/include/asm/dma-mapping.h:27:33: note: previous declaration of
'dummy_dma_ops' was here
extern const struct dma_map_ops dummy_dma_ops;
^
Rename the symbol in soc-utils.c to 'snd_dummy_ops' to avoid the conflict.
Signed-off-by: Matthias Kaehlcke
---
sound/soc/soc-utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/soc-utils.c b/sound/soc/soc-utils.c
index e0c93496c0cd..ab44133bc0bf 100644
--- a/sound/soc/soc-utils.c
+++ b/sound/soc/soc-utils.c
@@ -273,13 +273,13 @@ static int dummy_dma_open(struct snd_pcm_substream
*substream)
return 0;
}
-static const struct snd_pcm_ops dummy_dma_ops = {
+static const struct snd_pcm_ops snd_dummy_ops = {
.open = dummy_dma_open,
.ioctl = snd_pcm_lib_ioctl,
};
static const struct snd_soc_component_driver dummy_platform = {
- .ops = _dma_ops,
+ .ops = _dummy_ops,
};
static const struct snd_soc_component_driver dummy_codec = {
--
2.19.0.605.g01d371f741-goog
[PATCH] ASoC: soc-utils: Rename dummy_dma_ops to snd_dummy_ops
The symbols 'dummy_dma_ops' is declared with different data types by
sound/soc/soc-utils.c and arch/arm64/include/asm/dma-mapping.h. This
leads to conflicts when soc-utils.c (indirectly) includes dma-mapping.h:
sound/soc/soc-utils.c:282:33: error: conflicting types for 'dummy_dma_ops'
static const struct snd_pcm_ops dummy_dma_ops = {
^
...
arch/arm64/include/asm/dma-mapping.h:27:33: note: previous declaration of
'dummy_dma_ops' was here
extern const struct dma_map_ops dummy_dma_ops;
^
Rename the symbol in soc-utils.c to 'snd_dummy_ops' to avoid the conflict.
Signed-off-by: Matthias Kaehlcke
---
sound/soc/soc-utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/soc-utils.c b/sound/soc/soc-utils.c
index e0c93496c0cd..ab44133bc0bf 100644
--- a/sound/soc/soc-utils.c
+++ b/sound/soc/soc-utils.c
@@ -273,13 +273,13 @@ static int dummy_dma_open(struct snd_pcm_substream
*substream)
return 0;
}
-static const struct snd_pcm_ops dummy_dma_ops = {
+static const struct snd_pcm_ops snd_dummy_ops = {
.open = dummy_dma_open,
.ioctl = snd_pcm_lib_ioctl,
};
static const struct snd_soc_component_driver dummy_platform = {
- .ops = _dma_ops,
+ .ops = _dummy_ops,
};
static const struct snd_soc_component_driver dummy_codec = {
--
2.19.0.605.g01d371f741-goog
Re: [PATCH] clocksource/drivers/fttmr010: fix set_next_event handler
On 9/24/18, 4:20 PM, "Joel Stanley" wrote: > Whatever method is easiest for you. A patch file or a tarball is fine. > I will then add it to the set of tests I run when testing aspeed > kernels. No problem, Joel. I will share the test code with you offline. Thanks, Tao Ren
Re: [PATCH] clocksource/drivers/fttmr010: fix set_next_event handler
On 9/24/18, 4:20 PM, "Joel Stanley" wrote: > Whatever method is easiest for you. A patch file or a tarball is fine. > I will then add it to the set of tests I run when testing aspeed > kernels. No problem, Joel. I will share the test code with you offline. Thanks, Tao Ren
Re: [PATCH] rpmsg: core: add support to power domains for devices
Hi Srinivas,
On 06/15/2018 04:59 AM, Srinivas Kandagatla wrote:
> Some of the rpmsg devices need to switch on power domains to communicate
> with remote processor. For example on Qualcomm DB820c platform LPASS
> power domain needs to switched on for any kind of audio services.
> This patch adds the missing power domain support in rpmsg core.
>
> Without this patch attempting to play audio via QDSP on DB820c would
> reboot the system.
>
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/rpmsg/rpmsg_core.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index b714a543a91d..8122807db380 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "rpmsg_internal.h"
> @@ -449,6 +450,10 @@ static int rpmsg_dev_probe(struct device *dev)
> struct rpmsg_endpoint *ept = NULL;
> int err;
>
> + err = dev_pm_domain_attach(dev, true);
> + if (err)
> + goto out;
This patch has broken the virtio-rpmsg stack based rpmsg devices. These
devices are non-DT and the rpmsg_dev_probe() is now failing with -19
(-ENODEV) error code.
Loic, Arnaud,
Can one of you double-confirm this behavior on ST platforms as well?
The patch came through 4.14.71 stable release and broke our downstream
kernels.
regards
Suman
> +
> if (rpdrv->callback) {
> strncpy(chinfo.name, rpdev->id.name, RPMSG_NAME_SIZE);
> chinfo.src = rpdev->src;
> @@ -490,6 +495,8 @@ static int rpmsg_dev_remove(struct device *dev)
>
> rpdrv->remove(rpdev);
>
> + dev_pm_domain_detach(dev, true);
> +
> if (rpdev->ept)
> rpmsg_destroy_ept(rpdev->ept);
>
>
Re: [PATCH] rpmsg: core: add support to power domains for devices
Hi Srinivas,
On 06/15/2018 04:59 AM, Srinivas Kandagatla wrote:
> Some of the rpmsg devices need to switch on power domains to communicate
> with remote processor. For example on Qualcomm DB820c platform LPASS
> power domain needs to switched on for any kind of audio services.
> This patch adds the missing power domain support in rpmsg core.
>
> Without this patch attempting to play audio via QDSP on DB820c would
> reboot the system.
>
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/rpmsg/rpmsg_core.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/rpmsg/rpmsg_core.c b/drivers/rpmsg/rpmsg_core.c
> index b714a543a91d..8122807db380 100644
> --- a/drivers/rpmsg/rpmsg_core.c
> +++ b/drivers/rpmsg/rpmsg_core.c
> @@ -15,6 +15,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "rpmsg_internal.h"
> @@ -449,6 +450,10 @@ static int rpmsg_dev_probe(struct device *dev)
> struct rpmsg_endpoint *ept = NULL;
> int err;
>
> + err = dev_pm_domain_attach(dev, true);
> + if (err)
> + goto out;
This patch has broken the virtio-rpmsg stack based rpmsg devices. These
devices are non-DT and the rpmsg_dev_probe() is now failing with -19
(-ENODEV) error code.
Loic, Arnaud,
Can one of you double-confirm this behavior on ST platforms as well?
The patch came through 4.14.71 stable release and broke our downstream
kernels.
regards
Suman
> +
> if (rpdrv->callback) {
> strncpy(chinfo.name, rpdev->id.name, RPMSG_NAME_SIZE);
> chinfo.src = rpdev->src;
> @@ -490,6 +495,8 @@ static int rpmsg_dev_remove(struct device *dev)
>
> rpdrv->remove(rpdev);
>
> + dev_pm_domain_detach(dev, true);
> +
> if (rpdev->ept)
> rpmsg_destroy_ept(rpdev->ept);
>
>
Re: [PATCH TRIVIAL] Punctuation fixes
On Sun, Sep 23, 2018 at 5:59 AM Richard Weinberger wrote: > > On Sun, Sep 23, 2018 at 3:00 AM Miguel Ojeda > wrote: > > > > Hi Diego, > > > > A few things, since it looks like this is your first patch. > > git log... > > > On Sat, Sep 22, 2018 at 5:56 PM, Diego Viola wrote: > > > On Wed, Sep 12, 2018 at 12:54 AM Diego Viola > > > wrote: > > >> > > >> Signed-off-by: Diego Viola > > >> --- > > >> CREDITS | 2 +- > > >> MAINTAINERS | 2 +- > > >> Makefile| 2 +- > > >> 3 files changed, 3 insertions(+), 3 deletions(-) > > >> > > >> diff --git a/CREDITS b/CREDITS > > >> index 5befd2d71..b82efb36d 100644 > > >> --- a/CREDITS > > >> +++ b/CREDITS > > >> @@ -1473,7 +1473,7 @@ W: http://www.linux-ide.org/ > > >> W: http://www.linuxdiskcert.org/ > > >> D: Random SMP kernel hacker... > > >> D: Uniform Multi-Platform E-IDE driver > > >> -D: Active-ATA-Chipset maddness.. > > >> +D: Active-ATA-Chipset maddness... > > > > I think the extra dots is what was intended here :) > > Diego, I know you can do better. :-) > How about running linux-next and hunting down regressions? > I think we suggested this already on IRC. OK. I'll do that after I'm done with the documentation. > > -- > Thanks, > //richard Thanks, Diego
Re: [PATCH TRIVIAL] Punctuation fixes
On Sun, Sep 23, 2018 at 5:59 AM Richard Weinberger wrote: > > On Sun, Sep 23, 2018 at 3:00 AM Miguel Ojeda > wrote: > > > > Hi Diego, > > > > A few things, since it looks like this is your first patch. > > git log... > > > On Sat, Sep 22, 2018 at 5:56 PM, Diego Viola wrote: > > > On Wed, Sep 12, 2018 at 12:54 AM Diego Viola > > > wrote: > > >> > > >> Signed-off-by: Diego Viola > > >> --- > > >> CREDITS | 2 +- > > >> MAINTAINERS | 2 +- > > >> Makefile| 2 +- > > >> 3 files changed, 3 insertions(+), 3 deletions(-) > > >> > > >> diff --git a/CREDITS b/CREDITS > > >> index 5befd2d71..b82efb36d 100644 > > >> --- a/CREDITS > > >> +++ b/CREDITS > > >> @@ -1473,7 +1473,7 @@ W: http://www.linux-ide.org/ > > >> W: http://www.linuxdiskcert.org/ > > >> D: Random SMP kernel hacker... > > >> D: Uniform Multi-Platform E-IDE driver > > >> -D: Active-ATA-Chipset maddness.. > > >> +D: Active-ATA-Chipset maddness... > > > > I think the extra dots is what was intended here :) > > Diego, I know you can do better. :-) > How about running linux-next and hunting down regressions? > I think we suggested this already on IRC. OK. I'll do that after I'm done with the documentation. > > -- > Thanks, > //richard Thanks, Diego
[PATCH v2] dt-bindings: pinctrl: qcom-pmic-gpio: Add pms405 support
From: Vinod Koul Add support for the PMS405 GPIO support to the Qualcomm PMIC GPIO binding. Signed-off-by: Vinod Koul Signed-off-by: Bjorn Andersson --- Changes since v1: - Dropped unnecessary driver update - Updated subject Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index ffd4345415f3..ab4000eab07d 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -19,6 +19,7 @@ PMIC's from Qualcomm. "qcom,pm8998-gpio" "qcom,pma8084-gpio" "qcom,pmi8994-gpio" + "qcom,pms405-gpio" And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" if the device is on an spmi bus or an ssbi bus respectively @@ -91,6 +92,7 @@ to specify in a pin configuration subnode: gpio1-gpio26 for pm8998 gpio1-gpio22 for pma8084 gpio1-gpio10 for pmi8994 + gpio1-gpio11 for pms405 - function: Usage: required -- 2.18.0
[PATCH v2] dt-bindings: pinctrl: qcom-pmic-gpio: Add pms405 support
From: Vinod Koul Add support for the PMS405 GPIO support to the Qualcomm PMIC GPIO binding. Signed-off-by: Vinod Koul Signed-off-by: Bjorn Andersson --- Changes since v1: - Dropped unnecessary driver update - Updated subject Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index ffd4345415f3..ab4000eab07d 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -19,6 +19,7 @@ PMIC's from Qualcomm. "qcom,pm8998-gpio" "qcom,pma8084-gpio" "qcom,pmi8994-gpio" + "qcom,pms405-gpio" And must contain either "qcom,spmi-gpio" or "qcom,ssbi-gpio" if the device is on an spmi bus or an ssbi bus respectively @@ -91,6 +92,7 @@ to specify in a pin configuration subnode: gpio1-gpio26 for pm8998 gpio1-gpio22 for pma8084 gpio1-gpio10 for pmi8994 + gpio1-gpio11 for pms405 - function: Usage: required -- 2.18.0
Re: [PATCH v12 1/2] leds: core: Introduce LED pattern trigger
On Mon 10 Sep 19:47 PDT 2018, Baolin Wang wrote: [..] > diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern > b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern [..] > +What:/sys/class/leds//hw_pattern > +Date:September 2018 > +KernelVersion: 4.20 > +Description: > + Specify a hardware pattern for the LED, for LED hardware that > + supports autonomously controlling brightness over time, > according > + to some preprogrammed hardware patterns. > + > + Since different LED hardware can have different semantics of > + hardware patterns, each driver is expected to provide its own > + description for the hardware patterns in their ABI documentation > + file. > + > +What:/sys/class/leds//repeat > +Date:September 2018 > +KernelVersion: 4.20 > +Description: > + Specify a pattern repeat number. -1 means repeat indefinitely, > + other negative numbers and number 0 are invalid. > + > + This file will always return the originally written repeat > + number. This captures the infinite case much better, thanks! Given that 0 is described as invalid, does this imply that setting a new pattern the repeat will be disabled? And hence if my hardware supports only infinite or no-repeat setting a new pattern is the way to disable further repeats (rather than just setting repeat = 0)? Regardless, I believe the semantics of these two files will work fine for my Qualcomm LPG driver. Regards, Bjorn
Re: [PATCH v12 1/2] leds: core: Introduce LED pattern trigger
On Mon 10 Sep 19:47 PDT 2018, Baolin Wang wrote: [..] > diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern > b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern [..] > +What:/sys/class/leds//hw_pattern > +Date:September 2018 > +KernelVersion: 4.20 > +Description: > + Specify a hardware pattern for the LED, for LED hardware that > + supports autonomously controlling brightness over time, > according > + to some preprogrammed hardware patterns. > + > + Since different LED hardware can have different semantics of > + hardware patterns, each driver is expected to provide its own > + description for the hardware patterns in their ABI documentation > + file. > + > +What:/sys/class/leds//repeat > +Date:September 2018 > +KernelVersion: 4.20 > +Description: > + Specify a pattern repeat number. -1 means repeat indefinitely, > + other negative numbers and number 0 are invalid. > + > + This file will always return the originally written repeat > + number. This captures the infinite case much better, thanks! Given that 0 is described as invalid, does this imply that setting a new pattern the repeat will be disabled? And hence if my hardware supports only infinite or no-repeat setting a new pattern is the way to disable further repeats (rather than just setting repeat = 0)? Regardless, I believe the semantics of these two files will work fine for my Qualcomm LPG driver. Regards, Bjorn
[PATCH v3 0/3] Fix qcom geni i2c DMA handling
(Numbering is weird because I dropped patch 1 but left numbering the same) The qcom GENI I2C driver fails DMA sometimes when things from request firmware are passed in as the message buffer. This patch series fixes that problem in the first patch and the second patch cleans up the code a little to reduce lines and simplify lines. Cc: Karthikeyan Ramasubramanian Cc: Sagar Dharia Cc: Girish Mahadevan Cc: Doug Anderson Changes from v2: * Dropped first patch because it's applied * New patch 3 to simplify irq handler * Updated patch 2 to hoist out common code and remove 'mode' local variable Changes from v1: * Use i2c helpers to map buffers * New patch 2 to clean up seriously indented code Stephen Boyd (2): i2c: i2c-qcom-geni: Simplify tx/rx functions i2c: i2c-qcom-geni: Simplify irq handler drivers/i2c/busses/i2c-qcom-geni.c | 149 + 1 file changed, 65 insertions(+), 84 deletions(-) -- Sent by a computer through tubes
[PATCH v3 0/3] Fix qcom geni i2c DMA handling
(Numbering is weird because I dropped patch 1 but left numbering the same) The qcom GENI I2C driver fails DMA sometimes when things from request firmware are passed in as the message buffer. This patch series fixes that problem in the first patch and the second patch cleans up the code a little to reduce lines and simplify lines. Cc: Karthikeyan Ramasubramanian Cc: Sagar Dharia Cc: Girish Mahadevan Cc: Doug Anderson Changes from v2: * Dropped first patch because it's applied * New patch 3 to simplify irq handler * Updated patch 2 to hoist out common code and remove 'mode' local variable Changes from v1: * Use i2c helpers to map buffers * New patch 2 to clean up seriously indented code Stephen Boyd (2): i2c: i2c-qcom-geni: Simplify tx/rx functions i2c: i2c-qcom-geni: Simplify irq handler drivers/i2c/busses/i2c-qcom-geni.c | 149 + 1 file changed, 65 insertions(+), 84 deletions(-) -- Sent by a computer through tubes
[PATCH v3 3/3] i2c: i2c-qcom-geni: Simplify irq handler
We don't need to use goto here, we can just collapse the if statement
and goto chain into multiple branches and then combine some duplicate
completion calls into one big if statement. Let's do it to clean up code
some more.
Cc: Karthikeyan Ramasubramanian
Cc: Sagar Dharia
Cc: Girish Mahadevan
Cc: Doug Anderson
Signed-off-by: Stephen Boyd
---
drivers/i2c/busses/i2c-qcom-geni.c | 70 +-
1 file changed, 29 insertions(+), 41 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 0b466835cf40..527f55c8c4c7 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -201,21 +201,23 @@ static void geni_i2c_err(struct geni_i2c_dev *gi2c, int
err)
static irqreturn_t geni_i2c_irq(int irq, void *dev)
{
struct geni_i2c_dev *gi2c = dev;
- int j;
+ void __iomem *base = gi2c->se.base;
+ int j, p;
u32 m_stat;
u32 rx_st;
u32 dm_tx_st;
u32 dm_rx_st;
u32 dma;
+ u32 val;
struct i2c_msg *cur;
unsigned long flags;
spin_lock_irqsave(>lock, flags);
- m_stat = readl_relaxed(gi2c->se.base + SE_GENI_M_IRQ_STATUS);
- rx_st = readl_relaxed(gi2c->se.base + SE_GENI_RX_FIFO_STATUS);
- dm_tx_st = readl_relaxed(gi2c->se.base + SE_DMA_TX_IRQ_STAT);
- dm_rx_st = readl_relaxed(gi2c->se.base + SE_DMA_RX_IRQ_STAT);
- dma = readl_relaxed(gi2c->se.base + SE_GENI_DMA_MODE_EN);
+ m_stat = readl_relaxed(base + SE_GENI_M_IRQ_STATUS);
+ rx_st = readl_relaxed(base + SE_GENI_RX_FIFO_STATUS);
+ dm_tx_st = readl_relaxed(base + SE_DMA_TX_IRQ_STAT);
+ dm_rx_st = readl_relaxed(base + SE_DMA_RX_IRQ_STAT);
+ dma = readl_relaxed(base + SE_GENI_DMA_MODE_EN);
cur = gi2c->cur;
if (!cur ||
@@ -238,26 +240,17 @@ static irqreturn_t geni_i2c_irq(int irq, void *dev)
/* Disable the TX Watermark interrupt to stop TX */
if (!dma)
- writel_relaxed(0, gi2c->se.base +
- SE_GENI_TX_WATERMARK_REG);
- goto irqret;
- }
-
- if (dma) {
+ writel_relaxed(0, base + SE_GENI_TX_WATERMARK_REG);
+ } else if (dma) {
dev_dbg(gi2c->se.dev, "i2c dma tx:0x%x, dma rx:0x%x\n",
dm_tx_st, dm_rx_st);
- goto irqret;
- }
-
- if (cur->flags & I2C_M_RD &&
- m_stat & (M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN)) {
+ } else if (cur->flags & I2C_M_RD &&
+ m_stat & (M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN)) {
u32 rxcnt = rx_st & RX_FIFO_WC_MSK;
for (j = 0; j < rxcnt; j++) {
- u32 val;
- int p = 0;
-
- val = readl_relaxed(gi2c->se.base + SE_GENI_RX_FIFOn);
+ p = 0;
+ val = readl_relaxed(base + SE_GENI_RX_FIFOn);
while (gi2c->cur_rd < cur->len && p < sizeof(val)) {
cur->buf[gi2c->cur_rd++] = val & 0xff;
val >>= 8;
@@ -270,44 +263,39 @@ static irqreturn_t geni_i2c_irq(int irq, void *dev)
m_stat & M_TX_FIFO_WATERMARK_EN) {
for (j = 0; j < gi2c->tx_wm; j++) {
u32 temp;
- u32 val = 0;
- int p = 0;
+ val = 0;
+ p = 0;
while (gi2c->cur_wr < cur->len && p < sizeof(val)) {
temp = cur->buf[gi2c->cur_wr++];
val |= temp << (p * 8);
p++;
}
- writel_relaxed(val, gi2c->se.base + SE_GENI_TX_FIFOn);
+ writel_relaxed(val, base + SE_GENI_TX_FIFOn);
/* TX Complete, Disable the TX Watermark interrupt */
if (gi2c->cur_wr == cur->len) {
- writel_relaxed(0, gi2c->se.base +
- SE_GENI_TX_WATERMARK_REG);
+ writel_relaxed(0, base +
SE_GENI_TX_WATERMARK_REG);
break;
}
}
}
-irqret:
+
if (m_stat)
- writel_relaxed(m_stat, gi2c->se.base + SE_GENI_M_IRQ_CLEAR);
+ writel_relaxed(m_stat, base + SE_GENI_M_IRQ_CLEAR);
+
+ if (dma && dm_tx_st)
+ writel_relaxed(dm_tx_st, base + SE_DMA_TX_IRQ_CLR);
+ if (dma && dm_rx_st)
+ writel_relaxed(dm_rx_st, base + SE_DMA_RX_IRQ_CLR);
- if (dma) {
- if (dm_tx_st)
- writel_relaxed(dm_tx_st, gi2c->se.base +
-
[PATCH v3 2/3] i2c: i2c-qcom-geni: Simplify tx/rx functions
We never really look at the 'ret' local variable in these functions, so
let's remove it to make way for shorter and simpler code. Furthermore,
we can shorten some lines by adding two local variables for the SE and
the message length so that everything fits in 80 columns and testing the
'dma_buf' local variable in lieu of the 'mode' local variable. And
kernel style is to leave the return statement by itself, detached from
the rest of the function.
Cc: Karthikeyan Ramasubramanian
Cc: Sagar Dharia
Cc: Girish Mahadevan
Cc: Doug Anderson
Signed-off-by: Stephen Boyd
---
drivers/i2c/busses/i2c-qcom-geni.c | 79 ++
1 file changed, 36 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 9f2eb02481d3..0b466835cf40 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -365,29 +365,24 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
u32 m_param)
{
dma_addr_t rx_dma;
- enum geni_se_xfer_mode mode;
- unsigned long time_left = XFER_TIMEOUT;
+ unsigned long time_left;
void *dma_buf;
+ struct geni_se *se = >se;
+ size_t len = msg->len;
- gi2c->cur = msg;
- mode = GENI_SE_FIFO;
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
if (dma_buf)
- mode = GENI_SE_DMA;
-
- geni_se_select_mode(>se, mode);
- writel_relaxed(msg->len, gi2c->se.base + SE_I2C_RX_TRANS_LEN);
- geni_se_setup_m_cmd(>se, I2C_READ, m_param);
- if (mode == GENI_SE_DMA) {
- int ret;
-
- ret = geni_se_rx_dma_prep(>se, dma_buf, msg->len,
- _dma);
- if (ret) {
- mode = GENI_SE_FIFO;
- geni_se_select_mode(>se, mode);
- i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
- }
+ geni_se_select_mode(se, GENI_SE_DMA);
+ else
+ geni_se_select_mode(se, GENI_SE_FIFO);
+
+ writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN);
+ geni_se_setup_m_cmd(se, I2C_READ, m_param);
+
+ if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, _dma)) {
+ geni_se_select_mode(se, GENI_SE_FIFO);
+ i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
+ dma_buf = NULL;
}
time_left = wait_for_completion_timeout(>done, XFER_TIMEOUT);
@@ -395,12 +390,13 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
geni_i2c_abort_xfer(gi2c);
gi2c->cur_rd = 0;
- if (mode == GENI_SE_DMA) {
+ if (dma_buf) {
if (gi2c->err)
geni_i2c_rx_fsm_rst(gi2c);
- geni_se_rx_dma_unprep(>se, rx_dma, msg->len);
+ geni_se_rx_dma_unprep(se, rx_dma, len);
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
+
return gi2c->err;
}
@@ -408,45 +404,41 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
u32 m_param)
{
dma_addr_t tx_dma;
- enum geni_se_xfer_mode mode;
unsigned long time_left;
void *dma_buf;
+ struct geni_se *se = >se;
+ size_t len = msg->len;
- gi2c->cur = msg;
- mode = GENI_SE_FIFO;
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
if (dma_buf)
- mode = GENI_SE_DMA;
-
- geni_se_select_mode(>se, mode);
- writel_relaxed(msg->len, gi2c->se.base + SE_I2C_TX_TRANS_LEN);
- geni_se_setup_m_cmd(>se, I2C_WRITE, m_param);
- if (mode == GENI_SE_DMA) {
- int ret;
-
- ret = geni_se_tx_dma_prep(>se, dma_buf, msg->len,
- _dma);
- if (ret) {
- mode = GENI_SE_FIFO;
- geni_se_select_mode(>se, mode);
- i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
- }
+ geni_se_select_mode(se, GENI_SE_DMA);
+ else
+ geni_se_select_mode(se, GENI_SE_FIFO);
+
+ writel_relaxed(len, se->base + SE_I2C_TX_TRANS_LEN);
+ geni_se_setup_m_cmd(se, I2C_WRITE, m_param);
+
+ if (dma_buf && geni_se_tx_dma_prep(se, dma_buf, len, _dma)) {
+ geni_se_select_mode(se, GENI_SE_FIFO);
+ i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
+ dma_buf = NULL;
}
- if (mode == GENI_SE_FIFO) /* Get FIFO IRQ */
- writel_relaxed(1, gi2c->se.base + SE_GENI_TX_WATERMARK_REG);
+ if (!dma_buf) /* Get FIFO IRQ */
+ writel_relaxed(1, se->base + SE_GENI_TX_WATERMARK_REG);
time_left = wait_for_completion_timeout(>done, XFER_TIMEOUT);
[PATCH v3 2/3] i2c: i2c-qcom-geni: Simplify tx/rx functions
We never really look at the 'ret' local variable in these functions, so
let's remove it to make way for shorter and simpler code. Furthermore,
we can shorten some lines by adding two local variables for the SE and
the message length so that everything fits in 80 columns and testing the
'dma_buf' local variable in lieu of the 'mode' local variable. And
kernel style is to leave the return statement by itself, detached from
the rest of the function.
Cc: Karthikeyan Ramasubramanian
Cc: Sagar Dharia
Cc: Girish Mahadevan
Cc: Doug Anderson
Signed-off-by: Stephen Boyd
---
drivers/i2c/busses/i2c-qcom-geni.c | 79 ++
1 file changed, 36 insertions(+), 43 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 9f2eb02481d3..0b466835cf40 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -365,29 +365,24 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
u32 m_param)
{
dma_addr_t rx_dma;
- enum geni_se_xfer_mode mode;
- unsigned long time_left = XFER_TIMEOUT;
+ unsigned long time_left;
void *dma_buf;
+ struct geni_se *se = >se;
+ size_t len = msg->len;
- gi2c->cur = msg;
- mode = GENI_SE_FIFO;
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
if (dma_buf)
- mode = GENI_SE_DMA;
-
- geni_se_select_mode(>se, mode);
- writel_relaxed(msg->len, gi2c->se.base + SE_I2C_RX_TRANS_LEN);
- geni_se_setup_m_cmd(>se, I2C_READ, m_param);
- if (mode == GENI_SE_DMA) {
- int ret;
-
- ret = geni_se_rx_dma_prep(>se, dma_buf, msg->len,
- _dma);
- if (ret) {
- mode = GENI_SE_FIFO;
- geni_se_select_mode(>se, mode);
- i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
- }
+ geni_se_select_mode(se, GENI_SE_DMA);
+ else
+ geni_se_select_mode(se, GENI_SE_FIFO);
+
+ writel_relaxed(len, se->base + SE_I2C_RX_TRANS_LEN);
+ geni_se_setup_m_cmd(se, I2C_READ, m_param);
+
+ if (dma_buf && geni_se_rx_dma_prep(se, dma_buf, len, _dma)) {
+ geni_se_select_mode(se, GENI_SE_FIFO);
+ i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
+ dma_buf = NULL;
}
time_left = wait_for_completion_timeout(>done, XFER_TIMEOUT);
@@ -395,12 +390,13 @@ static int geni_i2c_rx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
geni_i2c_abort_xfer(gi2c);
gi2c->cur_rd = 0;
- if (mode == GENI_SE_DMA) {
+ if (dma_buf) {
if (gi2c->err)
geni_i2c_rx_fsm_rst(gi2c);
- geni_se_rx_dma_unprep(>se, rx_dma, msg->len);
+ geni_se_rx_dma_unprep(se, rx_dma, len);
i2c_put_dma_safe_msg_buf(dma_buf, msg, !gi2c->err);
}
+
return gi2c->err;
}
@@ -408,45 +404,41 @@ static int geni_i2c_tx_one_msg(struct geni_i2c_dev *gi2c,
struct i2c_msg *msg,
u32 m_param)
{
dma_addr_t tx_dma;
- enum geni_se_xfer_mode mode;
unsigned long time_left;
void *dma_buf;
+ struct geni_se *se = >se;
+ size_t len = msg->len;
- gi2c->cur = msg;
- mode = GENI_SE_FIFO;
dma_buf = i2c_get_dma_safe_msg_buf(msg, 32);
if (dma_buf)
- mode = GENI_SE_DMA;
-
- geni_se_select_mode(>se, mode);
- writel_relaxed(msg->len, gi2c->se.base + SE_I2C_TX_TRANS_LEN);
- geni_se_setup_m_cmd(>se, I2C_WRITE, m_param);
- if (mode == GENI_SE_DMA) {
- int ret;
-
- ret = geni_se_tx_dma_prep(>se, dma_buf, msg->len,
- _dma);
- if (ret) {
- mode = GENI_SE_FIFO;
- geni_se_select_mode(>se, mode);
- i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
- }
+ geni_se_select_mode(se, GENI_SE_DMA);
+ else
+ geni_se_select_mode(se, GENI_SE_FIFO);
+
+ writel_relaxed(len, se->base + SE_I2C_TX_TRANS_LEN);
+ geni_se_setup_m_cmd(se, I2C_WRITE, m_param);
+
+ if (dma_buf && geni_se_tx_dma_prep(se, dma_buf, len, _dma)) {
+ geni_se_select_mode(se, GENI_SE_FIFO);
+ i2c_put_dma_safe_msg_buf(dma_buf, msg, false);
+ dma_buf = NULL;
}
- if (mode == GENI_SE_FIFO) /* Get FIFO IRQ */
- writel_relaxed(1, gi2c->se.base + SE_GENI_TX_WATERMARK_REG);
+ if (!dma_buf) /* Get FIFO IRQ */
+ writel_relaxed(1, se->base + SE_GENI_TX_WATERMARK_REG);
time_left = wait_for_completion_timeout(>done, XFER_TIMEOUT);
[PATCH v3 3/3] i2c: i2c-qcom-geni: Simplify irq handler
We don't need to use goto here, we can just collapse the if statement
and goto chain into multiple branches and then combine some duplicate
completion calls into one big if statement. Let's do it to clean up code
some more.
Cc: Karthikeyan Ramasubramanian
Cc: Sagar Dharia
Cc: Girish Mahadevan
Cc: Doug Anderson
Signed-off-by: Stephen Boyd
---
drivers/i2c/busses/i2c-qcom-geni.c | 70 +-
1 file changed, 29 insertions(+), 41 deletions(-)
diff --git a/drivers/i2c/busses/i2c-qcom-geni.c
b/drivers/i2c/busses/i2c-qcom-geni.c
index 0b466835cf40..527f55c8c4c7 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -201,21 +201,23 @@ static void geni_i2c_err(struct geni_i2c_dev *gi2c, int
err)
static irqreturn_t geni_i2c_irq(int irq, void *dev)
{
struct geni_i2c_dev *gi2c = dev;
- int j;
+ void __iomem *base = gi2c->se.base;
+ int j, p;
u32 m_stat;
u32 rx_st;
u32 dm_tx_st;
u32 dm_rx_st;
u32 dma;
+ u32 val;
struct i2c_msg *cur;
unsigned long flags;
spin_lock_irqsave(>lock, flags);
- m_stat = readl_relaxed(gi2c->se.base + SE_GENI_M_IRQ_STATUS);
- rx_st = readl_relaxed(gi2c->se.base + SE_GENI_RX_FIFO_STATUS);
- dm_tx_st = readl_relaxed(gi2c->se.base + SE_DMA_TX_IRQ_STAT);
- dm_rx_st = readl_relaxed(gi2c->se.base + SE_DMA_RX_IRQ_STAT);
- dma = readl_relaxed(gi2c->se.base + SE_GENI_DMA_MODE_EN);
+ m_stat = readl_relaxed(base + SE_GENI_M_IRQ_STATUS);
+ rx_st = readl_relaxed(base + SE_GENI_RX_FIFO_STATUS);
+ dm_tx_st = readl_relaxed(base + SE_DMA_TX_IRQ_STAT);
+ dm_rx_st = readl_relaxed(base + SE_DMA_RX_IRQ_STAT);
+ dma = readl_relaxed(base + SE_GENI_DMA_MODE_EN);
cur = gi2c->cur;
if (!cur ||
@@ -238,26 +240,17 @@ static irqreturn_t geni_i2c_irq(int irq, void *dev)
/* Disable the TX Watermark interrupt to stop TX */
if (!dma)
- writel_relaxed(0, gi2c->se.base +
- SE_GENI_TX_WATERMARK_REG);
- goto irqret;
- }
-
- if (dma) {
+ writel_relaxed(0, base + SE_GENI_TX_WATERMARK_REG);
+ } else if (dma) {
dev_dbg(gi2c->se.dev, "i2c dma tx:0x%x, dma rx:0x%x\n",
dm_tx_st, dm_rx_st);
- goto irqret;
- }
-
- if (cur->flags & I2C_M_RD &&
- m_stat & (M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN)) {
+ } else if (cur->flags & I2C_M_RD &&
+ m_stat & (M_RX_FIFO_WATERMARK_EN | M_RX_FIFO_LAST_EN)) {
u32 rxcnt = rx_st & RX_FIFO_WC_MSK;
for (j = 0; j < rxcnt; j++) {
- u32 val;
- int p = 0;
-
- val = readl_relaxed(gi2c->se.base + SE_GENI_RX_FIFOn);
+ p = 0;
+ val = readl_relaxed(base + SE_GENI_RX_FIFOn);
while (gi2c->cur_rd < cur->len && p < sizeof(val)) {
cur->buf[gi2c->cur_rd++] = val & 0xff;
val >>= 8;
@@ -270,44 +263,39 @@ static irqreturn_t geni_i2c_irq(int irq, void *dev)
m_stat & M_TX_FIFO_WATERMARK_EN) {
for (j = 0; j < gi2c->tx_wm; j++) {
u32 temp;
- u32 val = 0;
- int p = 0;
+ val = 0;
+ p = 0;
while (gi2c->cur_wr < cur->len && p < sizeof(val)) {
temp = cur->buf[gi2c->cur_wr++];
val |= temp << (p * 8);
p++;
}
- writel_relaxed(val, gi2c->se.base + SE_GENI_TX_FIFOn);
+ writel_relaxed(val, base + SE_GENI_TX_FIFOn);
/* TX Complete, Disable the TX Watermark interrupt */
if (gi2c->cur_wr == cur->len) {
- writel_relaxed(0, gi2c->se.base +
- SE_GENI_TX_WATERMARK_REG);
+ writel_relaxed(0, base +
SE_GENI_TX_WATERMARK_REG);
break;
}
}
}
-irqret:
+
if (m_stat)
- writel_relaxed(m_stat, gi2c->se.base + SE_GENI_M_IRQ_CLEAR);
+ writel_relaxed(m_stat, base + SE_GENI_M_IRQ_CLEAR);
+
+ if (dma && dm_tx_st)
+ writel_relaxed(dm_tx_st, base + SE_DMA_TX_IRQ_CLR);
+ if (dma && dm_rx_st)
+ writel_relaxed(dm_rx_st, base + SE_DMA_RX_IRQ_CLR);
- if (dma) {
- if (dm_tx_st)
- writel_relaxed(dm_tx_st, gi2c->se.base +
-
Re: [PATCH] mm: fix COW faults after mlock()
On Tue, Sep 25, 2018 at 12:22:47AM +0300, Kirill A. Shutemov wrote:
> External Email
>
> On Mon, Sep 24, 2018 at 04:08:52PM +0300, Yury Norov wrote:
> > After mlock() on newly mmap()ed shared memory I observe page faults.
> >
> > The problem is that populate_vma_page_range() doesn't set FOLL_WRITE
> > flag for writable shared memory in mlock() path, arguing that like:
> > /*
> > * We want to touch writable mappings with a write fault in order
> > * to break COW, except for shared mappings because these don't COW
> > * and we would not want to dirty them for nothing.
> > */
> >
> > But they are actually COWed. The most straightforward way to avoid it
> > is to set FOLL_WRITE flag for shared mappings as well as for private ones.
>
> Huh? How do shared mapping get CoWed?
>
> In this context CoW means to create a private copy of the page for the
> process. It only makes sense for private mappings as all pages in shared
> mappings do not belong to the process.
>
> Shared mappings will still get faults, but a bit later -- after the page
> is written back to disc, the page get clear and write protected to catch
> the next write access.
>
> Noticeable exception is tmpfs/shmem. These pages do not belong to normal
> write back process. But the code path is used for other filesystems as
> well.
>
> Therefore, NAK. You only create unneeded write back traffic.
Hi Kirill,
(My first reaction was exactly like yours indeed, but) on my real
system (Cavium OcteonTX2), and on my qemu simulation I can reproduce
the same behavior: just mlock()ed memory causes faults. That faults
happen because page is mapped to the process as read-only, while
underlying VMA is read-write. So faults get resolved well by just
setting write access to the page.
Maybe I use term COW wrongly here, but this is how faultin_page()
works, and it sets FOLL_COW bit before return (which is ignored
on upper level).
I realize that proper fix may be more complex, and if so I'll
thankfully take it and drop this patch from my tree, but this is
all that I have so far to address the problem.
The user code below is reproducer.
Thanks,
Yury
int i, ret, len = getpagesize() * 1000;
char tmpfile[] = "/tmp/my_tmp-XX";
int fd = mkstemp(tmpfile);
ret = ftruncate(fd, len);
if (ret) {
printf("Failed to ftruncate: %d\n", errno);
goto out;
}
ptr = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (ptr == MAP_FAILED) {
printf("Failed to mmap memory: %d\n", errno);
goto out;
}
ret = mlock(ptr, len);
if (ret) {
printf("Failed to mlock: %d\n", errno);
goto out;
}
printf("Touch...\n");
for (i = 0; i < len; i++)
ptr[i] = (char) i; /* Faults here. */
printf("\t... done\n");
out:
close(fd);
unlink(tmpfile);
Re: [PATCH] mm: fix COW faults after mlock()
On Tue, Sep 25, 2018 at 12:22:47AM +0300, Kirill A. Shutemov wrote:
> External Email
>
> On Mon, Sep 24, 2018 at 04:08:52PM +0300, Yury Norov wrote:
> > After mlock() on newly mmap()ed shared memory I observe page faults.
> >
> > The problem is that populate_vma_page_range() doesn't set FOLL_WRITE
> > flag for writable shared memory in mlock() path, arguing that like:
> > /*
> > * We want to touch writable mappings with a write fault in order
> > * to break COW, except for shared mappings because these don't COW
> > * and we would not want to dirty them for nothing.
> > */
> >
> > But they are actually COWed. The most straightforward way to avoid it
> > is to set FOLL_WRITE flag for shared mappings as well as for private ones.
>
> Huh? How do shared mapping get CoWed?
>
> In this context CoW means to create a private copy of the page for the
> process. It only makes sense for private mappings as all pages in shared
> mappings do not belong to the process.
>
> Shared mappings will still get faults, but a bit later -- after the page
> is written back to disc, the page get clear and write protected to catch
> the next write access.
>
> Noticeable exception is tmpfs/shmem. These pages do not belong to normal
> write back process. But the code path is used for other filesystems as
> well.
>
> Therefore, NAK. You only create unneeded write back traffic.
Hi Kirill,
(My first reaction was exactly like yours indeed, but) on my real
system (Cavium OcteonTX2), and on my qemu simulation I can reproduce
the same behavior: just mlock()ed memory causes faults. That faults
happen because page is mapped to the process as read-only, while
underlying VMA is read-write. So faults get resolved well by just
setting write access to the page.
Maybe I use term COW wrongly here, but this is how faultin_page()
works, and it sets FOLL_COW bit before return (which is ignored
on upper level).
I realize that proper fix may be more complex, and if so I'll
thankfully take it and drop this patch from my tree, but this is
all that I have so far to address the problem.
The user code below is reproducer.
Thanks,
Yury
int i, ret, len = getpagesize() * 1000;
char tmpfile[] = "/tmp/my_tmp-XX";
int fd = mkstemp(tmpfile);
ret = ftruncate(fd, len);
if (ret) {
printf("Failed to ftruncate: %d\n", errno);
goto out;
}
ptr = mmap(NULL, len, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (ptr == MAP_FAILED) {
printf("Failed to mmap memory: %d\n", errno);
goto out;
}
ret = mlock(ptr, len);
if (ret) {
printf("Failed to mlock: %d\n", errno);
goto out;
}
printf("Touch...\n");
for (i = 0; i < len; i++)
ptr[i] = (char) i; /* Faults here. */
printf("\t... done\n");
out:
close(fd);
unlink(tmpfile);
[PATCH V5 29/30] dt-bindings: timer: gx6605s SOC timer
- Dt-bindings doc for gx6605s SOC's system timer.
Signed-off-by: Guo Ren
Reviewed-by: Rob Herring
---
.../bindings/timer/csky,gx6605s-timer.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
new file mode 100644
index 000..6b04344
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
@@ -0,0 +1,42 @@
+=
+gx6605s SOC Timer
+=
+
+The timer is used in gx6605s soc as system timer and the driver
+contain clk event and clk source.
+
+==
+timer node bindings definition
+==
+
+ Description: Describes gx6605s SOC timer
+
+ PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: must be "csky,gx6605s-timer"
+ - reg
+ Usage: required
+ Value type:
+ Definition: in soc from cpu view
+ - clocks
+ Usage: required
+ Value type: phandle + clock specifier cells
+ Definition: must be input clk node
+ - interrupt
+ Usage: required
+ Value type:
+ Definition: must be timer irq num defined by soc
+
+Examples:
+-
+
+ timer0: timer@20a000 {
+ compatible = "csky,gx6605s-timer";
+ reg = <0x0020a000 0x400>;
+ clocks = <_apb_clk>;
+ interrupts = <10>;
+ interrupt-parent = <>;
+ };
--
2.7.4
[PATCH V5 30/30] clocksource: add gx6605s SOC system timer
Changelog:
- Add COMPILE_TEST in Kconfig
- Add License and Copyright
- Use timer-of framework
- Change name with upstream feedback
- Use clksource_mmio framework
Signed-off-by: Guo Ren
---
drivers/clocksource/Kconfig | 8 ++
drivers/clocksource/Makefile| 1 +
drivers/clocksource/timer-gx6605s.c | 150
3 files changed, 159 insertions(+)
create mode 100644 drivers/clocksource/timer-gx6605s.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a28043f..3dc24ca 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -628,4 +628,12 @@ config CSKY_MPTIMER
Say yes here to enable C-SKY SMP timer driver used for C-SKY SMP
system.
+config GX6605S_TIMER
+ bool "Gx6605s SOC system timer driver" if COMPILE_TEST
+ depends on CSKY
+ select CLKSRC_MMIO
+ select TIMER_OF
+ help
+ This option enables support for gx6605s SOC's timer.
+
endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 848c676..7a1b0f4 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_X86_NUMACHIP)+= numachip.o
obj-$(CONFIG_ATCPIT100_TIMER) += timer-atcpit100.o
obj-$(CONFIG_RISCV_TIMER) += riscv_timer.o
obj-$(CONFIG_CSKY_MPTIMER) += csky_mptimer.o
+obj-$(CONFIG_GX6605S_TIMER)+= timer-gx6605s.o
diff --git a/drivers/clocksource/timer-gx6605s.c
b/drivers/clocksource/timer-gx6605s.c
new file mode 100644
index 000..3974ede
--- /dev/null
+++ b/drivers/clocksource/timer-gx6605s.c
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include
+#include
+#include
+
+#include "timer-of.h"
+
+#define CLKSRC_OFFSET 0x40
+
+#define TIMER_STATUS 0x00
+#define TIMER_VALUE0x04
+#define TIMER_CONTRL 0x10
+#define TIMER_CONFIG 0x20
+#define TIMER_DIV 0x24
+#define TIMER_INI 0x28
+
+#define GX6605S_STATUS_CLR BIT(0)
+#define GX6605S_CONTRL_RST BIT(0)
+#define GX6605S_CONTRL_START BIT(1)
+#define GX6605S_CONFIG_EN BIT(0)
+#define GX6605S_CONFIG_IRQ_EN BIT(1)
+
+static irqreturn_t gx6605s_timer_interrupt(int irq, void *dev)
+{
+ struct clock_event_device *ce = dev;
+ void __iomem *base = timer_of_base(to_timer_of(ce));
+
+ writel_relaxed(GX6605S_STATUS_CLR, base + TIMER_STATUS);
+
+ ce->event_handler(ce);
+
+ return IRQ_HANDLED;
+}
+
+static int gx6605s_timer_set_oneshot(struct clock_event_device *ce)
+{
+ void __iomem *base = timer_of_base(to_timer_of(ce));
+
+ /* reset and stop counter */
+ writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+ /* enable with irq and start */
+ writel_relaxed(GX6605S_CONFIG_EN | GX6605S_CONFIG_IRQ_EN, base +
TIMER_CONFIG);
+
+ return 0;
+}
+
+static int gx6605s_timer_set_next_event(unsigned long delta, struct
clock_event_device *ce)
+{
+ void __iomem *base = timer_of_base(to_timer_of(ce));
+
+ /* use reset to pause timer */
+ writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+ /* config next timeout value */
+ writel_relaxed(ULONG_MAX - delta, base + TIMER_INI);
+ writel_relaxed(GX6605S_CONTRL_START, base + TIMER_CONTRL);
+
+ return 0;
+}
+
+static int gx6605s_timer_shutdown(struct clock_event_device *ce)
+{
+ void __iomem *base = timer_of_base(to_timer_of(ce));
+
+ writel_relaxed(0, base + TIMER_CONTRL);
+ writel_relaxed(0, base + TIMER_CONFIG);
+
+ return 0;
+}
+
+static struct timer_of to = {
+ .flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
+ .clkevt = {
+ .rating = 300,
+ .features = CLOCK_EVT_FEAT_DYNIRQ |
+ CLOCK_EVT_FEAT_ONESHOT,
+ .set_state_shutdown = gx6605s_timer_shutdown,
+ .set_state_oneshot = gx6605s_timer_set_oneshot,
+ .set_next_event = gx6605s_timer_set_next_event,
+ .cpumask= cpu_possible_mask,
+ },
+ .of_irq = {
+ .handler= gx6605s_timer_interrupt,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
+ },
+};
+
+static u64 notrace gx6605s_sched_clock_read(void)
+{
+ void __iomem *base;
+
+ base = timer_of_base() + CLKSRC_OFFSET;
+
+ return (u64)readl_relaxed(base + TIMER_VALUE);
+}
+
+static void gx6605s_clkevt_init(void __iomem *base)
+{
+ writel_relaxed(0, base + TIMER_DIV);
+ writel_relaxed(0, base + TIMER_CONFIG);
+
+ clockevents_config_and_register(, timer_of_rate(), 2,
ULONG_MAX);
+}
+
+static int gx6605s_clksrc_init(void __iomem *base)
+{
+ writel_relaxed(0, base + TIMER_DIV);
+ writel_relaxed(0, base + TIMER_INI);
+
+
[PATCH V5 29/30] dt-bindings: timer: gx6605s SOC timer
- Dt-bindings doc for gx6605s SOC's system timer.
Signed-off-by: Guo Ren
Reviewed-by: Rob Herring
---
.../bindings/timer/csky,gx6605s-timer.txt | 42 ++
1 file changed, 42 insertions(+)
create mode 100644
Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
diff --git a/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
new file mode 100644
index 000..6b04344
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt
@@ -0,0 +1,42 @@
+=
+gx6605s SOC Timer
+=
+
+The timer is used in gx6605s soc as system timer and the driver
+contain clk event and clk source.
+
+==
+timer node bindings definition
+==
+
+ Description: Describes gx6605s SOC timer
+
+ PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: must be "csky,gx6605s-timer"
+ - reg
+ Usage: required
+ Value type:
+ Definition: in soc from cpu view
+ - clocks
+ Usage: required
+ Value type: phandle + clock specifier cells
+ Definition: must be input clk node
+ - interrupt
+ Usage: required
+ Value type:
+ Definition: must be timer irq num defined by soc
+
+Examples:
+-
+
+ timer0: timer@20a000 {
+ compatible = "csky,gx6605s-timer";
+ reg = <0x0020a000 0x400>;
+ clocks = <_apb_clk>;
+ interrupts = <10>;
+ interrupt-parent = <>;
+ };
--
2.7.4
[PATCH V5 30/30] clocksource: add gx6605s SOC system timer
Changelog:
- Add COMPILE_TEST in Kconfig
- Add License and Copyright
- Use timer-of framework
- Change name with upstream feedback
- Use clksource_mmio framework
Signed-off-by: Guo Ren
---
drivers/clocksource/Kconfig | 8 ++
drivers/clocksource/Makefile| 1 +
drivers/clocksource/timer-gx6605s.c | 150
3 files changed, 159 insertions(+)
create mode 100644 drivers/clocksource/timer-gx6605s.c
diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index a28043f..3dc24ca 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -628,4 +628,12 @@ config CSKY_MPTIMER
Say yes here to enable C-SKY SMP timer driver used for C-SKY SMP
system.
+config GX6605S_TIMER
+ bool "Gx6605s SOC system timer driver" if COMPILE_TEST
+ depends on CSKY
+ select CLKSRC_MMIO
+ select TIMER_OF
+ help
+ This option enables support for gx6605s SOC's timer.
+
endmenu
diff --git a/drivers/clocksource/Makefile b/drivers/clocksource/Makefile
index 848c676..7a1b0f4 100644
--- a/drivers/clocksource/Makefile
+++ b/drivers/clocksource/Makefile
@@ -80,3 +80,4 @@ obj-$(CONFIG_X86_NUMACHIP)+= numachip.o
obj-$(CONFIG_ATCPIT100_TIMER) += timer-atcpit100.o
obj-$(CONFIG_RISCV_TIMER) += riscv_timer.o
obj-$(CONFIG_CSKY_MPTIMER) += csky_mptimer.o
+obj-$(CONFIG_GX6605S_TIMER)+= timer-gx6605s.o
diff --git a/drivers/clocksource/timer-gx6605s.c
b/drivers/clocksource/timer-gx6605s.c
new file mode 100644
index 000..3974ede
--- /dev/null
+++ b/drivers/clocksource/timer-gx6605s.c
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include
+#include
+#include
+
+#include "timer-of.h"
+
+#define CLKSRC_OFFSET 0x40
+
+#define TIMER_STATUS 0x00
+#define TIMER_VALUE0x04
+#define TIMER_CONTRL 0x10
+#define TIMER_CONFIG 0x20
+#define TIMER_DIV 0x24
+#define TIMER_INI 0x28
+
+#define GX6605S_STATUS_CLR BIT(0)
+#define GX6605S_CONTRL_RST BIT(0)
+#define GX6605S_CONTRL_START BIT(1)
+#define GX6605S_CONFIG_EN BIT(0)
+#define GX6605S_CONFIG_IRQ_EN BIT(1)
+
+static irqreturn_t gx6605s_timer_interrupt(int irq, void *dev)
+{
+ struct clock_event_device *ce = dev;
+ void __iomem *base = timer_of_base(to_timer_of(ce));
+
+ writel_relaxed(GX6605S_STATUS_CLR, base + TIMER_STATUS);
+
+ ce->event_handler(ce);
+
+ return IRQ_HANDLED;
+}
+
+static int gx6605s_timer_set_oneshot(struct clock_event_device *ce)
+{
+ void __iomem *base = timer_of_base(to_timer_of(ce));
+
+ /* reset and stop counter */
+ writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+ /* enable with irq and start */
+ writel_relaxed(GX6605S_CONFIG_EN | GX6605S_CONFIG_IRQ_EN, base +
TIMER_CONFIG);
+
+ return 0;
+}
+
+static int gx6605s_timer_set_next_event(unsigned long delta, struct
clock_event_device *ce)
+{
+ void __iomem *base = timer_of_base(to_timer_of(ce));
+
+ /* use reset to pause timer */
+ writel_relaxed(GX6605S_CONTRL_RST, base + TIMER_CONTRL);
+
+ /* config next timeout value */
+ writel_relaxed(ULONG_MAX - delta, base + TIMER_INI);
+ writel_relaxed(GX6605S_CONTRL_START, base + TIMER_CONTRL);
+
+ return 0;
+}
+
+static int gx6605s_timer_shutdown(struct clock_event_device *ce)
+{
+ void __iomem *base = timer_of_base(to_timer_of(ce));
+
+ writel_relaxed(0, base + TIMER_CONTRL);
+ writel_relaxed(0, base + TIMER_CONFIG);
+
+ return 0;
+}
+
+static struct timer_of to = {
+ .flags = TIMER_OF_IRQ | TIMER_OF_BASE | TIMER_OF_CLOCK,
+ .clkevt = {
+ .rating = 300,
+ .features = CLOCK_EVT_FEAT_DYNIRQ |
+ CLOCK_EVT_FEAT_ONESHOT,
+ .set_state_shutdown = gx6605s_timer_shutdown,
+ .set_state_oneshot = gx6605s_timer_set_oneshot,
+ .set_next_event = gx6605s_timer_set_next_event,
+ .cpumask= cpu_possible_mask,
+ },
+ .of_irq = {
+ .handler= gx6605s_timer_interrupt,
+ .flags = IRQF_TIMER | IRQF_IRQPOLL,
+ },
+};
+
+static u64 notrace gx6605s_sched_clock_read(void)
+{
+ void __iomem *base;
+
+ base = timer_of_base() + CLKSRC_OFFSET;
+
+ return (u64)readl_relaxed(base + TIMER_VALUE);
+}
+
+static void gx6605s_clkevt_init(void __iomem *base)
+{
+ writel_relaxed(0, base + TIMER_DIV);
+ writel_relaxed(0, base + TIMER_CONFIG);
+
+ clockevents_config_and_register(, timer_of_rate(), 2,
ULONG_MAX);
+}
+
+static int gx6605s_clksrc_init(void __iomem *base)
+{
+ writel_relaxed(0, base + TIMER_DIV);
+ writel_relaxed(0, base + TIMER_INI);
+
+
[PATCH V5 27/30] dt-bindings: interrupt-controller: C-SKY APB intc
- Dt-bindings doc about C-SKY apb bus interrupt controller.
Signed-off-by: Guo Ren
---
.../interrupt-controller/csky,apb-intc.txt | 62 ++
1 file changed, 62 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
new file mode 100644
index 000..44286dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt
@@ -0,0 +1,62 @@
+==
+C-SKY APB Interrupt Controller
+==
+
+C-SKY APB Interrupt Controller is a simple soc interrupt controller
+on the apb bus and we only use it as root irq controller.
+
+ - csky,apb-intc is used in a lot of csky fpgas and socs, it support 64 irq
nums.
+ - csky,dual-apb-intc consists of 2 apb-intc and 128 irq nums supported.
+ - csky,gx6605s-intc is gx6605s soc internal irq interrupt controller, 64 irq
nums.
+
+=
+intc node bindings definition
+=
+
+ Description: Describes APB interrupt controller
+
+ PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: must be "csky,apb-intc"
+ "csky,dual-apb-intc"
+ "csky,gx6605s-intc"
+ - #interrupt-cells
+ Usage: required
+ Value type:
+ Definition: must be <1>
+ - reg
+ Usage: required
+ Value type:
+ Definition: in soc from cpu view
+ - interrupt-controller:
+ Usage: required
+ - csky,support-pulse-signal:
+ Usage: select
+ Description: to support pulse signal flag
+
+Examples:
+-
+
+ intc: interrupt-controller@50 {
+ compatible = "csky,apb-intc";
+ #interrupt-cells = <1>;
+ reg = <0x0050 0x400>;
+ interrupt-controller;
+ };
+
+ intc: interrupt-controller@50 {
+ compatible = "csky,dual-apb-intc";
+ #interrupt-cells = <1>;
+ reg = <0x0050 0x400>;
+ interrupt-controller;
+ };
+
+ intc: interrupt-controller@50 {
+ compatible = "csky,gx6605s-intc";
+ #interrupt-cells = <1>;
+ reg = <0x0050 0x400>;
+ interrupt-controller;
+ };
--
2.7.4
[PATCH V5 26/30] MAINTAINERS: Add csky
Add a maintainer information for the csky(C-SKY) architecture. Signed-off-by: Guo Ren --- MAINTAINERS | 16 1 file changed, 16 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index d870cb5..6b7c1be 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3211,6 +3211,22 @@ T: git git://git.alsa-project.org/alsa-kernel.git S: Maintained F: sound/pci/oxygen/ +C-SKY ARCHITECTURE +M: Guo Ren +T: git https://github.com/c-sky/csky-linux.git +S: Supported +F: arch/csky/ +F: Documentation/devicetree/bindings/interrupt-controller/csky,mpintc.txt +F: drivers/irqchip/irq-csky-mpintc.c +F: Documentation/devicetree/bindings/interrupt-controller/csky,apb-intc.txt +F: drivers/irqchip/irq-csky-apb-intc.c +F: Documentation/devicetree/bindings/timer/csky,mptimer.txt +F: drivers/clocksource/csky_mptimer.c +F: Documentation/devicetree/bindings/timer/csky,gx6605s-timer.txt +F: drivers/clocksource/timer-gx6605s.c +K: csky +N: csky + C6X ARCHITECTURE M: Mark Salter M: Aurelien Jacquiot -- 2.7.4
[PATCH V5 28/30] irqchip: add C-SKY APB bus interrupt controller
- irq-csky-apb-intc is a simple SOC interrupt controller which is
used in a lot of C-SKY CPU SOC products.
Changelog:
- use "bool ret" instead of "int ret"
- add support-pulse-signal in irq-csky-apb-intc.c
- change name with upstream feed-back
- add INTC_IFR to clear irq-pending
- remove CSKY_VECIRQ_LEGENCY
- change to generic irq chip framework
- add License and Copyright
- use irq_domain_add_linear instead of leagcy
Signed-off-by: Guo Ren
---
drivers/irqchip/Kconfig | 8 ++
drivers/irqchip/Makefile| 1 +
drivers/irqchip/irq-csky-apb-intc.c | 260
3 files changed, 269 insertions(+)
create mode 100644 drivers/irqchip/irq-csky-apb-intc.c
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 92e1c20..bf12549 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -379,6 +379,14 @@ config CSKY_MPINTC
for C-SKY SMP system. In fact it's not mmio map and it use ld/st
to visit the controller's register inside CPU.
+config CSKY_APB_INTC
+ bool "C-SKY APB Interrupt Controller"
+ depends on CSKY
+ help
+ Say yes here to enable C-SKY APB interrupt controller driver used
+ by C-SKY single core SOC system. It use mmio map apb-bus to visit
+ the controller's register.
+
endmenu
config SIFIVE_PLIC
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 6b739ea..72eaf53 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -88,4 +88,5 @@ obj-$(CONFIG_GOLDFISH_PIC)+= irq-goldfish-pic.o
obj-$(CONFIG_NDS32)+= irq-ativic32.o
obj-$(CONFIG_QCOM_PDC) += qcom-pdc.o
obj-$(CONFIG_CSKY_MPINTC) += irq-csky-mpintc.o
+obj-$(CONFIG_CSKY_APB_INTC)+= irq-csky-apb-intc.o
obj-$(CONFIG_SIFIVE_PLIC) += irq-sifive-plic.o
diff --git a/drivers/irqchip/irq-csky-apb-intc.c
b/drivers/irqchip/irq-csky-apb-intc.c
new file mode 100644
index 000..cfe32a7
--- /dev/null
+++ b/drivers/irqchip/irq-csky-apb-intc.c
@@ -0,0 +1,260 @@
+// SPDX-License-Identifier: GPL-2.0
+// Copyright (C) 2018 Hangzhou C-SKY Microsystems co.,ltd.
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define INTC_IRQS 64
+
+#define CK_INTC_ICR0x00
+#define CK_INTC_PEN31_00 0x14
+#define CK_INTC_PEN63_32 0x2c
+#define CK_INTC_NEN31_00 0x10
+#define CK_INTC_NEN63_32 0x28
+#define CK_INTC_SOURCE 0x40
+#define CK_INTC_DUAL_BASE 0x100
+
+#define GX_INTC_PEN31_00 0x00
+#define GX_INTC_PEN63_32 0x04
+#define GX_INTC_NEN31_00 0x40
+#define GX_INTC_NEN63_32 0x44
+#define GX_INTC_NMASK31_00 0x50
+#define GX_INTC_NMASK63_32 0x54
+#define GX_INTC_SOURCE 0x60
+
+static void __iomem *reg_base;
+static struct irq_domain *root_domain;
+
+static int nr_irq = INTC_IRQS;
+
+/*
+ * When controller support pulse signal, the PEN_reg will hold on signal
+ * without software trigger.
+ *
+ * So, to support pulse signal we need to clear IFR_reg and the address of
+ * IFR_offset is NEN_offset - 8.
+ */
+static void irq_ck_mask_set_bit(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+ unsigned long ifr = ct->regs.mask - 8;
+ u32 mask = d->mask;
+
+ irq_gc_lock(gc);
+ *ct->mask_cache |= mask;
+ irq_reg_writel(gc, *ct->mask_cache, ct->regs.mask);
+ irq_reg_writel(gc, irq_reg_readl(gc, ifr) & ~mask, ifr);
+ irq_gc_unlock(gc);
+}
+
+static void __init ck_set_gc(struct device_node *node, void __iomem *reg_base,
+u32 mask_reg, u32 irq_base)
+{
+ struct irq_chip_generic *gc;
+
+ gc = irq_get_domain_generic_chip(root_domain, irq_base);
+ gc->reg_base = reg_base;
+ gc->chip_types[0].regs.mask = mask_reg;
+ gc->chip_types[0].chip.irq_mask = irq_gc_mask_clr_bit;
+ gc->chip_types[0].chip.irq_unmask = irq_gc_mask_set_bit;
+
+ if (of_find_property(node, "csky,support-pulse-signal", NULL))
+ gc->chip_types[0].chip.irq_unmask = irq_ck_mask_set_bit;
+}
+
+static inline u32 build_channel_val(u32 idx, u32 magic)
+{
+ u32 res;
+
+ /*
+* Set the same index for each channel
+*/
+ res = idx | (idx << 8) | (idx << 16) | (idx << 24);
+
+ /*
+* Set the channel magic number in descending order.
+* The magic is 0x00010203 for ck-intc
+* The magic is 0x03020100 for gx6605s-intc
+*/
+ return res | magic;
+}
+
+static inline void setup_irq_channel(u32 magic, void __iomem *reg_addr)
+{
+ u32 i;
+
+ /* Setup 64 channel slots */
+ for (i = 0; i < INTC_IRQS; i += 4) {
+ writel_relaxed(build_channel_val(i, magic), reg_addr + i);
+
[PATCH V5 25/30] dt-bindings: timer: C-SKY Multi-processor timer
- Dt-bingdings doc for C-SKY SMP system setting.
Signed-off-by: Guo Ren
---
.../devicetree/bindings/timer/csky,mptimer.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/timer/csky,mptimer.txt
diff --git a/Documentation/devicetree/bindings/timer/csky,mptimer.txt
b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
new file mode 100644
index 000..1e7e31d
--- /dev/null
+++ b/Documentation/devicetree/bindings/timer/csky,mptimer.txt
@@ -0,0 +1,46 @@
+
+C-SKY Multi-processors Timer
+
+
+C-SKY multi-processors timer is designed for C-SKY SMP system and the
+regs is accessed by cpu co-processor 4 registers with mtcr/mfcr.
+
+ - PTIM_CTLR "cr<0, 14>" Control reg to start reset timer.
+ - PTIM_TSR "cr<1, 14>" Interrupt cleanup status reg.
+ - PTIM_CCVR "cr<3, 14>" Current counter value reg.
+ - PTIM_LVR "cr<6, 14>" Window value reg to triger next event.
+
+==
+timer node bindings definition
+==
+
+ Description: Describes SMP timer
+
+ PROPERTIES
+
+ - compatible
+ Usage: required
+ Value type:
+ Definition: must be "csky,mptimer"
+ - clocks
+ Usage: required
+ Value type:
+ Definition: must be input clk node
+ - interrupts
+ Usage: required
+ Value type:
+ Definition: must be timer irq num defined by soc
+ - interrupt-parent:
+ Usage: required
+ Value type:
+ Definition: must be interrupt controller node
+
+Examples:
+-
+
+ timer: timer {
+ compatible = "csky,mptimer";
+ clocks = <_apb_clk>;
+ interrupts = <16>;
+ interrupt-parent = <>;
+ };
--
2.7.4
