Re: [PATCH v2 3/4] power: Add support for DA9150 Fuel-Gauge
On Mon, 06 Jul 2015, Opensource [Adam Thomson] wrote: > On July 3, 2015 16:22, Lee Jones wrote: > > > > +/* > > > + * Function template to provide battery temperature. Should provide > > > + * 0.1 degrees C resolution return values. > > > + */ > > > +typedef int (*da9150_read_temp_t)(void *context); > > > + > > > +/* Register temp callback function */ > > > +void da9150_fg_register_temp_cb(struct power_supply *psy, > > da9150_read_temp_t cb, > > > + void *cb_context); > > > + > > > #endif /* __DA9150_FG_H */ > > > > I still don't get why you think pointers are better than just calling > > the function directly. Can the *fn() ever point to different functions? > > Here, the intention is to cover the scenario where a battery has no internal > thermistor, and cannot provide temperature readings to the DA9150 device. In > that scenario I've allowed for the option of providing an external function > which can give the temperature reading instead as DA9150 will not be able to > provide a correct reading in that scenario. This would be platform dependent > and > such a platform using a battery not employing an NTC in their battery can > register its own call-back function to provide battery temperature instead. > > So, in answer to your question, yes. Before you add this scenario, I would like to see the code which utilises it. I'm not a fan of coding-up 'just-in-case's. Please re-submit when you have a user in the same patch-set. This whole idea will need a discussion with Jonathan (the IIO Maintainer), now CC'ed. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] dt-bindings: ARM: Mediatek: Document devicetree bindings for clock controllers
Hi Daniel,
On Fri, 2015-07-03 at 18:46 +0800, Daniel Kurtz wrote:
> On Fri, Jul 3, 2015 at 7:40 AM, Stephen Boyd wrote:
> > DT nodes typically have a reg property. Not having a reg property is a
> > good indicator of a problem with the binding. A syscon is used when you
> > have a DT node with a reg property and some driver attached to it, but
> > you need to poke some bits in another register region that isn't part of
> > the reg property. Instead of having multiple nodes with two reg
> > properties where the second one is the same, we use a phandle and a syscon.
> >
> > If clock-controller isn't acceptable maybe clock-reset-contoller would
> > work? Or "power-controller"? We certainly shouldn't be making up
> > multiple nodes for one hardware block. Of course, the subject of the
> > patch is "bindings for clock controllers", so it may be that the
> > registers are predominantly clock related and so the name is appropriate
> > already.
>
> Using "clock-controller" seems to fit best with the bindings
> introduced by this patch.
>
> However, if these bindings are for hardware blocks that contain a grab
> bag of various functionality that will be added in later patches, then
> I think "syscon" might be best.
I referred some dt-binding documents that contain clock and reset
controller in the same unit:
qcom,gcc.txt:
clock-controller@90 {
compatible = "qcom,gcc-msm8960";
nvidia,tegra124-car.txt:
tegra_car: clock {
compatible = "nvidia,tegra124-car";
rockchip,rk3188-cru.txt:
cru: cru@2000 {
compatible = "rockchip,rk3188-cru";
Rockchip use "Clock and Reset Unit" as their controller's name. The
other two use "clock" or "clock-controller" as their controller's name.
It looks like "clock-controller" is also an acceptable name for
clock/reset controllers. So I would like to keep this name in next
patch.
Best regards,
James
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:x86/platform] x86/platform/intel/pmc_atom: Add Cherrytrail PMC interface
* Peter Zijlstra wrote: > On Mon, Jul 06, 2015 at 09:35:33AM -0700, tip-bot for Kumar P Mahesh wrote: > > Commit-ID: daf61e1b7fc31d553fe3bf2dead95d9404ad0f57 > > Gitweb: > > http://git.kernel.org/tip/daf61e1b7fc31d553fe3bf2dead95d9404ad0f57 > > Author: Kumar P Mahesh > > AuthorDate: Mon, 6 Jul 2015 17:29:03 +0300 > > Committer: Ingo Molnar > > CommitDate: Mon, 6 Jul 2015 17:50:59 +0200 > > > > x86/platform/intel/pmc_atom: Add Cherrytrail PMC interface > > > > The patch adds CHT PMC interface. This exposes all the South IP device > > power > > states and S0ix states for CHT. The bit map of FUNC_DIS and D3_STS_0 > > registers > > for SoCs are consistent. The D3_STS_1 and FUNC_DIS_2 registers, however, > > are > > not aligned. This is fixed by splitting a common mapping on per register > > basis. > > TLA collision.. I thought this was about performance monitor counters :/ I had to look twice as well - but PMC as 'Power Management Controller' in used in the kernel consistently in a number of places. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi-cpufreq.c: fix a memory leak in acpi_cpufreq_cpu_exit
On 06-07-15, 14:30, Pan Xinhui wrote: > > policy->cpu in acpi_cpufreq_cpu_init/exit is the same cpu in most cases. > However during cpu hotplug, > cpufreq core might nominate a new cpu for policy->cpu. Why aren't above lines well aligned? A simple trick to share for vim users: - Select lines you want to auto-align with shift+v and up-down keys - press gq - That's it and vim will do it for you. You need to set vim's 'textwidth' to 72 or 80, based on what you are editing, so that vim knows where you need to break the line. I have this in vimrc set textwidth=80 au FileType gitcommit set textwidth=72 Back to the real stuff. Few core changes have gone into v4.2-rc1 and policy->cpu doesn't change any longer on hotplug (unless its a physical hotplug). So you shouldn't see any issues. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] usb: usleep_range is preferred over udelay where wakeup is flexible
According to Documentation/timers/timers-howto.txt"
udelay() is only called once from a place where sleeping is allowed.
We can replace it with a call to usleep_range()
with a reasonable upper limit.
This is new version of patch created after discussion.
Signed-off-by: Sunny Kumar
---
drivers/usb/storage/transport.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/storage/transport.c b/drivers/usb/storage/transport.c
index 540add2..5e67f63 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -,7 +,7 @@ int usb_stor_Bulk_transport(struct scsi_cmnd *srb, struct
us_data *us)
* command phase and the data phase. Some devices need a little
* more than that, probably because of clock rate inaccuracies. */
if (unlikely(us->fflags & US_FL_GO_SLOW))
- udelay(125);
+ usleep_range(125, 150);
if (transfer_length) {
unsigned int pipe = srb->sc_data_direction == DMA_FROM_DEVICE ?
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] x86/mm/pat, drivers/media/ivtv: move pat warn and replace WARN() with pr_warn()
On Mon, Jul 6, 2015 at 5:44 PM, Luis R. Rodriguez wrote: > If we really wanted to we could consider arch_phys_wc_add() I mean adding a __arch_phys_wc_add() which does not check for pat_enabled(). > and > deal with that this will not check for pat_enabled() and forces MTRR... > I think Andy Luto won't like that very much though ? I at least don't > like it since we did all this work to finally leave only 1 piece of > code with direct MTRR access... Seems a bit sad. Since ipath will > be removed we'd have only ivtv driver using this API, I am not sure if > its worth it. Since ipath is going away soon we'd just have one driver with the icky #ifdef code. I'd rather see that and then require semantics / grammer rules to require ioremap_wc() when used with arch_phys_wc_add(). I don't think ivtv is worth to consider breaking the semantics and requirements. > Thoughts? Luis -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] w1: Use module_pci_driver
Use module_pci_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return pci_register_driver(&x); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { pci_unregister_driver(&x); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_pci_driver;
@@
-module_exit(e);
+module_pci_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/w1/masters/matrox_w1.c | 14 +-
1 file changed, 1 insertion(+), 13 deletions(-)
diff --git a/drivers/w1/masters/matrox_w1.c b/drivers/w1/masters/matrox_w1.c
index d8667b0..684bc9d 100644
--- a/drivers/w1/masters/matrox_w1.c
+++ b/drivers/w1/masters/matrox_w1.c
@@ -232,16 +232,4 @@ static void matrox_w1_remove(struct pci_dev *pdev)
}
kfree(dev);
}
-
-static int __init matrox_w1_init(void)
-{
- return pci_register_driver(&matrox_w1_pci_driver);
-}
-
-static void __exit matrox_w1_fini(void)
-{
- pci_unregister_driver(&matrox_w1_pci_driver);
-}
-
-module_init(matrox_w1_init);
-module_exit(matrox_w1_fini);
+module_pci_driver(matrox_w1_pci_driver);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND 00/10] regulator: pwm-regulator: Introduce continuous-mode
On Mon, 06 Jul 2015, Mark Brown wrote: > On Mon, Jul 06, 2015 at 09:58:22AM +0100, Lee Jones wrote: > > This patch-set has been rebased on to v4.2-rc1. > > Is this just a rebase or has the code been changed as well - IIRC there > were some bits in there that weren't supposed to be be there? This is a rebased resend with those couple of lines of debug removed. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 6/8] mfd: make mfd_remove_devices() iterate in reverse order
On Tue, 07 Jul 2015, Rafael J. Wysocki wrote: > On Monday, July 06, 2015 05:05:29 PM Lee Jones wrote: > > On Mon, 06 Jul 2015, Andy Shevchenko wrote: > > > > > On Mon, Jul 6, 2015 at 5:50 PM, Lee Jones wrote: > > > > On Mon, 06 Jul 2015, Andy Shevchenko wrote: > > > > > > > >> On Mon, 2015-07-06 at 11:24 +0200, Geert Uytterhoeven wrote: > > > >> > On Mon, Jul 6, 2015 at 11:10 AM, Andy Shevchenko > > > >> > wrote: > > > >> > > On Wed, 2015-06-24 at 12:31 +0100, Lee Jones wrote: > > > >> > > > On Mon, 15 Jun 2015, Andy Shevchenko wrote: > > > > > > [] > > > > > > >> > > > Applied, thanks. > > > >> > > > > > >> > > Hmm… Seems kinda mistake. I can't see this applied (and required > > > >> > > previous patches 4 and 5) to any of your branch neither in > > > >> > > (today's) > > > >> > > linux-next. > > > >> > > > > >> > New stuff applied after v4.1 couldn't show up in -next before v4.2 > > > >> > -rc1 was > > > >> > released (which just happened last night)? > > > >> > > > >> Might be, I would like to resend new version of my series and that's > > > >> why I would like to have a branch to check what is already applied. So, > > > >> if I can't see it does it mean it is brewed in the private repository? > > > > > > > > If you have patches that depend on this, they either need to come > > > > through my tree, or you have to wait until the next kernel version > > > > (which you probably don't want, right?). > > > > > > > > The alternative is that I unapply this patch and the whole lot can be > > > > sucked up by the most appropriate subsystem. > > > > > > I resent a new version for other comments(still with all patches > > > included). Meanwhile the patches 4-6 (from v4 or v5, where they are > > > the same) could be applied in the first place. Can you clarify what > > > exactly you have applied? The idea is to put the rest via your > > > subsystem since it's most appropriate for this series. > > > > Easiest thing for me to do is unapply. > > > > We can take the whole series when all the Acks have been accrued. > > So are there any ACKs missing from the last series posted by Andy? Yes, I have requested a Clk Ack, as there are some, lets say interesting code in the MFD driver which I am unsure about. However, we have caught Mike at an awkward time, as he is in the middle of transitioning jobs. Perhaps Stephen Boyd (now Cc'ed) might have a look. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rtc/ds3232: fix ds3232 get a WARNING trace in resume function
From: Wang Dongsheng
If ds3232 work on some platform that is not implementation
irq_set_wake, ds3232 will get a WARNING trace in resume.
So fix ds3232->suspended state to false when irq_set_irq_wake
return error.
[ cut here ]
WARNING: CPU: 0 PID: 729 at kernel/irq/manage.c:604
irq_set_irq_wake+0x4b/0x8c()
Unbalanced IRQ 201 wake disable
Modules linked in:
CPU: 0 PID: 729 Comm: sh Not tainted 3.12.19-rt30+ #25
[<800107d9>] (unwind_backtrace+0x1/0x88) from [<8000e4ef>]
(show_stack+0xb/0xc)
[<8000e4ef>] (show_stack+0xb/0xc) from [<802b5fa9>]
(dump_stack+0x4d/0x60)
[<802b5fa9>] (dump_stack+0x4d/0x60) from [<800186dd>]
(warn_slowpath_common+0x45/0x64)
[<800186dd>] (warn_slowpath_common+0x45/0x64) from [<80018717>]
(warn_slowpath_fmt+0x1b/0x24)
[<80018717>] (warn_slowpath_fmt+0x1b/0x24) from [<8003a8d3>]
(irq_set_irq_wake+0x4b/0x8c)
[<8003a8d3>] (irq_set_irq_wake+0x4b/0x8c) from [<80204fcb>]
(ds3232_resume+0x2d/0x36)
[<80204fcb>] (ds3232_resume+0x2d/0x36) from [<801954c7>]
(dpm_run_callback.isra.13+0xb/0x28)
[<801954c7>] (dpm_run_callback.isra.13+0xb/0x28) from [<80195b1b>]
(device_resume+0x7b/0xa2)
[<80195b1b>] (device_resume+0x7b/0xa2) from [<80195f0f>]
(dpm_resume+0xbb/0x19c)
[<80195f0f>] (dpm_resume+0xbb/0x19c) from [<801960d9>]
(dpm_resume_end+0x9/0x12)
[<801960d9>] (dpm_resume_end+0x9/0x12) from [<80037e1d>]
(suspend_devices_and_enter+0x17d/0x1d0)
[<80037e1d>] (suspend_devices_and_enter+0x17d/0x1d0) from [<80037ee1>]
(pm_suspend+0x71/0x128)
[<80037ee1>] (pm_suspend+0x71/0x128) from [<80037449>]
(state_store+0x6d/0x80)
[<80037449>] (state_store+0x6d/0x80) from [<800af4d5>]
(sysfs_write_file+0x9f/0xde)
[<800af4d5>] (sysfs_write_file+0x9f/0xde) from [<8007a437>]
(vfs_write+0x7b/0x104)
[<8007a437>] (vfs_write+0x7b/0x104) from [<8007a7f7>]
(SyS_write+0x27/0x48)
[<8007a7f7>] (SyS_write+0x27/0x48) from [<8000c121>]
(ret_fast_syscall+0x1/0x44)
---[ end trace 640959d2e8de6ccc ]---
Signed-off-by: Wang Dongsheng
diff --git a/drivers/rtc/rtc-ds3232.c b/drivers/rtc/rtc-ds3232.c
index 7e48e53..2081155 100644
--- a/drivers/rtc/rtc-ds3232.c
+++ b/drivers/rtc/rtc-ds3232.c
@@ -463,7 +463,10 @@ static int ds3232_suspend(struct device *dev)
if (device_can_wakeup(dev)) {
ds3232->suspended = true;
- irq_set_irq_wake(client->irq, 1);
+ if (irq_set_irq_wake(client->irq, 1)) {
+ dev_info(dev, "Cannot serve as a wakeup source\n");
+ ds3232->suspended = false;
+ }
}
return 0;
--
2.1.0.27.g96db324
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched/fair: Clean up the __sched_period() code
Commit-ID: 8e2b0bf397279878babcb39b021edcafe7c945eb
Gitweb: http://git.kernel.org/tip/8e2b0bf397279878babcb39b021edcafe7c945eb
Author: Boqun Feng
AuthorDate: Thu, 2 Jul 2015 22:25:52 +0800
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 08:46:10 +0200
sched/fair: Clean up the __sched_period() code
Since commit:
4bf0b77158 ("sched: remove do_div() from __sched_slice()")
... the logic of __sched_period() can be implemented as a single if-else
without any local variables, so this patch cleans it up with an if-else
statement, which expresses the function's logic straightforwardly.
Signed-off-by: Boqun Feng
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Srikar Dronamraju
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1435847152-29543-1-git-send-email-boqun.f...@gmail.com
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a53a610..03ea05b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -616,15 +616,10 @@ static inline u64 calc_delta_fair(u64 delta, struct
sched_entity *se)
*/
static u64 __sched_period(unsigned long nr_running)
{
- u64 period = sysctl_sched_latency;
- unsigned long nr_latency = sched_nr_latency;
-
- if (unlikely(nr_running > nr_latency)) {
- period = sysctl_sched_min_granularity;
- period *= nr_running;
- }
-
- return period;
+ if (unlikely(nr_running > sched_nr_latency))
+ return nr_running * sysctl_sched_min_granularity;
+ else
+ return sysctl_sched_latency;
}
/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched/fair: Fix a comment reflecting function name change
Commit-ID: 399595f248cb25dccb6044b53c47c44c174dc23d Gitweb: http://git.kernel.org/tip/399595f248cb25dccb6044b53c47c44c174dc23d Author: Byungchul Park AuthorDate: Mon, 6 Jul 2015 21:51:02 +0900 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 08:46:11 +0200 sched/fair: Fix a comment reflecting function name change update_cfs_rq_load_contribution() was changed to __update_cfs_rq_tg_load_contrib() - sync up the commit in calc_tg_weight() too. Signed-off-by: Byungchul Park Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1436187062-19658-1-git-send-email-byungchul.p...@lge.com Signed-off-by: Ingo Molnar --- kernel/sched/fair.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 03ea05b..587a2f6 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2349,7 +2349,7 @@ static inline long calc_tg_weight(struct task_group *tg, struct cfs_rq *cfs_rq) /* * Use this CPU's actual weight instead of the last load_contribution * to gain a more accurate current total weight. See -* update_cfs_rq_load_contribution(). +* __update_cfs_rq_tg_load_contrib(). */ tg_weight = atomic_long_read(&tg->load_avg); tg_weight -= cfs_rq->tg_load_contrib; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched/numa: Consider 'imbalance_pct' when comparing loads in numa_has_capacity()
Commit-ID: 44dcb04f0ea8eaac3b9c9d3172416efc5a950214 Gitweb: http://git.kernel.org/tip/44dcb04f0ea8eaac3b9c9d3172416efc5a950214 Author: Srikar Dronamraju AuthorDate: Tue, 16 Jun 2015 17:26:00 +0530 Committer: Ingo Molnar CommitDate: Tue, 7 Jul 2015 08:46:10 +0200 sched/numa: Consider 'imbalance_pct' when comparing loads in numa_has_capacity() This is consistent with all other load balancing instances where we absorb unfairness upto env->imbalance_pct. Absorbing unfairness upto env->imbalance_pct allows to pull and retain task to their preferred nodes. Signed-off-by: Srikar Dronamraju Signed-off-by: Peter Zijlstra (Intel) Acked-by: Rik van Riel Cc: Linus Torvalds Cc: Mel Gorman Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1434455762-30857-3-git-send-email-sri...@linux.vnet.ibm.com Signed-off-by: Ingo Molnar --- kernel/sched/fair.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 43ee84f..a53a610 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -1415,8 +1415,9 @@ static bool numa_has_capacity(struct task_numa_env *env) * - vs - * src->compute_capacitydst->compute_capacity */ - if (src->load * dst->compute_capacity > - dst->load * src->compute_capacity) + if (src->load * dst->compute_capacity * env->imbalance_pct > + + dst->load * src->compute_capacity * 100) return true; return false; -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:sched/core] sched/numa: Prefer NUMA hotness over cache hotness
Commit-ID: 2a1ed24ce94036d00a7c5d5e99a77a80f0aa556a
Gitweb: http://git.kernel.org/tip/2a1ed24ce94036d00a7c5d5e99a77a80f0aa556a
Author: Srikar Dronamraju
AuthorDate: Tue, 16 Jun 2015 17:25:59 +0530
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 08:46:10 +0200
sched/numa: Prefer NUMA hotness over cache hotness
The current load balancer may not try to prevent a task from moving
out of a preferred node to a less preferred node. The reason for this
being:
- Since sched features NUMA and NUMA_RESIST_LOWER are disabled by
default, migrate_degrades_locality() always returns false.
- Even if NUMA_RESIST_LOWER were to be enabled, if its cache hot,
migrate_degrades_locality() never gets called.
The above behaviour can mean that tasks can move out of their
preferred node but they may be eventually be brought back to their
preferred node by numa balancer (due to higher numa faults).
To avoid the above, this commit merges migrate_degrades_locality() and
migrate_improves_locality(). It also replaces 3 sched features NUMA,
NUMA_FAVOUR_HIGHER and NUMA_RESIST_LOWER by a single sched feature
NUMA.
Signed-off-by: Srikar Dronamraju
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rik van Riel
Cc: Linus Torvalds
Cc: Mel Gorman
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Mike Galbraith
Link:
http://lkml.kernel.org/r/1434455762-30857-2-git-send-email-sri...@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 89 ++---
kernel/sched/features.h | 18 +++---
2 files changed, 30 insertions(+), 77 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 98b2b96..43ee84f 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5670,72 +5670,39 @@ static int task_hot(struct task_struct *p, struct
lb_env *env)
#ifdef CONFIG_NUMA_BALANCING
/*
- * Returns true if the destination node is the preferred node.
- * Needs to match fbq_classify_rq(): if there is a runnable task
- * that is not on its preferred node, we should identify it.
+ * Returns 1, if task migration degrades locality
+ * Returns 0, if task migration improves locality i.e migration preferred.
+ * Returns -1, if task migration is not affected by locality.
*/
-static bool migrate_improves_locality(struct task_struct *p, struct lb_env
*env)
+static int migrate_degrades_locality(struct task_struct *p, struct lb_env *env)
{
struct numa_group *numa_group = rcu_dereference(p->numa_group);
unsigned long src_faults, dst_faults;
int src_nid, dst_nid;
- if (!sched_feat(NUMA) || !sched_feat(NUMA_FAVOUR_HIGHER) ||
- !p->numa_faults || !(env->sd->flags & SD_NUMA)) {
- return false;
- }
-
- src_nid = cpu_to_node(env->src_cpu);
- dst_nid = cpu_to_node(env->dst_cpu);
-
- if (src_nid == dst_nid)
- return false;
-
- /* Encourage migration to the preferred node. */
- if (dst_nid == p->numa_preferred_nid)
- return true;
-
- /* Migrating away from the preferred node is bad. */
- if (src_nid == p->numa_preferred_nid)
- return false;
-
- if (numa_group) {
- src_faults = group_faults(p, src_nid);
- dst_faults = group_faults(p, dst_nid);
- } else {
- src_faults = task_faults(p, src_nid);
- dst_faults = task_faults(p, dst_nid);
- }
-
- return dst_faults > src_faults;
-}
-
-
-static bool migrate_degrades_locality(struct task_struct *p, struct lb_env
*env)
-{
- struct numa_group *numa_group = rcu_dereference(p->numa_group);
- unsigned long src_faults, dst_faults;
- int src_nid, dst_nid;
-
- if (!sched_feat(NUMA) || !sched_feat(NUMA_RESIST_LOWER))
- return false;
-
if (!p->numa_faults || !(env->sd->flags & SD_NUMA))
- return false;
+ return -1;
+
+ if (!sched_feat(NUMA))
+ return -1;
src_nid = cpu_to_node(env->src_cpu);
dst_nid = cpu_to_node(env->dst_cpu);
if (src_nid == dst_nid)
- return false;
+ return -1;
- /* Migrating away from the preferred node is bad. */
- if (src_nid == p->numa_preferred_nid)
- return true;
+ /* Migrating away from the preferred node is always bad. */
+ if (src_nid == p->numa_preferred_nid) {
+ if (env->src_rq->nr_running > env->src_rq->nr_preferred_running)
+ return 1;
+ else
+ return -1;
+ }
/* Encourage migration to the preferred node. */
if (dst_nid == p->numa_preferred_nid)
- return false;
+ return 0;
if (numa_group) {
src_faults = group_faults(p, src_nid);
@@ -5749,16 +5716,10 @@ static bool migrate_degrades_locality(struct
task_struct *p, struct lb_env *env)
}
#else
-sta
[tip:sched/core] sched/numa: Check sched_feat(NUMA) in migrate_improves_locality()
Commit-ID: 6dfec8d9493f48a42896386b41ec1a4644331b0b
Gitweb: http://git.kernel.org/tip/6dfec8d9493f48a42896386b41ec1a4644331b0b
Author: bseg...@google.com
AuthorDate: Tue, 16 Jun 2015 12:18:21 -0700
Committer: Ingo Molnar
CommitDate: Tue, 7 Jul 2015 08:46:09 +0200
sched/numa: Check sched_feat(NUMA) in migrate_improves_locality()
migrate_improves_locality checked sched_feat(NUMA_FAVOUR_HIGHER) but not
sched_feat(NUMA), so disabling just the NUMA feature would leave it
working off of old data.
Signed-off-by: Ben Segall
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Mel Gorman
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/xm26si9rtqbm@sword-of-the-dawn.mtv.corp.google.com
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d113c3b..98b2b96 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5680,8 +5680,8 @@ static bool migrate_improves_locality(struct task_struct
*p, struct lb_env *env)
unsigned long src_faults, dst_faults;
int src_nid, dst_nid;
- if (!sched_feat(NUMA_FAVOUR_HIGHER) || !p->numa_faults ||
- !(env->sd->flags & SD_NUMA)) {
+ if (!sched_feat(NUMA) || !sched_feat(NUMA_FAVOUR_HIGHER) ||
+ !p->numa_faults || !(env->sd->flags & SD_NUMA)) {
return false;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: tps6586x: Fix up define for TPS6586X_MAX_REGISTER
On Tue, 07 Jul 2015, Axel Lin wrote:
> The latest valid register is TPS6586X_VERSIONCRC.
>
> Signed-off-by: Axel Lin
> ---
> drivers/mfd/tps6586x.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
> index e0a2583..ae08b29 100644
> --- a/drivers/mfd/tps6586x.c
> +++ b/drivers/mfd/tps6586x.c
> @@ -52,7 +52,7 @@
> #define TPS6586X_VERSIONCRC 0xcd
>
> /* Maximum register */
> -#define TPS6586X_MAX_REGISTER(TPS6586X_VERSIONCRC + 1)
> +#define TPS6586X_MAX_REGISTERTPS6586X_VERSIONCRC
>
> struct tps6586x_irq_data {
> u8 mask_reg;
> @@ -467,7 +467,7 @@ static bool is_volatile_reg(struct device *dev, unsigned
> int reg)
> static const struct regmap_config tps6586x_regmap_config = {
> .reg_bits = 8,
> .val_bits = 8,
> - .max_register = TPS6586X_MAX_REGISTER - 1,
> + .max_register = TPS6586X_MAX_REGISTER,
> .volatile_reg = is_volatile_reg,
> .cache_type = REGCACHE_RBTREE,
> };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sched: introduce sched_switch_post trace event
On Mon, Jul 06, 2015 at 12:15:45PM -0700, Cong Wang wrote: > Currently we only have one sched_switch trace event > for task switching, which is generated very early during > task switch. When we try to monitor per-container perf > events, this is not what we expect. > > For example, we have a process A which is in the cgroup > we monitor, and process B which isn't, when kernel switches > from B to A, the sched_switch event is not recorded for this > cgroup since it belongs to B (current process is still B > util we finish the switch), but we require this event to > signal that process A in this cgroup gets scheduled. This is > crucial for calculating schedule latency (like `perf sched`). > > Ideally, we need to split the sched_switch event into two: > sched_in event before we perform the switch, and sched_out > event after we perform the switch. However, for compatibility, > we can not change the sched_switch event. So before we have > trace event alias, we can just reuse sched_switch and introduce > sched_switch_post event instead. No.. its still horrible. You're trying to solve perf problems with ftrace; this cannot work. Does this patch by Adrian work for you? I think it solves this problem and a bunch of others. lkml.kernel.org/r/1435927962-32417-2-git-send-email-adrian.hun...@intel.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:sched/core] sched/rt: Fix memory leak in alloc_rt_sched_group()
* Anshul Garg wrote: > Dear linux community, > > I think this patch" sched/rt: Fix memory leak in > alloc_rt_sched_group()" with Commit-ID: > ecdd6804b7c9e15fe8fc836ba0233d9912834e8b is not correct. > > As it will create panic in case of kzalloc failure because of doingkfree > twice. > > As if alloc_rt_sched_group fails it will return zero then core.c will > call free_sched_group in core.c > which subsequently calls free_rt_sched_group . > > In free_rt_sched_group memory is getting freed properly. > > so it seems patch sent by me is not correct. > > Please help to review patch once again as it might break some things. > > Sorry for inconvenience. > > Thanks > Anshul Garg Ok, I've removed this patch. Thanks! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Clarification for the use of additional fields in the message body
On Tue, Jul 7, 2015 at 8:21 AM, SF Markus Elfring wrote: >>> From: Markus Elfring >>> Date: Sat, 27 Jun 2015 15:56:57 +0200 >> >> Why is this in the body of the email? > > Does the canonical patch format support to preserve > specific details about a shown commit by specification > of fields like "Date" and "From" in the message body? Using "From:" in the body can be used to provide your properly spelled name, or the name/e-mail of the actual author, if that happens not to be the sender. git-send-email will do that automagically for you. If "From:" is not specified in the message body, the e-mails sender will be used as author. The date, as far as I know, is ignored. It is the commit date, not the authoring date, and once your patch is applied by a maintainer (i.e. committed), the date gets reset anyway. No need to try and preserve it. Frans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/2] Correct for ACPI 5.1->6.0 spec changes in MADT GICC entries
On Mon, 6 Jul 2015, Al Stone wrote: > On 07/06/2015 05:20 PM, Rafael J. Wysocki wrote: > > Hi Al, > > > > On Tue, Jul 7, 2015 at 1:16 AM, Al Stone wrote: > >> In the ACPI 5.1 version of the spec, the struct for the GICC subtable > >> (struct acpi_madt_generic_interrupt) of the MADT is 76 bytes long; in > >> ACPI 6.0, the struct is 80 bytes long. But, there is only one definition > >> in ACPICA for this struct -- and that is the 6.0 version. Hence, when > >> BAD_MADT_ENTRY() compares the struct size to the length in the GICC > >> subtable, it fails if 5.1 structs are in use, and there are systems in > >> the wild that have them. > >> > >> Note that this was found in linux-next and these patches apply against > >> that tree and the arm64 kernel tree; 4.1 does not appear to have this > >> problem since it still has the 5.1 struct definition. > >> > >> Though there is precedent in ia64 code for ignoring the changes in size, > >> this patch set instead verifies correctness. The first patch adds the > >> BAD_MADT_GICC_ENTRY() macro to check the GICC subtable only, accounting > >> for the difference in specification versions that are possible. The > >> second patch replaces BAD_MADT_ENTRY usage with the BAD_MADT_GICC_ENTRY > >> macro in arm64 code, which is currently the only architecture affected. > >> The BAD_MADT_ENTRY() will continue to work as is for all other MADT > >> subtables. > >> > >> I have tested these patches on an APM Mustang with version 1.15 firmware, > >> where the problem was found, and they fix the problem -- i.e., the system > >> will boot with either Linux 4.1 or linux-next kernels using the same ACPI > >> 5.1 compatible firmware. > > > > ACK for the series, but I guess it's better to let it go via ARM64, right? > > > > Rafael > > Thanks, Rafael. Yeah, probably so. Will has ACKd the one patch > (2/2); if he and/or Catalin ACK patch 1/2, then this seems like it > would pretty cleanly fit into ARM64. The only question would be if > Will or Catalin would want an ACK from Thomas on the irq-gic.c part > in 2/2. No objections from my side. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] nohz: Affining unpinned timers
On Tue, 7 Jul 2015, Frederic Weisbecker wrote: > On Mon, Jul 06, 2015 at 07:18:22PM +0200, Thomas Gleixner wrote: > > On Mon, 6 Jul 2015, Frederic Weisbecker wrote: > > > I hope everybody received the patch because there is a ";" after each > > > address :-) > > > > > > On Tue, Jun 23, 2015 at 02:01:33PM +0530, Vatika Harlalka wrote: > > > > The problem addressed in this patch is about affining unpinned timers. > > > > Adaptive or Full Dynticks CPUs should not be disturbed by unnecessary > > > > jitter due to firing of such timers on them. > > > > This patch will affine timers to online CPUs which are not Full Dynticks > > > > in FULL_NOHZ configured systems. It will not bring about functional > > > > changes if NOHZ_FULL is not configured, because is_housekeeping_cpu() > > > > always returns true in CONFIG_NO_HZ_FULL=n. > > > > > > > > Signed-off by: Vatika Harlalka > > > > > > The patch looks good to me. Peter, Thomas, are you ok with it too? > > > > By some definition of OK. The overhead of this is growing and growing. > > > > We really need to make this a pull not a push model. > > I'm currently working toward that. > See "[PATCH 0/8] tick/nohz: Tick dependency quick check + cleanups" as a > first step. > > Now for this very patch, I don't know how we could make it better. Any > suggestion? Not for the time being. When I'm done with the timer wheel overhaul we should look into queueing stuff in different wheels and let the non idle cpus pull from there instead of pushing stuff at enqueue time. The latter is really silly because most of these timers are removed before they expire. Needs some thoughts, but anything which avoids the whole target cpu crap at enqueue time is better than what we have now. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rtc-linux] [PATCH-v2] rtc: 88pm80x: add device tree support
On Thursday 25 June 2015 01:16 PM, Vaibhav Hiremath wrote:
On Saturday 20 June 2015 06:13 AM, Alexandre Belloni wrote:
Hi,
Sorry I missed this email.
Just wanted to send reminder email and saw this :)
On 18/06/2015 at 00:28:06 +0530, Vaibhav Hiremath wrote :
-pdata = dev_get_platdata(&pdev->dev);
-if (pdata == NULL)
-dev_warn(&pdev->dev, "No platform data!\n");
+if (!pdata && !node) {
+dev_err(&pdev->dev,
+"pm80x-rtc requires platform data or of_node\n");
+return -EINVAL;
+}
+
+if (!pdata) {
+pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
I had troubles to follow the rtc_wakeup initialization cleanup but it
seems OK.
Probably, once we have complete PM support ready then it would be
easier to understand. I think as of now lets have this minimal code for
rtc_wakeup.
However, I'm wondering why you are adding DT support as this
will always be probed from the MFD driver which pass the platform_data
and avoids that allocation.
You are right.
Originally, it was cleanup patch,
- remove pm80x_pdata
- Add check for pdata and np
- and around rtc_wakeup
While doing that I added this nice to have allocation.
Any update/feedback on this?
Thanks,
Vaibhav
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: imx-sdma: Add device to device support
Hi vinod
On Tue, Jul 07, 2015 at 09:50:57AM +0530, Vinod Koul wrote:
> On Tue, Jun 23, 2015 at 04:42:54PM +0800, Shengjiu Wang wrote:
> > +static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
> > +{
> > + struct sdma_engine *sdma = sdmac->sdma;
> > +
> > + int lwml = sdmac->watermark_level & 0xff;
> > + int hwml = (sdmac->watermark_level >> 16) & 0xff;
> > +
> > + if (sdmac->event_id0 > 31) {
> > + sdmac->event_mask[0] |= 0;
> > + __set_bit(28, &sdmac->watermark_level);
> why not use set_bit(), you are modifying driver memory
Original driver all use the __set_bit. do you think we need to change
all the __set_bit to set_bit? And from the header file "arch/arm/include/asm
/bitops.h", the set_bit is same as __set_bit.
>
>
> > + sdmac->event_mask[1] |=
> > + BIT(sdmac->event_id0 % 32);
> and then why not use set_bit() here too?
>
> > + } else {
> > + sdmac->event_mask[0] |= 0;
> > + sdmac->event_mask[1] |=
> > + BIT(sdmac->event_id0 % 32);
> > + }
> > + if (sdmac->event_id1 > 31) {
> > + sdmac->event_mask[1] |= 0;
> > + __set_bit(29, &sdmac->watermark_level);
> > + sdmac->event_mask[0] |=
> > + BIT(sdmac->event_id1 % 32);
> > + } else {
> > + sdmac->event_mask[1] |= 0;
> > + sdmac->event_mask[0] |=
> > + BIT(sdmac->event_id1 % 32);
> > + }
> pattern for eventidX is repeated, also in that we can make generic macro to
> handle and reduce code size
I will change this.
>
> > +
> > + /*
> > +* If LWML(src_maxburst) > HWML(dst_maxburst), we need
> > +* swap LWML and HWML of INFO(A.3.2.5.1), also need swap
> > +* r0(event_mask[1]) and r1(event_mask[0]).
> > +*/
> > + if (lwml > hwml) {
> > + sdmac->watermark_level &= ~0xff00ff;
> Magic number?
>
> > static int sdma_config_channel(struct dma_chan *chan)
> > {
> > struct sdma_channel *sdmac = to_sdma_chan(chan);
> > @@ -869,6 +945,12 @@ static int sdma_config_channel(struct dma_chan *chan)
> > sdma_event_enable(sdmac, sdmac->event_id0);
> > }
> >
> > + if (sdmac->event_id1) {
> > + if (sdmac->event_id1 >= sdmac->sdma->drvdata->num_events)
> > + return -EINVAL;
> > + sdma_event_enable(sdmac, sdmac->event_id1);
> > + }
> > +
> > switch (sdmac->peripheral_type) {
> > case IMX_DMATYPE_DSP:
> > sdma_config_ownership(sdmac, false, true, true);
> > @@ -887,19 +969,21 @@ static int sdma_config_channel(struct dma_chan *chan)
> > (sdmac->peripheral_type != IMX_DMATYPE_DSP)) {
> > /* Handle multiple event channels differently */
> > if (sdmac->event_id1) {
> > - sdmac->event_mask[1] = BIT(sdmac->event_id1 % 32);
> > - if (sdmac->event_id1 > 31)
> > - __set_bit(31, &sdmac->watermark_level);
> > - sdmac->event_mask[0] = BIT(sdmac->event_id0 % 32);
> > - if (sdmac->event_id0 > 31)
> > - __set_bit(30, &sdmac->watermark_level);
> > - } else {
> > + if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
> > + sdmac->peripheral_type == IMX_DMATYPE_ASRC)
> > + sdma_set_watermarklevel_for_p2p(sdmac);
> > + } else
> > __set_bit(sdmac->event_id0, sdmac->event_mask);
> > - }
> > +
> > /* Watermark Level */
> > sdmac->watermark_level |= sdmac->watermark_level;
> > /* Address */
> > - sdmac->shp_addr = sdmac->per_address;
> > + if (sdmac->direction == DMA_DEV_TO_DEV) {
> Okay the direction is depreciated, so can you store both source and
> destination and use them based on direction in prepare()
>
> Also I see driver is not doing this, so while at it, can you fix this is
> current code as well
>
which prepare() do you mean? sdma_prep_dma_cyclic, sdma_prep_slave_sg?
> --
> ~Vinod
>
best regards
wang shengjiu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] sched: separate operations only for SMP from account_entity_en(de)queue
On Tue, Jul 07, 2015 at 10:07:03AM +0900, byungchul.p...@lge.com wrote:
> From: Byungchul Park
>
> manipulating rq->cfs_tasks and numa-accounting are not meaningless on !SMP.
> separate the operations from account_entity_en(de)queue.
>
> Signed-off-by: Byungchul Park
> ---
> kernel/sched/fair.c | 40 +++-
> 1 file changed, 27 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 09456fc..a22f255 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -2314,20 +2314,36 @@ static inline void account_numa_dequeue(struct rq
> *rq, struct task_struct *p)
> }
> #endif /* CONFIG_NUMA_BALANCING */
>
> +#ifdef CONFIG_SMP
> +static void account_task_enqueue(struct rq *rq, struct sched_entity *se)
> +{
> + account_numa_enqueue(rq, task_of(se));
i put this code within #ifdef CONFIG_SMP as original code. see below.
> + list_add(&se->group_node, &rq->cfs_tasks);
se->group_node can be used for other purposes, so i didn't touch the structure.
but manipulating rq->cfs_tasks list is only for CONFIG_SMP.
so i just touched the code manipulating the list.
> +}
> +
> +static void account_task_dequeue(struct rq *rq, struct sched_entity *se)
> +{
> + account_numa_dequeue(rq, task_of(se));
> + list_del_init(&se->group_node);
> +}
> +#else
> +static inline void account_task_enqueue(struct rq *rq, struct sched_entity
> *se)
> +{
> +}
> +
> +static inline void account_task_dequeue(struct rq *rq, struct sched_entity
> *se)
> +{
> +}
> +#endif /* CONFIG_SMP */
> +
> static void
> account_entity_enqueue(struct cfs_rq *cfs_rq, struct sched_entity *se)
> {
> update_load_add(&cfs_rq->load, se->load.weight);
> if (!parent_entity(se))
> update_load_add(&rq_of(cfs_rq)->load, se->load.weight);
> -#ifdef CONFIG_SMP
> - if (entity_is_task(se)) {
> - struct rq *rq = rq_of(cfs_rq);
> -
> - account_numa_enqueue(rq, task_of(se));
> - list_add(&se->group_node, &rq->cfs_tasks);
> - }
> -#endif
this is the original code i mentioned.
> + if (entity_is_task(se))
> + account_task_enqueue(rq_of(cfs_rq), se);
> cfs_rq->nr_running++;
> }
>
> @@ -2337,15 +2353,13 @@ account_entity_dequeue(struct cfs_rq *cfs_rq, struct
> sched_entity *se)
> update_load_sub(&cfs_rq->load, se->load.weight);
> if (!parent_entity(se))
> update_load_sub(&rq_of(cfs_rq)->load, se->load.weight);
> - if (entity_is_task(se)) {
> - account_numa_dequeue(rq_of(cfs_rq), task_of(se));
> - list_del_init(&se->group_node);
> - }
> + if (entity_is_task(se))
> + account_task_dequeue(rq_of(cfs_rq), se);
> cfs_rq->nr_running--;
> }
>
> #ifdef CONFIG_FAIR_GROUP_SCHED
> -# ifdef CONFIG_SMP
> +#ifdef CONFIG_SMP
> static inline long calc_tg_weight(struct task_group *tg, struct cfs_rq
> *cfs_rq)
> {
> long tg_weight;
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpio: pca953x: Fix warning when HW interrupts are rescheduled by the softirq tasklet
Hi all
2014-09-26 11:07 GMT+02:00 Linus Walleij :
> On Thu, Sep 25, 2014 at 6:26 PM, Grygorii Strashko
> wrote:
>> On 09/25/2014 11:07 AM, Linus Walleij wrote:
>>> On Wed, Sep 24, 2014 at 2:28 PM, Grygorii Strashko
>>> wrote:
On 09/24/2014 02:17 PM, Linus Walleij wrote:
>>>
> So PCA cannot use gpiochip_set_chained_irqchip()?
Yes. It can't - pca is i2c device.
>>>
>>> ? I don't get this statement.
>>>
>>> Why does the fact that it is an I2C device matter?
>>> We have several devices that are in fact on top of
>>> I2C (albeit as MFD cells) like gpio-tc3589x.c.
>>
>> gpio-tc3589x.c doesn't call gpiochip_set_chained_irqchip()
>
> Ah yeah you're right of course. I considered adding a separate
> registration function for the sleeping handlers, like
> gpiochip_set_threaded_irqchip() that would handle
> setting up the nested case.
>
>>> Yes, but the .map function isn't called until a client
>>> wants to use an IRQ. And that won't happen until after
>>> we exit the whole .probe() function.
>>
>> .map function is called from irq_create_mapping() which,
>> in turn, can be called as from irq_domain_add_simple() -
>> as result .map will be always called from gpiochip_irqchip_add().
>
> Ah yeah you're right, I was just wrong here :-/
>
>>> Well it happens in one single driver, and was done by me.
>>> Maybe I should either disallow that, as that means we're adding
>>> multiple parents (which is what you want, right?) or actually
>>> implement it in a way so that multiple parents can be handled
>>> by the helpers, by adding the parents to a list or something.
>>
>> Sorry, but It seems the simplest way is to allow drivers to manage
>> parent IRQs for the complex cases. So, I vote for custom .map()
>> callback, but It could be not too simple to implement it, because
>> private driver data need to be passed as parameter to this callback
>> somehow.
>
> Yeah. Well what I'm thinking as subsystem maintainer, is that
> when I added the generic GPIOlib irqchip helpers we managed to
> smoke out a large:ish set of subtle bugs that different drivers
> had created independently of each other.
>
> So centralizing code is very important if at all possible to bring
> down the maintainer burden.
>
> So for that reason I'm looking a second and a third time at these
> things before going ahead with custom code in drivers...
>
>> === Simple one - driver need to set parent_irq before adding gpiochip ===
>>
>> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
>> index 8aa84d5..292840b 100644
>> --- a/drivers/gpio/gpiolib.c
>> +++ b/drivers/gpio/gpiolib.c
>> @@ -447,8 +447,11 @@ static int gpiochip_irq_map(struct irq_domain *d,
>> unsigned int irq,
>> irq_set_lockdep_class(irq, &gpiochip_irq_lock_class);
>> irq_set_chip_and_handler(irq, chip->irqchip, chip->irq_handler);
>> /* Chips that can sleep need nested thread handlers */
>> - if (chip->can_sleep)
>> + if (chip->can_sleep) {
>> irq_set_nested_thread(irq, 1);
>> + if (chip->parent_irq)
>> + irq_set_parent(irq, chip->parent_irq);
>> + }
>
> Yeah I need to think of something like this...
>
I did run into exact the same situation with a 4.1.1 kernel :)
[ 312.863047] [ cut here ]
[ 312.867681] WARNING: CPU: 1 PID: 12 at kernel/irq/manage.c:696
irq_nested_primary_handler+0x30/0x38()
[ 312.876901] Primary handler called for nested irq 301
[ 312.881953] Modules linked in: uinput ipv6 smsc95xx usbnet mii
imx2_wdt etnaviv(C) matrix_keypad matrix_keymap ar1021_i2c
[ 312.893067] CPU: 1 PID: 12 Comm: ksoftirqd/1 Tainted: GWC
4.1.1 #9
[ 312.900378] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 312.906906] Backtrace:
[ 312.909377] [] (dump_backtrace) from []
(show_stack+0x20/0x24)
[ 312.916947] r6:0009 r5: r4: r3:dc8ba301
[ 312.922673] [] (show_stack) from []
(dump_stack+0x70/0xc0)
[ 312.929924] [] (dump_stack) from []
(warn_slowpath_common+0x88/0xc0)
[ 312.938029] r5:02b8 r4:
[ 312.941678] [] (warn_slowpath_common) from []
(warn_slowpath_fmt+0x40/0x48)
[ 312.950391] r8: r7:c07b1314 r6:012d r5:eea07720 r4:c3048840
[ 312.957233] [] (warn_slowpath_fmt) from []
(irq_nested_primary_handler+0x30/0x38)
[ 312.966467] r3:012d r2:c06b9128
[ 312.970113] [] (irq_nested_primary_handler) from
[] (handle_irq_event_percpu+0x70/0x2d0)
[ 312.979967] [] (handle_irq_event_percpu) from
[] (handle_irq_event+0x4c/0x6c)
[ 312.988854] r10:0002 r9:0018 r8: r7:c07b1314
r6:c3048840 r5:eea07720
[ 312.996812] r4:eea076c0
[ 312.999395] [] (handle_irq_event) from []
(handle_simple_irq+0xa4/0xc8)
[ 313.007760] r6:c07c5404 r5:eea07720 r4:eea076c0 r3:0003
[ 313.013536] [] (handle_simple_irq) from []
(resend_irqs+0x50/0x7c)
[ 313.021468] r5:c07c5404 r4:012d
[ 313.025119] [] (resend_irqs) from []
(tasklet_action+0x94/0x140)
[ 313.032877] r6: r5:c07
Re: Clarification for the use of additional fields in the message body
>> From: Markus Elfring >> Date: Sat, 27 Jun 2015 15:56:57 +0200 > > Why is this in the body of the email? Does the canonical patch format support to preserve specific details about a shown commit by specification of fields like "Date" and "From" in the message body? Regards, Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] mtd: nand_bbt: separate struct nand_chip from nand_bbt.c
Currently nand_bbt.c is tied with struct nand_chip, and it makes other
NAND family chips hard to use nand_bbt.c. Maybe it's the reason why
onenand has own bbt(onenand_bbt.c).
Parameterize a few relevant device detail information into a new
nand_bbt struct, and set some hooks for chip specified part. Allocate
and initialize struct nand_bbt in nand_base.c.
Most of the patch is borrowed from Brian Norris .
http://git.infradead.org/users/norris/linux-mtd.git/shortlog/refs/heads/nand-bbt
Signed-off-by: Peter Pan
Signed-off-by: Brian Norris
Tested-by: Kamil Debski
---
changelog:
v1-v2:
Address Kamil Debski's test
Add necessary comments to nand_bbt struct
drivers/mtd/nand/docg4.c | 8 +-
drivers/mtd/nand/nand_base.c | 145 +++-
drivers/mtd/nand/nand_bbt.c | 524 +--
include/linux/mtd/bbm.h | 96 +---
include/linux/mtd/nand.h | 14 +-
include/linux/mtd/nand_bbt.h | 172 ++
6 files changed, 533 insertions(+), 426 deletions(-)
create mode 100644 include/linux/mtd/nand_bbt.h
diff --git a/drivers/mtd/nand/docg4.c b/drivers/mtd/nand/docg4.c
index e5d7bca..eb55a21 100644
--- a/drivers/mtd/nand/docg4.c
+++ b/drivers/mtd/nand/docg4.c
@@ -1037,7 +1037,7 @@ static int __init read_factory_bbt(struct mtd_info *mtd)
* operation after device power-up. The above read ensures it never is.
* Ugly, I know.
*/
- if (nand->bbt == NULL) /* no memory-based bbt */
+ if (nand->nand_bbt == NULL) /* no memory-based bbt */
goto exit;
if (mtd->ecc_stats.failed > eccfailed_stats) {
@@ -1064,7 +1064,11 @@ static int __init read_factory_bbt(struct mtd_info *mtd)
unsigned long bits = ~buf[i];
for_each_set_bit(bitnum, &bits, 8) {
int badblock = block + 7 - bitnum;
- nand->bbt[badblock / 4] |=
+ /*
+* Should we create a mark factory bad block interface
+* for this?
+*/
+ nand->nand_bbt->bbt[badblock / 4] |=
0x03 << ((badblock % 4) * 2);
mtd->ecc_stats.badblocks++;
dev_notice(doc->dev, "factory-marked bad block: %d\n",
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index ceb68ca..eb94714 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -97,6 +97,9 @@ static int nand_get_device(struct mtd_info *mtd, int
new_state);
static int nand_do_write_oob(struct mtd_info *mtd, loff_t to,
struct mtd_oob_ops *ops);
+static int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr,
+ int allowbbt);
+
/*
* For devices which display every fart in the system on a separate LED. Is
* compiled away when LED support is disabled.
@@ -450,8 +453,8 @@ static int nand_block_markbad_lowlevel(struct mtd_info
*mtd, loff_t ofs)
}
/* Mark block bad in BBT */
- if (chip->bbt) {
- res = nand_markbad_bbt(mtd, ofs);
+ if (chip->nand_bbt) {
+ res = nand_bbt_markbad(chip->nand_bbt, ofs);
if (!ret)
ret = res;
}
@@ -493,10 +496,10 @@ static int nand_block_isreserved(struct mtd_info *mtd,
loff_t ofs)
{
struct nand_chip *chip = mtd->priv;
- if (!chip->bbt)
+ if (!chip->nand_bbt)
return 0;
/* Return info from the table */
- return nand_isreserved_bbt(mtd, ofs);
+ return nand_bbt_isreserved(chip->nand_bbt, ofs);
}
/**
@@ -513,12 +516,18 @@ static int nand_block_checkbad(struct mtd_info *mtd,
loff_t ofs, int getchip,
int allowbbt)
{
struct nand_chip *chip = mtd->priv;
+ struct nand_bbt *bbt = chip->nand_bbt;
- if (!chip->bbt)
+ if (!bbt)
return chip->block_bad(mtd, ofs, getchip);
/* Return info from the table */
- return nand_isbad_bbt(mtd, ofs, allowbbt);
+ if (nand_bbt_isbad(bbt, ofs))
+ return 1;
+ else if (allowbbt)
+ return 0;
+ else
+ return nand_bbt_isreserved(bbt, ofs);
}
/**
@@ -2729,7 +2738,7 @@ static int nand_erase(struct mtd_info *mtd, struct
erase_info *instr)
*
* Erase one ore more blocks.
*/
-int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr,
+static int nand_erase_nand(struct mtd_info *mtd, struct erase_info *instr,
int allowbbt)
{
int page, status, pages_per_block, ret, chipnr;
@@ -2836,6 +2845,122 @@ erase_exit:
return ret;
}
+/* NAND BBT helper - erase a block, including reserved blocks */
+static int nand_bbt_erase_block(struct mtd_info *mtd, loff_t addr)
+{
+ struct erase_info einfo;
+
[PATCH] cris: arch-v32: gpio: Use kzalloc instead of kmalloc/memset
Turn a kmalloc/memset into an equivalent kzalloc. Doing so also move the zero'ing of the memory outside of a mutex. Signed-off-by: Christophe Jaillet --- A simililar patch has already been applied against arch/cris/arch-v32/drivers/mach-fs/gpio.c --- arch/cris/arch-v32/drivers/mach-a3/gpio.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/cris/arch-v32/drivers/mach-a3/gpio.c b/arch/cris/arch-v32/drivers/mach-a3/gpio.c index 74f9fe8..75f0264 100644 --- a/arch/cris/arch-v32/drivers/mach-a3/gpio.c +++ b/arch/cris/arch-v32/drivers/mach-a3/gpio.c @@ -386,13 +386,12 @@ static int gpio_open(struct inode *inode, struct file *filp) (p > GPIO_MINOR_LAST && p < GPIO_MINOR_PWM0)) return -EINVAL; - priv = kmalloc(sizeof(struct gpio_private), GFP_KERNEL); + priv = kzalloc(sizeof(struct gpio_private), GFP_KERNEL); if (!priv) return -ENOMEM; mutex_lock(&gpio_mutex); - memset(priv, 0, sizeof(*priv)); priv->minor = p; filp->private_data = priv; -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: stats (Was: Linux 4.2-rc1)
Hi all, [These will be easier in the future as I have now scripted this message] As usual, the executive friendly graph is at http://neuling.org/linux-next-size.html :-) (No merge commits counted, next-20150623 was the first linux-next after the merge window opened.) Commits in v4.2-rc1 (relative to v4.1):12092 Commits in next-20150623: 11851 Commits with the same SHA1:10679 Commits with the same patch_id: 615 (1) Commits with the same subject line: 54 (1) (1) not counting those in the lines above. So commits in -rc1 that were in next-20150623: 11294 93% Some breakdown of the list of extra commits (relative to next-20150623) in -rc1: Top ten first word of commit summary: 54 perf 52 drm 46 net 35 kvm 25 btrfs 25 acpica 24 arcv2 22 ntb 22 ceph 13 nfs Top ten authors: 32 jo...@kernel.org 29 vgu...@synopsys.com 26 anand.j...@oracle.com 24 t...@linutronix.de 23 z...@redhat.com 15 human.hw...@samsung.com 15 guangrong.x...@linux.intel.com 14 idryo...@gmail.com 14 christian.koe...@amd.com 13 lv.zh...@intel.com Top ten commiters: 122 da...@davemloft.net 53 a...@redhat.com 40 idryo...@gmail.com 36 pbonz...@redhat.com 34 rafael.j.wyso...@intel.com 32 vgu...@synopsys.com 30 t...@linutronix.de 30 alexander.deuc...@amd.com 29 trond.mykleb...@primarydata.com 26 dste...@suse.cz There are also 503 commits in next-20150623 that didn't make it into v4.2-rc1. Top ten first word of commit summary: 51 kdbus 31 userfaultfd 31 arm 23 rcu 21 mm 19 ocfs2 17 documentation 17 coresight 16 cris 14 page-flags Top ten authors: 37 a...@linux-foundation.org 30 aarca...@redhat.com 29 ser...@s15v.net 21 dh.herrm...@gmail.com 20 ra...@rab.in 20 dan...@zonque.org 19 paul...@linux.vnet.ibm.com 16 kirill.shute...@linux.intel.com 14 ttynkky...@nvidia.com 13 tred...@nvidia.com Some of Andrew's patches are fixes for other patches in his tree (and have been merged into those). Top ten commiters: 153 m...@ellerman.id.au 59 gre...@linuxfoundation.org 32 paul...@linux.vnet.ibm.com 32 mathieu.poir...@linaro.org 30 tred...@nvidia.com 26 jesp...@axis.com 19 dh.herrm...@gmail.com 18 mma...@suse.cz 17 s...@canb.auug.org.au 16 a...@arndb.de Those commits by m...@ellerman.id.au and me are from the quilt series (mainly Andrew's mmotm tree). -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] cxl: Fix off by one error allowing subsequent mmap page to be accessed
From: Ian Munsie
It was discovered that if a process mmaped their problem state area they
were able to access one page more than expected, potentially allowing
them to access the problem state area of an unrelated process.
This was due to a simple off by one error in the mmap fault handler
introduced in 0712dc7e73e59d79bcead5d5520acf4e9e917e87 ("cxl: Fix issues
when unmapping contexts"), which is fixed in this patch.
Cc: sta...@vger.kernel.org
Fixes: 0712dc7e73e5 ("cxl: Fix issues when unmapping contexts")
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/context.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
index 2a4c80a..6c1ce51 100644
--- a/drivers/misc/cxl/context.c
+++ b/drivers/misc/cxl/context.c
@@ -113,11 +113,11 @@ static int cxl_mmap_fault(struct vm_area_struct *vma,
struct vm_fault *vmf)
if (ctx->afu->current_mode == CXL_MODE_DEDICATED) {
area = ctx->afu->psn_phys;
- if (offset > ctx->afu->adapter->ps_size)
+ if (offset >= ctx->afu->adapter->ps_size)
return VM_FAULT_SIGBUS;
} else {
area = ctx->psn_phys;
- if (offset > ctx->psn_size)
+ if (offset >= ctx->psn_size)
return VM_FAULT_SIGBUS;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] cxl: Fail mmap if requested mapping is larger than assigned problem state area
From: Ian Munsie
This patch makes the mmap call fail outright if the requested region is
larger than the problem state area assigned to the context so the error
is reported immediately rather than waiting for an attempt to access an
address out of bounds.
Although we never expect users to map more than the assigned problem
state area and are not aware of anyone doing this (other than for
testing), this does have the potential to break users if someone has
used a larger range regardless. I'm submitting it for consideration, but
if this change is not considered acceptable the previous patch is
sufficient to prevent access out of bounds without breaking anyone.
Signed-off-by: Ian Munsie
---
drivers/misc/cxl/context.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/cxl/context.c b/drivers/misc/cxl/context.c
index 6c1ce51..1287148 100644
--- a/drivers/misc/cxl/context.c
+++ b/drivers/misc/cxl/context.c
@@ -145,8 +145,16 @@ static const struct vm_operations_struct cxl_mmap_vmops = {
*/
int cxl_context_iomap(struct cxl_context *ctx, struct vm_area_struct *vma)
{
+ u64 start = vma->vm_pgoff << PAGE_SHIFT;
u64 len = vma->vm_end - vma->vm_start;
- len = min(len, ctx->psn_size);
+
+ if (ctx->afu->current_mode == CXL_MODE_DEDICATED) {
+ if (start + len > ctx->afu->adapter->ps_size)
+ return -EINVAL;
+ } else {
+ if (start + len > ctx->psn_size)
+ return -EINVAL;
+ }
if (ctx->afu->current_mode != CXL_MODE_DEDICATED) {
/* make sure there is a valid per process space for this AFU */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [SCSI] FlashPoint: optimize string comparison
Stop comparing the strings as soon as we know that they don't match.
Signed-off-by: Christophe JAILLET
---
drivers/scsi/FlashPoint.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/scsi/FlashPoint.c b/drivers/scsi/FlashPoint.c
index 5c74e4c..24a4d1a 100644
--- a/drivers/scsi/FlashPoint.c
+++ b/drivers/scsi/FlashPoint.c
@@ -6280,8 +6280,10 @@ static unsigned char FPT_scmachid(unsigned char p_card,
match = 1;
for (k = 0; k < ID_STRING_LENGTH; k++) {
- if (p_id_string[k] != FPT_scamInfo[i].id_string[k])
+ if (p_id_string[k] != FPT_scamInfo[i].id_string[k]) {
match = 0;
+ break;
+ }
}
if (match) {
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] rtc: rtc-ds1685: Use module_platform_driver
Use module_platform_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return platform_driver_register(&x); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { platform_driver_unregister(&x); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_platform_driver;
@@
-module_exit(e);
+module_platform_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/rtc/rtc-ds1685.c | 22 +-
1 file changed, 1 insertion(+), 21 deletions(-)
diff --git a/drivers/rtc/rtc-ds1685.c b/drivers/rtc/rtc-ds1685.c
index 818a363..05a51ef 100644
--- a/drivers/rtc/rtc-ds1685.c
+++ b/drivers/rtc/rtc-ds1685.c
@@ -2145,27 +2145,7 @@ static struct platform_driver ds1685_rtc_driver = {
.probe = ds1685_rtc_probe,
.remove = ds1685_rtc_remove,
};
-
-/**
- * ds1685_rtc_init - rtc module init.
- */
-static int __init
-ds1685_rtc_init(void)
-{
- return platform_driver_register(&ds1685_rtc_driver);
-}
-
-/**
- * ds1685_rtc_exit - rtc module exit.
- */
-static void __exit
-ds1685_rtc_exit(void)
-{
- platform_driver_unregister(&ds1685_rtc_driver);
-}
-
-module_init(ds1685_rtc_init);
-module_exit(ds1685_rtc_exit);
+module_platform_driver(ds1685_rtc_driver);
/* --- */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: make decaying sched_avg's variables happen on period boundary
From: Byungchul Park
decaying time happens on every period boundary. if it does not reach
the period boundary yet, the partial time needs to be kept so that
the time can be decayed on exactly period boundary at next update.
sa->avg_period is not appropriate for getting partial delta_w because
the value is a decayed average value, with which we cannnot get partial
delta at all which does not reach the period boundary yet.
Signed-off-by: Byungchul Park
---
include/linux/sched.h |6 ++
kernel/sched/fair.c |4 +++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/include/linux/sched.h b/include/linux/sched.h
index 8aa4a25..2fdea70 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1192,6 +1192,12 @@ struct sched_avg {
* running_avg_sum.
*/
u32 runnable_avg_sum, avg_period, running_avg_sum;
+ /*
+* decaying time happens on every period boundary. if it does not reach
+* the period boundary yet, the partial time needs to be kept so that
+* the time can be decayed on exactly period boundary at next update.
+*/
+ u32 last_delta;
};
#ifdef CONFIG_SCHEDSTATS
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 09456fc..54ca11e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -680,6 +680,7 @@ void init_task_runnable_average(struct task_struct *p)
slice = sched_slice(task_cfs_rq(p), &p->se) >> 10;
p->se.avg.runnable_avg_sum = p->se.avg.running_avg_sum = slice;
p->se.avg.avg_period = slice;
+ p->se.avg.last_delta = 0;
__update_task_entity_contrib(&p->se);
__update_task_entity_utilization(&p->se);
}
@@ -2576,7 +2577,7 @@ static __always_inline int
__update_entity_runnable_avg(u64 now, int cpu,
sa->last_runnable_update = now;
/* delta_w is the amount already accumulated against our next period */
- delta_w = sa->avg_period % 1024;
+ delta_w = sa->last_delta % 1024;
if (delta + delta_w >= 1024) {
/* period roll-over */
decayed = 1;
@@ -2624,6 +2625,7 @@ static __always_inline int
__update_entity_runnable_avg(u64 now, int cpu,
sa->running_avg_sum += delta * scale_freq
>> SCHED_CAPACITY_SHIFT;
sa->avg_period += delta;
+ sa->last_delta = delta;
return decayed;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Input: elan_i2c - Change the hover event from MT to ST
We want the hover event like BTN_LEFT, even no contract object,
it still can be reported to upper OS system.
Signed-off by: Duson Lin
---
drivers/input/mouse/elan_i2c_core.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c
b/drivers/input/mouse/elan_i2c_core.c
index 62641f2..5b5f403 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -771,7 +771,7 @@ static const struct attribute_group *elan_sysfs_groups[] = {
*/
static void elan_report_contact(struct elan_tp_data *data,
int contact_num, bool contact_valid,
- bool hover_event, u8 *finger_data)
+ u8 *finger_data)
{
struct input_dev *input = data->input;
unsigned int pos_x, pos_y;
@@ -815,9 +815,7 @@ static void elan_report_contact(struct elan_tp_data *data,
input_mt_report_slot_state(input, MT_TOOL_FINGER, true);
input_report_abs(input, ABS_MT_POSITION_X, pos_x);
input_report_abs(input, ABS_MT_POSITION_Y, data->max_y - pos_y);
- input_report_abs(input, ABS_MT_DISTANCE, hover_event);
- input_report_abs(input, ABS_MT_PRESSURE,
-hover_event ? 0 : scaled_pressure);
+ input_report_abs(input, ABS_MT_PRESSURE, scaled_pressure);
input_report_abs(input, ABS_TOOL_WIDTH, mk_x);
input_report_abs(input, ABS_MT_TOUCH_MAJOR, major);
input_report_abs(input, ABS_MT_TOUCH_MINOR, minor);
@@ -839,14 +837,14 @@ static void elan_report_absolute(struct elan_tp_data
*data, u8 *packet)
hover_event = hover_info & 0x40;
for (i = 0; i < ETP_MAX_FINGERS; i++) {
contact_valid = tp_info & (1U << (3 + i));
- elan_report_contact(data, i, contact_valid, hover_event,
- finger_data);
+ elan_report_contact(data, i, contact_valid, finger_data);
if (contact_valid)
finger_data += ETP_FINGER_DATA_LEN;
}
input_report_key(input, BTN_LEFT, tp_info & 0x01);
+ input_report_abs(input, ABS_DISTANCE, hover_event != 0);
input_mt_report_pointer_emulation(input, true);
input_sync(input);
}
@@ -922,6 +920,7 @@ static int elan_setup_input_device(struct elan_tp_data
*data)
input_abs_set_res(input, ABS_Y, data->y_res);
input_set_abs_params(input, ABS_PRESSURE, 0, ETP_MAX_PRESSURE, 0, 0);
input_set_abs_params(input, ABS_TOOL_WIDTH, 0, ETP_FINGER_WIDTH, 0, 0);
+ input_set_abs_params(input, ABS_DISTANCE, 0, 1, 0, 0);
/* And MT parameters */
input_set_abs_params(input, ABS_MT_POSITION_X, 0, data->max_x, 0, 0);
@@ -934,7 +933,6 @@ static int elan_setup_input_device(struct elan_tp_data
*data)
ETP_FINGER_WIDTH * max_width, 0, 0);
input_set_abs_params(input, ABS_MT_TOUCH_MINOR, 0,
ETP_FINGER_WIDTH * min_width, 0, 0);
- input_set_abs_params(input, ABS_MT_DISTANCE, 0, 1, 0, 0);
data->input = input;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: lock-up with module: Optimize __module_address() using a latched RB-tree
I had a single, non-reproducible case of the same lock-up happening on my other machine running the Linus git head kernel in 64-bit mode. The kernel was built very similarly to the 32-bit mode kernel, using: CONCURRENCY_LEVEL=4 MAKEFLAGS="CC=gcc-5 LD=ld.gold KCFLAGS=-march=athlon64" \ make-kpkg --config menuconfig --initrd linux-image That machine has the following cpu: processor : 0 vendor_id : AuthenticAMD cpu family : 16 model : 5 model name : AMD Athlon(tm) II X4 640 Processor stepping: 3 microcode : 0x1c8 cpu MHz : 3000.000 cache size : 512 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 5 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt hw_pstate npt lbrv svm_lock nrip_save vmmcall bugs: tlb_mmatch apic_c1e fxsave_leak sysret_ss_attrs bogomips: 6015.47 TLB size: 1024 4K pages clflush size: 64 cache_alignment : 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm stc 100mhzsteps hwpstate The start of dmesg shows: [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Initializing cgroup subsys cpuacct [0.00] Linux version 4.2.0-rc1+ (root@am64) (gcc version 5.1.1 20150622 (Debian 5.1.1-12) ) #1815 SMP PREEMPT Tue Jul 7 13:13:00 ACST 2015 [0.00] Command line: BOOT_IMAGE=/vmlinuz-4.2.0-rc1+ root=UUID=39706f53-7c27-4310-b22a-36c7b042d1a1 ro radeon.audio=1 [0.00] tseg: 00 [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'lazy' FPU context switches. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009efff] usable [0.00] BIOS-e820: [mem 0x0009f000-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e4000-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcffa] usable [0.00] BIOS-e820: [mem 0xcffb-0xcffbdfff] ACPI data [0.00] BIOS-e820: [mem 0xcffbe000-0xcffd] ACPI NVS [0.00] BIOS-e820: [mem 0xcffe-0xcfff] reserved [0.00] BIOS-e820: [mem 0xff70-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00022fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.5 present. [0.00] DMI: System manufacturer System Product Name/M3A78 PRO, BIOS 170101/27/2011 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x23 max_arch_pfn = 0x4 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base mask 8000 write-back [0.00] 1 base 8000 mask C000 write-back [0.00] 2 base C000 mask F000 write-back [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] TOM2: 00023000 aka 8960M [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WC UC- WT [0.00] e820: update [mem 0xd000-0x] usable ==> reserved [0.00] e820: last_pfn = 0xcffb0 max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000ff780-0x000ff78f] mapped at [880ff780] [0.00] Base memory trampoline at [88098000] 98000 size 28672 [0.00] Using GB pages for direct mapping [0.00] init_memory_mapping: [mem 0x-0x000f] [0.00] [mem 0x-0x000f] page 4k [0.00] BRK [0x0292e000, 0x0292efff] PGTABLE [0.00] BRK [0x0292f000, 0x0292] PGTABLE [0.00] BRK [0x0293, 0x02930fff] PGTABLE [0.00] init_memory_mapping: [mem 0x22fe0-0x22fff] [0.00] [mem 0x22fe0-0x22fff] page 2M [0.00] BRK [0x02931000, 0x02931fff] PGTABLE [0.00] init_memory_mapping: [mem 0x22000-0x22fdf] [0.00] [mem 0x22000-0x22fdf] page 2M [0.00] init_memory_mapping: [mem 0x2-0x21fff] [0.00] [mem 0x2-0x21
[PATCH] coresight: replicator: Use module_platform_driver
Use module_platform_driver for drivers whose init and exit functions
only register and unregister, respectively.
A simplified version of the Coccinelle semantic patch that performs
this transformation is as follows:
@a@
identifier f, x;
@@
-static f(...) { return platform_driver_register(&x); }
@b depends on a@
identifier e, a.x;
@@
-static e(...) { platform_driver_unregister(&x); }
@c depends on a && b@
identifier a.f;
declarer name module_init;
@@
-module_init(f);
@d depends on a && b && c@
identifier b.e, a.x;
declarer name module_exit;
declarer name module_platform_driver;
@@
-module_exit(e);
+module_platform_driver(x);
Signed-off-by: Vaishali Thakkar
---
drivers/hwtracing/coresight/coresight-replicator.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/hwtracing/coresight/coresight-replicator.c
b/drivers/hwtracing/coresight/coresight-replicator.c
index 7974b7c..df45932 100644
--- a/drivers/hwtracing/coresight/coresight-replicator.c
+++ b/drivers/hwtracing/coresight/coresight-replicator.c
@@ -183,18 +183,7 @@ static struct platform_driver replicator_driver = {
.pm = &replicator_dev_pm_ops,
},
};
-
-static int __init replicator_init(void)
-{
- return platform_driver_register(&replicator_driver);
-}
-module_init(replicator_init);
-
-static void __exit replicator_exit(void)
-{
- platform_driver_unregister(&replicator_driver);
-}
-module_exit(replicator_exit);
+module_platform_driver(replicator_driver);
MODULE_LICENSE("GPL v2");
MODULE_DESCRIPTION("CoreSight Replicator driver");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Query: Clock driver requests mailbox channel
On Mon, Jul 6, 2015 at 5:03 PM, Leo Yan wrote: > Hi all, > > i'm working with one clock driver, which will invoke mailbox API to > request the mailbox channel and send message. > > Usually clock driver will init with devicetree, below is the example: > CLK_OF_DECLARE(hi6220_clk_power, "hisilicon,hi6220-clock-power", > hi6220_clk_power_init); > > Clock init function it will pass the pointer of struct device_node > but not the pointer of struct device. So finally it's difficult to > invoke mailbox API *mbox_request_channel()*, due it need use the > struct device to search DT's property "mboxes". > > I want to find which is the best way to resolve this issue, so do you > suggest clock driver to manually register one device? Or can we add > one more API to request the mailbox channel directly with device_node? > IIUC, such clocks (that require platform resources) should be populated from the platform_device's probe()? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Tools: hv: kvp: fix a build warning -Wformat-security
It is to fix:
hv_kvp_daemon.c:705:2: warning: format not a string literal and no format
arguments [-Wformat-security]
Signed-off-by: Dexuan Cui
---
tools/hv/hv_kvp_daemon.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/hv/hv_kvp_daemon.c b/tools/hv/hv_kvp_daemon.c
index 0d9f48e..f9d5089 100644
--- a/tools/hv/hv_kvp_daemon.c
+++ b/tools/hv/hv_kvp_daemon.c
@@ -702,7 +702,7 @@ static char *kvp_mac_to_if_name(char *mac)
if (dir == NULL)
return NULL;
- snprintf(dev_id, sizeof(dev_id), kvp_net_dir);
+ snprintf(dev_id, sizeof(dev_id), "%s", kvp_net_dir);
q = dev_id + strlen(kvp_net_dir);
while ((entry = readdir(dir)) != NULL) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v6 3/3] drivers: nvmem: Add Vybrid OCOTP support
Hello Stefan,
On 15-07-06 12:16:34, Stefan Wahren wrote:
> Hi Sanchayan,
>
> > Sanchayan Maity hat am 29. Juni 2015 um 13:22
> > geschrieben:
> >
> >
> > The patch adds support for the On Chip One Time Programmable Peripheral
> > (OCOTP) on the Vybrid platform.
>
> please provide a changelog in your cover letter and a new version after
> changes.
>
> I think it's important to note that the driver only support read-only access.
Ok. Will mention this explicitly in the next version.
>
> >
> > Signed-off-by: Sanchayan Maity
> > ---
> > drivers/nvmem/Kconfig | 10 ++
> > drivers/nvmem/Makefile | 2 +
> > drivers/nvmem/vf610-ocotp.c | 250
> >
> > 3 files changed, 262 insertions(+)
> > create mode 100644 drivers/nvmem/vf610-ocotp.c
> >
> > diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> > index 17f1a57..84c830d 100644
> > --- a/drivers/nvmem/Kconfig
> > +++ b/drivers/nvmem/Kconfig
> > @@ -33,4 +33,14 @@ config NVMEM_SUNXI_SID
> > This driver can also be built as a module. If so, the module
> > will be called eeprom-sunxi-sid.
> >
> > +config NVMEM_VF610_OCOTP
> > + tristate "VF610 SoCs OCOTP support"
> > + depends on SOC_VF610
> > + help
> > + This is a driver for the 'OCOTP' available on various Vybrid
> > + devices.
>
> I don't know much about Vybrid. But this driver is specific for VF610, isn't
> it?
Sorry. I only checked on VF50 and VF61. Will check if is it available with the
other Vybrid devices and change if it is not so.
>
> > +
> > + This driver can also be built as a module. If so, the module
> > + will be called nvmem-vf610-ocotp.
> > +
> > endif
> > diff --git a/drivers/nvmem/Makefile b/drivers/nvmem/Makefile
> > index cc46791..a9ed113 100644
> > --- a/drivers/nvmem/Makefile
> > +++ b/drivers/nvmem/Makefile
> > @@ -11,3 +11,5 @@ obj-$(CONFIG_QCOM_QFPROM) += nvmem_qfprom.o
> > nvmem_qfprom-y := qfprom.o
> > obj-$(CONFIG_NVMEM_SUNXI_SID) += nvmem-sunxi-sid.o
> > nvmem-sunxi-sid-y := sunxi-sid.o
> > +obj-$(CONFIG_NVMEM_VF610_OCOTP) += nvmem-vf610-ocotp.o
> > +nvmem-vf610-ocotp-y := vf610-ocotp.o
> > diff --git a/drivers/nvmem/vf610-ocotp.c b/drivers/nvmem/vf610-ocotp.c
> > new file mode 100644
> > index 000..b7a782c
> > --- /dev/null
> > +++ b/drivers/nvmem/vf610-ocotp.c
> > @@ -0,0 +1,250 @@
> > +/*
> > + * Copyright (C) 2015 Sanchayan Maity
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 and
> > + * only version 2 as published by the Free Software Foundation.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +/* OCOTP Register Offsets */
> > +#define OCOTP_CTRL_REG 0x00
> > +#define OCOTP_CTRL_SET 0x04
> > +#define OCOTP_CTRL_CLR 0x08
> > +#define OCOTP_TIMING 0x10
> > +#define OCOTP_DATA 0x20
> > +#define OCOTP_READ_CTRL_REG 0x30
> > +#define OCOTP_READ_FUSE_DATA 0x40
> > +
> > +/* OCOTP Register bits and masks */
> > +#define OCOTP_CTRL_WR_UNLOCK 16
> > +#define OCOTP_CTRL_WR_UNLOCK_KEY 0x3E77
> > +#define OCOTP_CTRL_WR_UNLOCK_MASK 0x
> > +#define OCOTP_CTRL_ADDR 0
> > +#define OCOTP_CTRL_ADDR_MASK 0x7F
> > +#define OCOTP_CTRL_RELOAD_SHADOWS (0x1 << 10)
> > +#define OCOTP_CTRL_ERROR (0x1 << 9)
> > +#define OCOTP_CTRL_BUSY (0x1 << 8)
>
> You can use the BIT() macro here.
Ok.
>
> > +
> > +#define OCOTP_TIMING_STROBE_READ 16
> > +#define OCOTP_TIMING_STROBE_READ_MASK 0x003F
> > +#define OCOTP_TIMING_RELAX 12
> > +#define OCOTP_TIMING_RELAX_MASK 0xF000
> > +#define OCOTP_TIMING_STROBE_PROG 0
> > +#define OCOTP_TIMING_STROBE_PROG_MASK 0x0FFF
> > +
> > +#define OCOTP_READ_CTRL_READ_FUSE 0x1
> > +
> > +#define VF610_OCOTP_TIMEOUT 10
> > +
> > +#define BF(value, field) (((value) << field) & field##_MASK)
> > +
> > +#define DEF_RELAX 20
> > +
> > +struct vf610_ocotp_dev {
> > + void __iomem *base;
> > + struct clk *clk;
> > + struct device *dev;
> > + struct resource *res;
> > + struct regmap *regmap;
> > + struct nvmem_device *nvmem;
> > +};
>
> Some member of this struct seems unnecessary to me. Please
> remove the unused one.
>
> > +
> > +static int ocotp_timing;
>
> How about storing the timings in struct above?
Ok.
>
> > +
> > +static u8 valid_fuse_addr[] = {
> > + 0x00, 0x01, 0x02, 0x04, 0x0F, 0x20, 0x21, 0x22, 0x23, 0x24,
> > + 0x25, 0x26, 0x27, 0x28, 0x2F, 0x38, 0x39, 0x3A, 0x3B, 0x3C,
> > + 0x3D, 0x3E, 0x3F
> > +};
>
> const?
Right.
>
> > +
> > +static int vf610_ocotp_wait_busy(void __iomem *base)
> > +{
> > + int timeout = VF610_OCOTP_TIMEOUT;
> > +
> > + while ((readl(base) & OCOTP_CTRL_BU
RE: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
Hi Felipe, > -Original Message- > From: Felipe Balbi [mailto:ba...@ti.com] > Sent: Monday, July 06, 2015 10:38 PM > To: Subbaraya Sundeep Bhatta > Cc: ba...@ti.com; gre...@linuxfoundation.org; linux-...@vger.kernel.org; > linux-kernel@vger.kernel.org; sta...@vger.kernel.org > Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command > sent to DEPCMD register fails > > On Wed, Jul 01, 2015 at 07:29:28AM +, Subbaraya Sundeep Bhatta > wrote: > > Hi Felipe, > > > > > -Original Message- > > > From: Felipe Balbi [mailto:ba...@ti.com] > > > Sent: Tuesday, June 30, 2015 3:17 AM > > > To: Subbaraya Sundeep Bhatta > > > Cc: ba...@ti.com; gre...@linuxfoundation.org; > > > linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; > > > sta...@vger.kernel.org; Subbaraya Sundeep Bhatta > > > Subject: Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if > > > command sent to DEPCMD register fails > > > > > > Hi, > > > > > > On Thu, May 21, 2015 at 03:46:48PM +0530, Subbaraya Sundeep > Bhatta > > > wrote: > > > > We need to return error to caller if command is not sent to > > > > controller succesfully. > > > > > > > > Signed-off-by: Subbaraya Sundeep Bhatta > > > > Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) > > > > Cc: > > > > --- > > > > v2 changes: > > > > Added Fixes and Cc in commit message. > > > > > > I noticed that this breaks at least my AM437x silicon with DWC3 > > > 2.40a when used with g_zero and testusb. As of now, it could be that > > > silicon is mis-behaving because I got a Transfer Complete before the > > > failing Set Endpoint Transfer Resource command. > > > > > > In any case, can you run on your setup with g_zero and > > > test.sh/testusb [1]/[2] just to verify that it really works for you ? > > > > Ok I will do that. > > Did you manage to run the test I asked ? If we don't get down to this, I'll > have to revert your patch as it regresses my platforms. Sorry I caught up with some other customer reported issue on Zynq (Chipidea). I will do it by this weekend at any cost. Please wait. Thanks, Sundeep.B.S. > > -- > balbi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] ipc: Modify message queue accounting to not take kernel data structures into account
On Mon, 2015-07-06 at 17:49 +0200, Marcus Gelderie wrote: > A while back, the message queue implementation in the kernel was > improved to use btrees to speed up retrieval of messages (commit > d6629859b36). The patch introducing the improved kernel handling of > message queues (using btrees) has, as a by-product, changed the > meaning of the QSIZE field in the pseudo-file created for the queue. > Before, this field reflected the size of the user-data in the queue. > Since, it also takes kernel data structures into account. For > example, if 13 bytes of user data are in the queue, on my machine the > file reports a size of 61 bytes. > > There was some discussion on this topic before (for example > https://lkml.org/lkml/2014/10/1/115). Commenting on a th lkml, Michael > Kerrisk gave the following background (https://lkml.org/lkml/2015/6/16/74): > > The pseudofiles in the mqueue filesystem (usually mounted at > /dev/mqueue) expose fields with metadata describing a message > queue. One of these fields, QSIZE, as originally implemented, > showed the total number of bytes of user data in all messages in > the message queue, and this feature was documented from the > beginning in the mq_overview(7) page. In 3.5, some other (useful) > work happened to break the user-space API in a couple of places, > including the value exposed via QSIZE, which now includes a measure > of kernel overhead bytes for the queue, a figure that renders QSIZE > useless for its original purpose, since there's no way to deduce > the number of overhead bytes consumed by the implementation. > (The other user-space breakage was subsequently fixed.) Michael, this breakage was never finally documented in the manpage, right? I took a look and there is no mention, but it was a quick look. It's just that if this patch goes in, I'd hate ending up with something like this in the manpage: as of 3.5 as of 4.3 If there are changes to be made to the manpage, it should probably be posted with this patch, methinks. > > This patch removes the accounting of kernel data structures in the > queue. Reporting the size of these data-structures in the QSIZE field > was a breaking change (see Michael's comment above). Without the QSIZE > field reporting the total size of user-data in the queue, there is no > way to deduce this number. > > It should be noted that the resource limit RLIMIT_MSGQUEUE is counted > against the worst-case size of the queue (in both the old and the new > implementation). Therefore, the kernel overhead accounting in QSIZE is > not necessary to help the user understand the limitations RLIMIT imposes > on the processes. Also, I would suggest adding some comment in struct mqueue_inode_info for future reference, ie: - unsigned long qsize; /* size of queue in memory (sum of all msgs) */ + /* +* Size of queue in memory (sum of all msgs). Accounts for +* only userspace overhead; ignoring any in-kernel rbtree nodes. +*/ + unsigned long qsize; But no big deal in any case. I think this is the right approach, but would still like to know if Doug has any concerns about it. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 5/6] clk: sunxi: make use of of_clk_parent_fill helper function
Hi Dinh, On Mon, Jul 06, 2015 at 10:59:05PM -0500, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > Use of_clk_parent_fill to fill in the parent clock names' array. > > Signed-off-by: Dinh Nguyen > Cc: Maxime Ripard > Cc: "Emilio López" Acked-by: Maxime Ripard Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v4] clk: change clk_ops' ->determine_rate() prototype
Hi Stephen,
On Mon, 6 Jul 2015 14:32:10 -0700
Stephen Boyd wrote:
> On 07/06, Boris Brezillon wrote:
> > Clock rates are stored in an unsigned long field, but ->determine_rate()
> > (which returns a rounded rate from a requested one) returns a long
> > value (errors are reported using negative error codes), which can lead
> > to long overflow if the clock rate exceed 2Ghz.
> >
> > Change ->determine_rate() prototype to return 0 or an error code, and pass
> > a pointer to a clk_rate_request structure containing the expected target
> > rate and the rate constraints imposed by clk users.
> >
> > The clk_rate_request structure might be extended in the future to contain
> > other kind of constraints like the rounding policy, the maximum clock
> > inaccuracy or other things that are not yet supported by the CCF
> > (power consumption constraints ?).
> >
> > Signed-off-by: Boris Brezillon
>
> Which files did you compile?
>
> drivers/clk/mmp/clk-mix.c: In function ‘mmp_clk_mix_determine_rate’:
> drivers/clk/mmp/clk-mix.c:221:13: error: ‘rate’ undeclared (first use in this
> function)
>
Hm, I only compile tested the multi_v5 and multi_v7 defconfigs, and
obviously it was a bad idea (just thought all the impacted platforms
were already converted to multiplatform support).
[...]
> > -long omap3_noncore_dpll_determine_rate(struct clk_hw *hw, unsigned long
> > rate,
> > - unsigned long min_rate,
> > - unsigned long max_rate,
> > - unsigned long *best_parent_rate,
> > - struct clk_hw **best_parent_clk)
> > +int omap3_noncore_dpll_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > {
> > struct clk_hw_omap *clk = to_clk_hw_omap(hw);
> > struct dpll_data *dd;
> >
> > - if (!hw || !rate)
> > + if (!hw || !req || !req->rate)
>
> Why do we need to check for req? It shouldn't be NULL.
We don't, I'll remove this test.
[...]
> > -long omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw, unsigned long
> > rate,
> > - unsigned long min_rate,
> > - unsigned long max_rate,
> > - unsigned long *best_parent_rate,
> > - struct clk_hw **best_parent_clk)
> > +int omap4_dpll_regm4xen_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > {
> > struct clk_hw_omap *clk = to_clk_hw_omap(hw);
> > struct dpll_data *dd;
> >
> > - if (!hw || !rate)
> > + if (!hw || !req || !req->rate)
>
> Same comment here. And why would we care about hw being NULL
> either for that matter.
Yes, but I'm not sure this removal should be done in the same patch.
Let me know if you think otherwise.
> > -static long mmc_clk_determine_rate(struct clk_hw *hw, unsigned long rate,
> > - unsigned long min_rate,
> > - unsigned long max_rate,
> > - unsigned long *best_parent_rate,
> > - struct clk_hw **best_parent_p)
> > +static int mmc_clk_determine_rate(struct clk_hw *hw,
> > + struct clk_rate_request *req)
> > {
> > struct clk_mmc *mclk = to_mmc(hw);
> > - unsigned long best = 0;
> >
> > - if ((rate <= 1300) && (mclk->id == HI3620_MMC_CIUCLK1)) {
> > - rate = 1300;
> > - best = 2600;
> > - } else if (rate <= 2600) {
> > - rate = 2500;
> > - best = 18000;
> > - } else if (rate <= 5200) {
> > - rate = 5000;
> > - best = 36000;
> > - } else if (rate <= 1) {
> > - rate = 1;
> > - best = 72000;
> > + req->best_parent_hw = __clk_get_hw(__clk_get_parent(hw->clk));
> > +
>
> Where did this come from? We weren't setting the best_parent_p
> pointer before.
It comes from a previous version where I was not assigning the
->best_parent_hw field to the current parent in the core code.
I fixed it in the meantime, but forgot to remove this assignment.
> > -static long
> > -clk_pll_determine_rate(struct clk_hw *hw, unsigned long rate,
> > - unsigned long min_rate, unsigned long max_rate,
> > - unsigned long *p_rate, struct clk_hw **p)
> > +static int
> > +clk_pll_determine_rate(struct clk_hw *hw, struct clk_rate_request *req)
> > {
> > + struct clk *parent = __clk_get_parent(hw->clk);
> > struct clk_pll *pll = to_clk_pll(hw);
> > const struct pll_freq_tbl *f;
> >
> > - f = find_freq(pll->freq_tbl, rate);
> > + req->best_parent_hw = __clk_get_hw(parent);
> > + req->best_parent_rate = __clk_get_rate(parent);
> > +
> > + f = find_freq(pll->freq_tbl, req->rate);
> > if (!f)
> > - return clk_pll_recalc_rate(hw, *p_rate);
> > +
Re: [PATCH] staging: lustre: obdclass: fix macro coding style issue in uuid.c
On Mon, 2015-07-06 at 19:36 -0700, Greg KH wrote: > On Fri, Jun 26, 2015 at 11:04:49PM -0700, Joe Perches wrote: > > On Sat, 2015-06-27 at 06:36 +0100, Vasiliy Korchagin wrote: [] > > > Here is another version with macro expansion. Inline function > > > expansion doesn't > > > seem like a good idea to me as it would make things overcomplicated. > > > > It looks like it'd be simpler to use vsprintf extension %pU [] > > diff --git a/drivers/staging/lustre/lustre/obdclass/uuid.c > > b/drivers/staging/lustre/lustre/obdclass/uuid.c [] > > + sprintf(out->uuid, "%pU", uu); > > } > > EXPORT_SYMBOL(class_uuid_unparse); > > I agree, much better, can you resend this in a form I can apply? Vasiliy, you started this, can you submit this under your name please? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] bio integrity: do not assume bio_integrity_pool exists if bioset exists
On Wed, Jul 01 2015 at 12:57pm -0400,
Mike Snitzer wrote:
> bio_integrity_alloc() and bio_integrity_free() assume that if a bio was
> allocated from a bioset that that bioset also had its bio_integrity_pool
> allocated using bioset_integrity_create(). This is a very bad
> assumption given that bioset_create() and bioset_integrity_create() are
> completely disjoint. Not all callers of bioset_create() have been
> trained to also call bioset_integrity_create() -- and they may not care
> to be.
>
> Fix this by falling back to kmalloc'ing 'struct bio_integrity_payload'
> rather than force all bioset consumers to (wastefully) preallocate a
> bio_integrity_pool that they very likely won't actually need (given the
> niche nature of the current block integrity support).
>
> Otherwise, a NULL pointer "Kernel BUG" with a trace like the following
> will be observed (as seen on s390x using zfcp storage) because dm-io
> doesn't use bioset_integrity_create() when creating its bioset:
>
> [ 791.643338] Call Trace:
> [ 791.643339] ([<0003df98b848>] 0x3df98b848)
> [ 791.643341] [<002c5de8>] bio_integrity_alloc+0x48/0xf8
> [ 791.643348] [<002c6486>] bio_integrity_prep+0xae/0x2f0
> [ 791.643349] [<00371e38>] blk_queue_bio+0x1c8/0x3d8
> [ 791.643355] [<0036f8d0>] generic_make_request+0xc0/0x100
> [ 791.643357] [<0036f9b2>] submit_bio+0xa2/0x198
> [ 791.643406] [<03ff801f9774>] dispatch_io+0x15c/0x3b0 [dm_mod]
> [ 791.643419] [<03ff801f9b3e>] dm_io+0x176/0x2f0 [dm_mod]
> [ 791.643423] [<03ff8074b28a>] do_reads+0x13a/0x1a8 [dm_mirror]
> [ 791.643425] [<03ff8074b43a>] do_mirror+0x142/0x298 [dm_mirror]
> [ 791.643428] [<00154fca>] process_one_work+0x18a/0x3f8
> [ 791.643432] [<0015598a>] worker_thread+0x132/0x3b0
> [ 791.643435] [<0015d49a>] kthread+0xd2/0xd8
> [ 791.643438] [<005bc0ca>] kernel_thread_starter+0x6/0xc
> [ 791.643446] [<005bc0c4>] kernel_thread_starter+0x0/0xc
>
> Signed-off-by: Mike Snitzer
> Cc: sta...@vger.kernel.org
> ---
> block/bio-integrity.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> NOTE: this serves as a more generic fix in the block layer rather than
> the dm-io specific fix which isn't ideal (due to potential for memory
> waste), see:
> https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=for-next&id=17dbe96d4f8a6f87004e6cfb5944872dfe2edb9f
>
> diff --git a/block/bio-integrity.c b/block/bio-integrity.c
> index 0436c21..719b715 100644
> --- a/block/bio-integrity.c
> +++ b/block/bio-integrity.c
> @@ -51,7 +51,7 @@ struct bio_integrity_payload *bio_integrity_alloc(struct
> bio *bio,
> unsigned long idx = BIO_POOL_NONE;
> unsigned inline_vecs;
>
> - if (!bs) {
> + if (!bs || !bs->bio_integrity_pool) {
> bip = kmalloc(sizeof(struct bio_integrity_payload) +
> sizeof(struct bio_vec) * nr_vecs, gfp_mask);
> inline_vecs = nr_vecs;
> @@ -104,7 +104,7 @@ void bio_integrity_free(struct bio *bio)
> kfree(page_address(bip->bip_vec->bv_page) +
> bip->bip_vec->bv_offset);
>
> - if (bs) {
> + if (bs && bs->bio_integrity_pool) {
> if (bip->bip_slab != BIO_POOL_NONE)
> bvec_free(bs->bvec_integrity_pool, bip->bip_vec,
> bip->bip_slab);
> --
> 2.3.2 (Apple Git-55)
>
>
Both the above block patch and the referenced dm-io patch fix the
following issue. I really prefer the block fix over the dm-io one. As
such I'd like to see it go upstream during 4.2-rc.
Jens, what do you think?
Here is an updated NULL pointer trace using 4.2-rc1 (which is easily hit
using the attached reproducer script):
[ 239.425111] BUG: unable to handle kernel NULL pointer dereference at
0048
[ 239.426010] IP: [] mempool_alloc+0x60/0x180
[ 239.426010] PGD 0
[ 239.426010] Oops: [#1] SMP
[ 239.426010] Modules linked in: dm_mirror dm_region_hash dm_log scsi_debug sg
nfsv3 nfs fscache crct10dif_pclmul crc32_pclmul crc32c_intel
ghash_clmulni_intel aesni_intel glue_helper lrw gf128mul ablk_helper dm_mod
cryptd pcspkr serio_raw virtio_balloon 8139too i2c_piix4 nfsd auth_rpcgss
nfs_acl lockd grace sunrpc ext4 mbcache jbd2 ata_generic sd_mod pata_acpi
cirrus syscopyarea sysfillrect sysimgblt drm_kms_helper virtio_scsi ttm
virtio_blk drm ata_piix libata virtio_pci virtio_ring 8139cp virtio mii
i2c_core floppy
[ 239.426010] CPU: 2 PID: 134 Comm: kworker/2:2 Not tainted 4.2.0-rc1+ #59
[ 239.426010] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
[ 239.426010] Workqueue: kcopyd do_work [dm_mod]
[ 239.426010] task: 88011a701bc0 ti: 880036a1 task.ti:
880036a1
[ 239.426010] RIP: 0010:[] []
mempool_alloc+0x60/0x180
[ 239.426010] RSP: 0018:880036a13878 EFLAGS: 00
Re: [PATCHv6 1/2] dts: Adding docs for Xilinx LogiCORE IP mailbox driver.
On Mon, Jul 6, 2015 at 10:57 PM, Sören Brinkmann
wrote:
> On Mon, 2015-07-06 at 10:16AM -0700, Moritz Fischer wrote:
>> Signed-off-by: Moritz Fischer
>> Acked-by: Michal Simek
>> ---
>> .../devicetree/bindings/mailbox/xilinx-mailbox.txt | 44
>> ++
>> 1 file changed, 44 insertions(+)
>> create mode 100644
>> Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>> b/Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>> new file mode 100644
>> index 000..97b81f8
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mailbox/xilinx-mailbox.txt
>> @@ -0,0 +1,44 @@
>> +Xilinx Mailbox Driver
>> +=
>> +
>> +Required properties:
>> +- compatible : "xlnx,mailbox-2.1".
>> +- reg : physical base address of the mailbox and length of
>> + memory mapped region.
>> +- #mbox-cells : common mailbox binding property to identify the number
>> + of cells required for the mailbox specifier, should
>> be 0
>> +- clocks : phandle to clock provider
>> +- clock-names : must be 'mbox'
>> +
>> +Optional properties:
>> +- interrupt-parent : interrupt source phandle
>> +- interrupts : interrupt number, The interrupt specifier format
>> + depends on the interrupt controller parent.
>> +
>> +Example:
>> + mbox: mailbox@4040 {
>> + compatible = "xlnx,mailbox-2.1";
>> + reg = <0x4040 0x100>;
>> + interrupt-parent = <&intc>;
>> + interrupts = <5>;
>> + #mbox-cells = <0>;
>> + clocks = <&clkc 15>;
>> + clock-names = "mbox";
>> + };
>> +
>> +Mailbox client
>> +===
>> +"mboxes" and the optional "mbox-names" (please see
>> +Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each
>> value
>> +of the mboxes property should contain a phandle to the mailbox controller
>> +device node and second argument is the channel index. It must be 0 (hardware
>> +support only one channel). The equivalent "mbox-names" property value can be
>> +used to give a name to the communication channel to be used by the client
>> user.
>> +
>> +Example:
>> + mclient0: mclient0@400 {
>> + compatible = "client-1.0";
>> + reg = <0x400 0x10>;
>> + mbox-names = "mbox";
>> + mboxes = <&mbox 0>;
>
> Sorry, to bring this up again, but I'm confused regarding the #mbox-cells
> thing. Above it says #mbox-cells is 0. In that case, shouldn't the
> 'mboxes' property not only be '<&mbox>'?
>
Yeah, this is inconsistent. Either provide your own of_xlate() for
#cells=0 or have #cells=1 to use stock of_xlate() and specify <&mbox
0> for the channel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: let __sched_period() use rq cfs's nr_running
From: Byungchul Park
__sched_period() returns a period which a rq can have. the period has to be
stretched by the number of task *the rq has*, when nr_running > nr_latency.
otherwise, task slice can be very smaller than sysctl_sched_min_granularity
depending on the position of tg hierarchy when CONFIG_FAIR_GROUP_SCHED.
Signed-off-by: Byungchul Park
---
kernel/sched/fair.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 09456fc..1adacb8 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -635,7 +635,7 @@ static u64 __sched_period(unsigned long nr_running)
*/
static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se)
{
- u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq);
+ u64 slice = __sched_period(rq_of(cfs_rq)->cfs.nr_running + !se->on_rq);
for_each_sched_entity(se) {
struct load_weight *load;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFCv3 2/5] mm/compaction: enable mobile-page migration
From: Gioh Kim
Add framework to register callback functions and check page mobility.
There are some modes for page isolation so that isolate interface
has arguments of page address and isolation mode while putback
interface has only page address as argument.
Signed-off-by: Gioh Kim
---
fs/proc/page.c | 3 ++
include/linux/compaction.h | 76 ++
include/linux/fs.h | 2 +
include/linux/page-flags.h | 19 +
include/uapi/linux/kernel-page-flags.h | 1 +
5 files changed, 101 insertions(+)
diff --git a/fs/proc/page.c b/fs/proc/page.c
index 7eee2d8..a4f5a00 100644
--- a/fs/proc/page.c
+++ b/fs/proc/page.c
@@ -146,6 +146,9 @@ u64 stable_page_flags(struct page *page)
if (PageBalloon(page))
u |= 1 << KPF_BALLOON;
+ if (PageMobile(page))
+ u |= 1 << KPF_MOBILE;
+
u |= kpf_copy_bit(k, KPF_LOCKED,PG_locked);
u |= kpf_copy_bit(k, KPF_SLAB, PG_slab);
diff --git a/include/linux/compaction.h b/include/linux/compaction.h
index aa8f61c..c375a89 100644
--- a/include/linux/compaction.h
+++ b/include/linux/compaction.h
@@ -1,6 +1,9 @@
#ifndef _LINUX_COMPACTION_H
#define _LINUX_COMPACTION_H
+#include
+#include
+
/* Return values for compact_zone() and try_to_compact_pages() */
/* compaction didn't start as it was deferred due to past failures */
#define COMPACT_DEFERRED 0
@@ -51,6 +54,66 @@ extern void compaction_defer_reset(struct zone *zone, int
order,
bool alloc_success);
extern bool compaction_restarting(struct zone *zone, int order);
+static inline bool mobile_page(struct page *page)
+{
+ return page->mapping && page->mapping->a_ops &&
+ (PageMobile(page) || PageBalloon(page));
+}
+
+static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
+{
+ bool ret;
+
+ /*
+* Avoid burning cycles with pages that are yet under __free_pages(),
+* or just got freed under us.
+*
+* In case we 'win' a race for a mobile page being freed under us and
+* raise its refcount preventing __free_pages() from doing its job
+* the put_page() at the end of this block will take care of
+* release this page, thus avoiding a nasty leakage.
+*/
+ if (likely(get_page_unless_zero(page))) {
+ /*
+* As mobile pages are not isolated from LRU lists, concurrent
+* compaction threads can race against page migration functions
+* as well as race against the releasing a page.
+*
+* In order to avoid having an already isolated mobile page
+* being (wrongly) re-isolated while it is under migration,
+* or to avoid attempting to isolate pages being released,
+* lets be sure we have the page lock
+* before proceeding with the mobile page isolation steps.
+*/
+ if (likely(trylock_page(page))) {
+ if (mobile_page(page) &&
+ page->mapping->a_ops->isolatepage) {
+ ret = page->mapping->a_ops->isolatepage(page,
+ mode);
+ unlock_page(page);
+ return ret;
+ }
+ unlock_page(page);
+ }
+ put_page(page);
+ }
+ return false;
+}
+
+static inline void putback_mobilepage(struct page *page)
+{
+ /*
+* 'lock_page()' stabilizes the page and prevents races against
+* concurrent isolation threads attempting to re-isolate it.
+*/
+ lock_page(page);
+ if (mobile_page(page) && page->mapping->a_ops->putbackpage) {
+ page->mapping->a_ops->putbackpage(page);
+ /* drop the extra ref count taken for mobile page isolation */
+ put_page(page);
+ }
+ unlock_page(page);
+}
#else
static inline unsigned long try_to_compact_pages(gfp_t gfp_mask,
unsigned int order, int alloc_flags,
@@ -83,6 +146,19 @@ static inline bool compaction_deferred(struct zone *zone,
int order)
return true;
}
+static inline bool mobile_page(struct page *page)
+{
+ return false;
+}
+
+static inline bool isolate_mobilepage(struct page *page, isolate_mode_t mode)
+{
+ return false;
+}
+
+static inline void putback_mobilepage(struct page *page)
+{
+}
#endif /* CONFIG_COMPACTION */
#if defined(CONFIG_COMPACTION) && defined(CONFIG_SYSFS) && defined(CONFIG_NUMA)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 35ec87e..33c9aa5 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -395,6 +395,8 @@ struct address_space_operations {
[RFCv3 1/5] fs/anon_inodes: new interface to create new inode
From: Gioh Kim
The anon_inodes has already complete interfaces to create manage
many anonymous inodes but don't have interface to get
new inode. Other sub-modules can create anonymous inode
without creating and mounting it's own pseudo filesystem.
Signed-off-by: Gioh Kim
---
fs/anon_inodes.c| 6 ++
include/linux/anon_inodes.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 80ef38c..1d51f96 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -162,6 +162,12 @@ err_put_unused_fd:
}
EXPORT_SYMBOL_GPL(anon_inode_getfd);
+struct inode *anon_inode_new(void)
+{
+ return alloc_anon_inode(anon_inode_mnt->mnt_sb);
+}
+EXPORT_SYMBOL_GPL(anon_inode_new);
+
static int __init anon_inode_init(void)
{
anon_inode_mnt = kern_mount(&anon_inode_fs_type);
diff --git a/include/linux/anon_inodes.h b/include/linux/anon_inodes.h
index 8013a45..ddbd67f 100644
--- a/include/linux/anon_inodes.h
+++ b/include/linux/anon_inodes.h
@@ -15,6 +15,7 @@ struct file *anon_inode_getfile(const char *name,
void *priv, int flags);
int anon_inode_getfd(const char *name, const struct file_operations *fops,
void *priv, int flags);
+struct inode *anon_inode_new(void);
#endif /* _LINUX_ANON_INODES_H */
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFCv3 5/5] mm: remove direct calling of migration
From: Gioh Kim
Migration is completely generalized so that migrating mobile page
is processed with lru-pages in move_to_new_page.
Signed-off-by: Gioh Kim
---
mm/balloon_compaction.c | 8
mm/migrate.c| 13 -
2 files changed, 21 deletions(-)
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index 0dd0b0d..9d07ed9 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -170,13 +170,6 @@ int balloon_page_migrate(struct address_space *mapping,
if (!isolated_balloon_page(page))
return rc;
- /*
-* Block others from accessing the 'newpage' when we get around to
-* establishing additional references. We should be the only one
-* holding a reference to the 'newpage' at this point.
-*/
- BUG_ON(!trylock_page(newpage));
-
if (WARN_ON(!__is_movable_balloon_page(page))) {
dump_page(page, "not movable balloon page");
unlock_page(newpage);
@@ -186,7 +179,6 @@ int balloon_page_migrate(struct address_space *mapping,
if (balloon && balloon->migratepage)
rc = balloon->migratepage(balloon, newpage, page, mode);
- unlock_page(newpage);
return rc;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index e22be67..b82539b 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -844,19 +844,6 @@ static int __unmap_and_move(struct page *page, struct page
*newpage,
}
}
- if (unlikely(mobile_page(page))) {
- /*
-* A mobile page does not need any special attention from
-* physical to virtual reverse mapping procedures.
-* Skip any attempt to unmap PTEs or to remap swap cache,
-* in order to avoid burning cycles at rmap level, and perform
-* the page migration right away (proteced by page lock).
-*/
- rc = page->mapping->a_ops->migratepage(page->mapping,
- newpage, page, mode);
- goto out_unlock;
- }
-
/*
* Corner case handling:
* 1. When a new swap-cache page is read into, it is added to the LRU
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFCv3 0/5] enable migration of driver pages
From: Gioh Kim Hello, This series try to enable migration of non-LRU pages, such as driver's page. My ARM-based platform occured severe fragmentation problem after long-term (several days) test. Sometimes even order-3 page allocation failed. It has memory size 512MB ~ 1024MB. 30% ~ 40% memory is consumed for graphic processing and 20~30 memory is reserved for zram. I found that many pages of GPU driver and zram are non-movable pages. So I reported Minchan Kim, the maintainer of zram, and he made the internal compaction logic of zram. And I made the internal compaction of GPU driver. They reduced some fragmentation but they are not enough effective. They are activated by its own interface, /sys, so they are not cooperative with kernel compaction. If there is too much fragmentation and kernel starts to compaction, zram and GPU driver cannot work with the kernel compaction. This patch set combines 5 patches. 1. patch 1/5: get inode from anon_inodes This patch adds new interface to create inode from anon_inodes. 2. patch 2/5: framework to isolate/migrate/putback page Add isolatepage, putbackpage into address_space_operations and wrapper function to call them 3. patch 3/5: apply the framework into balloon driver The balloon driver is applied into the framework. It gets a inode from anon_inodes and register operations in the inode. Any other drivers can register operations via inode like this to migrate it's pages. 4. patch 4/5: compaction/migration call the generic interfaces Compaction and migration pages call the generic interfaces of the framework, instead of calling balloon migration directly. 5. patch 5/5: remove direct calling of migration of driver pages Non-lru pages are migrated with lru pages by move_to_new_page(). This patch set is tested: - turn on Ubuntu 14.04 with 1G memory on qemu. - do kernel building - after several seconds check more than 512MB is used with free command - command "balloon 512" in qemu monitor - check hundreds MB of pages are migrated My thanks to Konstantin Khlebnikov for his reviews of the v2 patch set. Most of the changes were based on his feedback. Changes since v2: - change the name of page type from migratable page into mobile page - get and lock page to isolate page - add wrapper interfaces for page->mapping->a_ops->isolate/putback - leave balloon pages marked as balloon This patch-set is based on v4.1 Gioh Kim (5): fs/anon_inodes: new interface to create new inode mm/compaction: enable mobile-page migration mm/balloon: apply mobile page migratable into balloon mm/compaction: call generic migration callbacks mm: remove direct calling of migration drivers/virtio/virtio_balloon.c| 3 ++ fs/anon_inodes.c | 6 +++ fs/proc/page.c | 3 ++ include/linux/anon_inodes.h| 1 + include/linux/balloon_compaction.h | 15 +-- include/linux/compaction.h | 76 ++ include/linux/fs.h | 2 + include/linux/page-flags.h | 19 + include/uapi/linux/kernel-page-flags.h | 1 + mm/balloon_compaction.c| 71 ++- mm/compaction.c| 8 ++-- mm/migrate.c | 24 +++ 12 files changed, 154 insertions(+), 75 deletions(-) -- 2.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFCv3 3/5] mm/balloon: apply mobile page migratable into balloon
From: Gioh Kim
Apply mobile page migration into balloon driver.
The balloong driver has an anonymous inode that manages
address_space_operation for page migration.
Signed-off-by: Gioh Kim
---
drivers/virtio/virtio_balloon.c| 3 ++
include/linux/balloon_compaction.h | 15 +++--
mm/balloon_compaction.c| 65 +-
mm/compaction.c| 2 +-
mm/migrate.c | 2 +-
5 files changed, 39 insertions(+), 48 deletions(-)
diff --git a/drivers/virtio/virtio_balloon.c b/drivers/virtio/virtio_balloon.c
index 82e80e0..ef5b9b5 100644
--- a/drivers/virtio/virtio_balloon.c
+++ b/drivers/virtio/virtio_balloon.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
/*
* Balloon device works in 4K page units. So each page is pointed to by
@@ -505,6 +506,8 @@ static int virtballoon_probe(struct virtio_device *vdev)
balloon_devinfo_init(&vb->vb_dev_info);
#ifdef CONFIG_BALLOON_COMPACTION
vb->vb_dev_info.migratepage = virtballoon_migratepage;
+ vb->vb_dev_info.inode = anon_inode_new();
+ vb->vb_dev_info.inode->i_mapping->a_ops = &balloon_aops;
#endif
err = init_vqs(vb);
diff --git a/include/linux/balloon_compaction.h
b/include/linux/balloon_compaction.h
index 9b0a15d..a9e0bde 100644
--- a/include/linux/balloon_compaction.h
+++ b/include/linux/balloon_compaction.h
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
/*
* Balloon device information descriptor.
@@ -62,6 +63,7 @@ struct balloon_dev_info {
struct list_head pages; /* Pages enqueued & handled to Host */
int (*migratepage)(struct balloon_dev_info *, struct page *newpage,
struct page *page, enum migrate_mode mode);
+ struct inode *inode;
};
extern struct page *balloon_page_enqueue(struct balloon_dev_info *b_dev_info);
@@ -73,12 +75,16 @@ static inline void balloon_devinfo_init(struct
balloon_dev_info *balloon)
spin_lock_init(&balloon->pages_lock);
INIT_LIST_HEAD(&balloon->pages);
balloon->migratepage = NULL;
+ balloon->inode = NULL;
}
#ifdef CONFIG_BALLOON_COMPACTION
-extern bool balloon_page_isolate(struct page *page);
+extern const struct address_space_operations balloon_aops;
+extern bool balloon_page_isolate(struct page *page,
+isolate_mode_t mode);
extern void balloon_page_putback(struct page *page);
-extern int balloon_page_migrate(struct page *newpage,
+extern int balloon_page_migrate(struct address_space *mapping,
+ struct page *newpage,
struct page *page, enum migrate_mode mode);
/*
@@ -124,6 +130,7 @@ static inline void balloon_page_insert(struct
balloon_dev_info *balloon,
struct page *page)
{
__SetPageBalloon(page);
+ page->mapping = balloon->inode->i_mapping;
SetPagePrivate(page);
set_page_private(page, (unsigned long)balloon);
list_add(&page->lru, &balloon->pages);
@@ -140,6 +147,7 @@ static inline void balloon_page_insert(struct
balloon_dev_info *balloon,
static inline void balloon_page_delete(struct page *page)
{
__ClearPageBalloon(page);
+ page->mapping = NULL;
set_page_private(page, 0);
if (PagePrivate(page)) {
ClearPagePrivate(page);
@@ -191,7 +199,8 @@ static inline bool isolated_balloon_page(struct page *page)
return false;
}
-static inline bool balloon_page_isolate(struct page *page)
+static inline bool balloon_page_isolate(struct page *page,
+ isolate_mode_t mode)
{
return false;
}
diff --git a/mm/balloon_compaction.c b/mm/balloon_compaction.c
index fcad832..0dd0b0d 100644
--- a/mm/balloon_compaction.c
+++ b/mm/balloon_compaction.c
@@ -131,43 +131,16 @@ static inline void __putback_balloon_page(struct page
*page)
}
/* __isolate_lru_page() counterpart for a ballooned page */
-bool balloon_page_isolate(struct page *page)
+bool balloon_page_isolate(struct page *page, isolate_mode_t mode)
{
/*
-* Avoid burning cycles with pages that are yet under __free_pages(),
-* or just got freed under us.
-*
-* In case we 'win' a race for a balloon page being freed under us and
-* raise its refcount preventing __free_pages() from doing its job
-* the put_page() at the end of this block will take care of
-* release this page, thus avoiding a nasty leakage.
+* A ballooned page, by default, has PagePrivate set.
+* Prevent concurrent compaction threads from isolating
+* an already isolated balloon page by clearing it.
*/
- if (likely(get_page_unless_zero(page))) {
- /*
-* As balloon pages are not isolated from LRU lists, concurrent
-* compaction threads can race against page migration
[RFCv3 4/5] mm: call generic migration callbacks
From: Gioh Kim
Compaction calls interfaces of mobile page migration
instead of calling balloon migration directly.
Signed-off-by: Gioh Kim
---
mm/compaction.c | 8
mm/migrate.c| 19 ++-
2 files changed, 14 insertions(+), 13 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index 81bafaf..60e4cbb 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -14,7 +14,7 @@
#include
#include
#include
-#include
+#include
#include
#include
#include "internal.h"
@@ -714,12 +714,12 @@ isolate_migratepages_block(struct compact_control *cc,
unsigned long low_pfn,
/*
* Check may be lockless but that's ok as we recheck later.
-* It's possible to migrate LRU pages and balloon pages
+* It's possible to migrate LRU pages and mobile pages
* Skip any other type of page
*/
if (!PageLRU(page)) {
- if (unlikely(balloon_page_movable(page))) {
- if (balloon_page_isolate(page, isolate_mode)) {
+ if (unlikely(mobile_page(page))) {
+ if (isolate_mobilepage(page, isolate_mode)) {
/* Successfully isolated */
goto isolate_success;
}
diff --git a/mm/migrate.c b/mm/migrate.c
index c94038e..e22be67 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -35,7 +35,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -76,7 +76,7 @@ int migrate_prep_local(void)
* from where they were once taken off for compaction/migration.
*
* This function shall be used whenever the isolated pageset has been
- * built from lru, balloon, hugetlbfs page. See isolate_migratepages_range()
+ * built from lru, mobile, hugetlbfs page. See isolate_migratepages_range()
* and isolate_huge_page().
*/
void putback_movable_pages(struct list_head *l)
@@ -92,8 +92,8 @@ void putback_movable_pages(struct list_head *l)
list_del(&page->lru);
dec_zone_page_state(page, NR_ISOLATED_ANON +
page_is_file_cache(page));
- if (unlikely(isolated_balloon_page(page)))
- balloon_page_putback(page);
+ if (unlikely(mobile_page(page)))
+ putback_mobilepage(page);
else
putback_lru_page(page);
}
@@ -844,15 +844,16 @@ static int __unmap_and_move(struct page *page, struct
page *newpage,
}
}
- if (unlikely(isolated_balloon_page(page))) {
+ if (unlikely(mobile_page(page))) {
/*
-* A ballooned page does not need any special attention from
+* A mobile page does not need any special attention from
* physical to virtual reverse mapping procedures.
* Skip any attempt to unmap PTEs or to remap swap cache,
* in order to avoid burning cycles at rmap level, and perform
* the page migration right away (proteced by page lock).
*/
- rc = balloon_page_migrate(page->mapping, newpage, page, mode);
+ rc = page->mapping->a_ops->migratepage(page->mapping,
+ newpage, page, mode);
goto out_unlock;
}
@@ -960,8 +961,8 @@ out:
if (rc != MIGRATEPAGE_SUCCESS && put_new_page) {
ClearPageSwapBacked(newpage);
put_new_page(newpage, private);
- } else if (unlikely(__is_movable_balloon_page(newpage))) {
- /* drop our reference, page already in the balloon */
+ } else if (unlikely(mobile_page(newpage))) {
+ /* drop our reference */
put_page(newpage);
} else
putback_lru_page(newpage);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] arm64: Modify the dump mem for 64 bit addresses
From: Rohit Thapliyal
On 64bit kernel, the dump_mem gives 32 bit addresses
on the stack dump. This gives unorganized information regarding
the 64bit values on the stack. Hence, modified to get a complete
64bit memory dump.
With patch:
[ 93.534801] Process insmod (pid: 1587, stack limit = 0xffc976be4058)
[ 93.541441] Stack: (0xffc976be7cf0 to 0xffc976be8000)
[ 93.547136] 7ce0: ffc976be7d00
ffc8163c
[ 93.554898] 7d00: ffc976be7d40 ffcf8a44 ffc00098ef38
ffbffc88
[ 93.562659] 7d20: ffc00098ef50 ffbffcc0 0001
ffbffc70
[ 93.570419] 7d40: ffc976be7e40 ffcf935c
2b424090
[ 93.578179] 7d60: 2b424010 007facc555f4 8000
0015
[ 93.585937] 7d80: 0116 0069 ffc00097b000
ffc976be4000
[ 93.593694] 7da0: 0064 0072 006e
003f
[ 93.601453] 7dc0: feff fff1 ffbffc002028
0124
[ 93.609211] 7de0: ffc976be7e10 0001 ff80
ffbb
[ 93.616969] 7e00: ffc976be7e60
[ 93.624726] 7e20:
[ 93.632484] 7e40: 007fcc474550 ffc841ec 2b424010
007facda0710
[ 93.640241] 7e60: ffcbe6dc ff80007d2000
0001c010
[ 93.647999] 7e80: ff80007e0ae0 ff80007e09d0 ff80007edf70
0288
[ 93.655757] 7ea0: 02e8
001c001b
[ 93.663514] 7ec0: 0009 0007 2b424090
0001c010
[ 93.671272] 7ee0: 2b424010 007faccd3a48
[ 93.679030] 7f00: 007fcc4743f8 007fcc4743f8 0069
0003
[ 93.686787] 7f20: 0101010101010101 0004 0020
03f3
[ 93.694544] 7f40: 007facb95664 007facda7030 007facc555d0
00498378
[ 93.702301] 7f60: 2b424010 007facda0710
2b424090
[ 93.710058] 7f80: 007fcc474698 00498000 007fcc474ebb
00474f58
[ 93.717815] 7fa0: 00498000
007fcc474550
[ 93.725573] 7fc0: 004104bc 007fcc474430 007facc555f4
8000
[ 93.70] 7fe0: 2b424090 0069 0950020128000244
41040804
[ 93.741084] Call trace:
The above output makes a debugger life a lot more easier.
Signed-off-by: Rohit Thapliyal
Signed-off-by: Maninder Singh
---
v1: added new function dump_mem64
v2: Removed the separate function dump_mem64 and accommodated
a field width based on which the dump shall be created of
width either 4 or 8 as suggested by Catalin.
v3: Changelog modified
arch/arm64/kernel/traps.c | 44 +---
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 1ef2940..53d57db 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -51,8 +51,9 @@ int show_unhandled_signals = 1;
/*
* Dump out the contents of some memory nicely...
*/
+
static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
-unsigned long top)
+unsigned long top, unsigned int width)
{
unsigned long first;
mm_segment_t fs;
@@ -70,18 +71,27 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
for (first = bottom & ~31; first < top; first += 32) {
unsigned long p;
- char str[sizeof(" 12345678") * 8 + 1];
+ char str[sizeof(" 1234567812345678") * 8 + 1];
memset(str, ' ', sizeof(str));
str[sizeof(str) - 1] = '\0';
- for (p = first, i = 0; i < 8 && p < top; i++, p += 4) {
+ for (p = first, i = 0; i < (width > 4 ? width-4 : width+4)
+ && p < top; i++, p += width) {
if (p >= bottom && p < top) {
- unsigned int val;
- if (__get_user(val, (unsigned int *)p) == 0)
- sprintf(str + i * 9, " %08x", val);
- else
- sprintf(str + i * 9, " ");
+ unsigned long val;
+
+ if (width == 8) {
+ if (__get_user(val, (unsigned long *)p)
== 0)
+ sprintf(str + i * 17, "
%016lx", val);
+ else
+
Re: [RESEND][PATCH v2] arm64:Modify the dump mem for 64 bit addresses
2015-07-07 12:56 GMT+09:00 Maninder Singh : > From: Rohit Thapliyal > > V1 = added new function dump_mem64 > v1->v2 > Removed the separate function dump_mem64 and accommodated > a field width based on which the dump shall be created of > width either 4 or 8 as suggested by Catalin. Hi, Please put the changelog after the commit message under separator (---) so it won't be included in commit. If you really, really want to include the changelog inside the commit then please put it at the end because it is the least important piece of information (from history point of view). > > On 64bit kernel, the dump_mem gives 32 bit addresses > on the stack dump. This gives unorganized information regarding > the 64bit values on the stack. Hence, modified to get a complete > 64bit memory dump. > > With patch: > [ 93.534801] Process insmod (pid: 1587, stack limit = 0xffc976be4058) > [ 93.541441] Stack: (0xffc976be7cf0 to 0xffc976be8000) > [ 93.547136] 7ce0: ffc976be7d00 > ffc8163c > [ 93.554898] 7d00: ffc976be7d40 ffcf8a44 ffc00098ef38 > ffbffc88 > [ 93.562659] 7d20: ffc00098ef50 ffbffcc0 0001 > ffbffc70 > [ 93.570419] 7d40: ffc976be7e40 ffcf935c > 2b424090 > [ 93.578179] 7d60: 2b424010 007facc555f4 8000 > 0015 > [ 93.585937] 7d80: 0116 0069 ffc00097b000 > ffc976be4000 > [ 93.593694] 7da0: 0064 0072 006e > 003f > [ 93.601453] 7dc0: feff fff1 ffbffc002028 > 0124 > [ 93.609211] 7de0: ffc976be7e10 0001 ff80 > ffbb > [ 93.616969] 7e00: ffc976be7e60 > > [ 93.624726] 7e20: > > [ 93.632484] 7e40: 007fcc474550 ffc841ec 2b424010 > 007facda0710 > [ 93.640241] 7e60: ffcbe6dc ff80007d2000 > 0001c010 > [ 93.647999] 7e80: ff80007e0ae0 ff80007e09d0 ff80007edf70 > 0288 > [ 93.655757] 7ea0: 02e8 > 001c001b > [ 93.663514] 7ec0: 0009 0007 2b424090 > 0001c010 > [ 93.671272] 7ee0: 2b424010 007faccd3a48 > > [ 93.679030] 7f00: 007fcc4743f8 007fcc4743f8 0069 > 0003 > [ 93.686787] 7f20: 0101010101010101 0004 0020 > 03f3 > [ 93.694544] 7f40: 007facb95664 007facda7030 007facc555d0 > 00498378 > [ 93.702301] 7f60: 2b424010 007facda0710 > 2b424090 > [ 93.710058] 7f80: 007fcc474698 00498000 007fcc474ebb > 00474f58 > [ 93.717815] 7fa0: 00498000 > 007fcc474550 > [ 93.725573] 7fc0: 004104bc 007fcc474430 007facc555f4 > 8000 > [ 93.70] 7fe0: 2b424090 0069 0950020128000244 > 41040804 > [ 93.741084] Call trace: > > The above output makes a debugger life a lot more easier. > > Signed-off-by: Rohit Thapliyal > Signed-off-by: Maninder Singh > Reviewed-by: Akhilesh kumar The first patch you sent, already contained Akhilesh kumar's reviewed-by tag. But there was no email from him with actual review. Reviews should be performed publicly and should have a public trace. The person is not even cc-ed so he cannot verify whether the tag is appropriate. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next] tcp: always send a quick ack when quickacks are enabled
I ran some tests and after setting the "ip route change quickack 1"
knob there were still many delayed ACKs sent. This occured
because when icsk_ack.quick=0 the !icsk_ack.pingpong value is
subsequently ignored as tcp_in_quickack_mode() checks both these
values. The condition for a quick ack to trigger requires
that both icsk_ack.quick != 0 and icsk_ack.pingpong=0. Currently
only icsk_ack.pingpong is controlled by the knob. But the
icsk_ack.quick value changes dynamically depending on heuristics.
The crux of the matter is that delayed acks still cannot be entirely
disabled even with the RTAX_QUICKACK per dst knob enabled. This
patch ensures that a quick ack is always sent when the RTAX_QUICKACK
per dst knob is turned on.
The "ip route change quickack 1" knob was recently added to enable
quickacks. It was modeled around the TCP_QUICKACK setsockopt() option.
This issue is that even with "ip route change quickack 1" enabled
we still see delayed ACKs under some conditions. It would be nice
to be able to completely disable delayed ACKs.
Here is an example:
# netstat -s|grep dela
3 delayed acks sent
For all routes enable the knob
# ip route change quickack 1
Generate some traffic across a slow link and we still see the delayed
acks.
# netstat -s|grep dela
106 delayed acks sent
1 delayed acks further delayed because of locked socket
The issue is that both the "ip route change quickack 1" knob and
the TCP_QUICKACK option set the icsk_ack.pingpong variable to 0.
However at the business end in the __tcp_ack_snd_check() routine,
tcp_in_quickack_mode() checks that both icsk_ack.quick != 0
and icsk_ack.pingpong=0 in order to trigger a quickack. As
icsk_ack.quick is determined by heuristics it can be 0. When
that occurs the icsk_ack.pingpong value is ignored and a delayed
ACK is sent regardless.
This patch moves the RTAX_QUICKACK per dst check into the
__tcp_ack_snd_check() routine which ensures that a quickack is
always sent when the quickack knob is enabled for that dst.
Signed-off-by: Jon Maxwell
---
net/ipv4/tcp_input.c | 8
net/ipv4/tcp_output.c | 6 ++
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 684f095..1af7d74 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3948,7 +3948,6 @@ void tcp_reset(struct sock *sk)
static void tcp_fin(struct sock *sk)
{
struct tcp_sock *tp = tcp_sk(sk);
- const struct dst_entry *dst;
inet_csk_schedule_ack(sk);
@@ -3960,9 +3959,7 @@ static void tcp_fin(struct sock *sk)
case TCP_ESTABLISHED:
/* Move to CLOSE_WAIT */
tcp_set_state(sk, TCP_CLOSE_WAIT);
- dst = __sk_dst_get(sk);
- if (!dst || !dst_metric(dst, RTAX_QUICKACK))
- inet_csk(sk)->icsk_ack.pingpong = 1;
+ inet_csk(sk)->icsk_ack.pingpong = 1;
break;
case TCP_CLOSE_WAIT:
@@ -4887,6 +4884,7 @@ static inline void tcp_data_snd_check(struct sock *sk)
static void __tcp_ack_snd_check(struct sock *sk, int ofo_possible)
{
struct tcp_sock *tp = tcp_sk(sk);
+ const struct dst_entry *dst = __sk_dst_get(sk);
/* More than one full frame received... */
if (((tp->rcv_nxt - tp->rcv_wup) > inet_csk(sk)->icsk_ack.rcv_mss &&
@@ -4896,6 +4894,8 @@ static void __tcp_ack_snd_check(struct sock *sk, int
ofo_possible)
__tcp_select_window(sk) >= tp->rcv_wnd) ||
/* We ACK each frame or... */
tcp_in_quickack_mode(sk) ||
+ /* quickack on dst */
+ (dst && dst_metric(dst, RTAX_QUICKACK)) ||
/* We have out of order data. */
(ofo_possible && skb_peek(&tp->out_of_order_queue))) {
/* Then ack it now */
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index b1c218d..7105784 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -163,7 +163,6 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
{
struct inet_connection_sock *icsk = inet_csk(sk);
const u32 now = tcp_time_stamp;
- const struct dst_entry *dst = __sk_dst_get(sk);
if (sysctl_tcp_slow_start_after_idle &&
(!tp->packets_out && (s32)(now - tp->lsndtime) > icsk->icsk_rto))
@@ -174,9 +173,8 @@ static void tcp_event_data_sent(struct tcp_sock *tp,
/* If it is a reply for ato after last received
* packet, enter pingpong mode.
*/
- if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato &&
- (!dst || !dst_metric(dst, RTAX_QUICKACK)))
- icsk->icsk_ack.pingpong = 1;
+ if ((u32)(now - icsk->icsk_ack.lrcvtime) < icsk->icsk_ack.ato)
+ icsk->icsk_ack.pingpong = 1;
}
/* Account for an ACK we sent. */
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kern
Re: [PATCH] dmaengine: imx-sdma: Add device to device support
On Tue, Jun 23, 2015 at 04:42:54PM +0800, Shengjiu Wang wrote:
> +static void sdma_set_watermarklevel_for_p2p(struct sdma_channel *sdmac)
> +{
> + struct sdma_engine *sdma = sdmac->sdma;
> +
> + int lwml = sdmac->watermark_level & 0xff;
> + int hwml = (sdmac->watermark_level >> 16) & 0xff;
> +
> + if (sdmac->event_id0 > 31) {
> + sdmac->event_mask[0] |= 0;
> + __set_bit(28, &sdmac->watermark_level);
why not use set_bit(), you are modifying driver memory
> + sdmac->event_mask[1] |=
> + BIT(sdmac->event_id0 % 32);
and then why not use set_bit() here too?
> + } else {
> + sdmac->event_mask[0] |= 0;
> + sdmac->event_mask[1] |=
> + BIT(sdmac->event_id0 % 32);
> + }
> + if (sdmac->event_id1 > 31) {
> + sdmac->event_mask[1] |= 0;
> + __set_bit(29, &sdmac->watermark_level);
> + sdmac->event_mask[0] |=
> + BIT(sdmac->event_id1 % 32);
> + } else {
> + sdmac->event_mask[1] |= 0;
> + sdmac->event_mask[0] |=
> + BIT(sdmac->event_id1 % 32);
> + }
pattern for eventidX is repeated, also in that we can make generic macro to
handle and reduce code size
> +
> + /*
> + * If LWML(src_maxburst) > HWML(dst_maxburst), we need
> + * swap LWML and HWML of INFO(A.3.2.5.1), also need swap
> + * r0(event_mask[1]) and r1(event_mask[0]).
> + */
> + if (lwml > hwml) {
> + sdmac->watermark_level &= ~0xff00ff;
Magic number?
> static int sdma_config_channel(struct dma_chan *chan)
> {
> struct sdma_channel *sdmac = to_sdma_chan(chan);
> @@ -869,6 +945,12 @@ static int sdma_config_channel(struct dma_chan *chan)
> sdma_event_enable(sdmac, sdmac->event_id0);
> }
>
> + if (sdmac->event_id1) {
> + if (sdmac->event_id1 >= sdmac->sdma->drvdata->num_events)
> + return -EINVAL;
> + sdma_event_enable(sdmac, sdmac->event_id1);
> + }
> +
> switch (sdmac->peripheral_type) {
> case IMX_DMATYPE_DSP:
> sdma_config_ownership(sdmac, false, true, true);
> @@ -887,19 +969,21 @@ static int sdma_config_channel(struct dma_chan *chan)
> (sdmac->peripheral_type != IMX_DMATYPE_DSP)) {
> /* Handle multiple event channels differently */
> if (sdmac->event_id1) {
> - sdmac->event_mask[1] = BIT(sdmac->event_id1 % 32);
> - if (sdmac->event_id1 > 31)
> - __set_bit(31, &sdmac->watermark_level);
> - sdmac->event_mask[0] = BIT(sdmac->event_id0 % 32);
> - if (sdmac->event_id0 > 31)
> - __set_bit(30, &sdmac->watermark_level);
> - } else {
> + if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
> + sdmac->peripheral_type == IMX_DMATYPE_ASRC)
> + sdma_set_watermarklevel_for_p2p(sdmac);
> + } else
> __set_bit(sdmac->event_id0, sdmac->event_mask);
> - }
> +
> /* Watermark Level */
> sdmac->watermark_level |= sdmac->watermark_level;
> /* Address */
> - sdmac->shp_addr = sdmac->per_address;
> + if (sdmac->direction == DMA_DEV_TO_DEV) {
Okay the direction is depreciated, so can you store both source and
destination and use them based on direction in prepare()
Also I see driver is not doing this, so while at it, can you fix this is
current code as well
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
spoluprace
Mam prospesne resení pro nas oba. byste mi mel odpovedet na nize pro vysvetlení na e-mailovou adresu. E-mail: jgg.c...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] base: power: wakeirq: don't leak dev->power.wakeirq
Hi On Mon, Jul 6, 2015 at 8:09 PM, Felipe Balbi wrote: > On Mon, Jul 06, 2015 at 08:06:17PM +0200, Michael Trimarchi wrote: >> Hi >> >> On Jul 6, 2015 8:01 PM, "Felipe Balbi" wrote: >> > >> > on a first call to dev_pm_attach_wake_irq(), if it >> > fails, it will leave dev->power.wakeirq set to a >> > dangling pointer. Instead, let's clear it to make >> > sure a subsequent call to dev_pm_attach_wake_irq() >> > has chance to succeed. >> > >> > Cc: Tony Lindgren >> > Signed-off-by: Felipe Balbi >> > --- >> > drivers/base/power/wakeirq.c | 9 - >> > 1 file changed, 8 insertions(+), 1 deletion(-) >> > >> > diff --git a/drivers/base/power/wakeirq.c b/drivers/base/power/wakeirq.c >> > index 7470004ca810..394d250a1ad8 100644 >> > --- a/drivers/base/power/wakeirq.c >> > +++ b/drivers/base/power/wakeirq.c >> > @@ -50,9 +50,16 @@ static int dev_pm_attach_wake_irq(struct device *dev, >> int irq, >> > >> > err = device_wakeup_attach_irq(dev, wirq); >> > if (err) >> > - return err; >> > + goto err_cleanup; >> > >> > return 0; >> > + >> > +err_cleanup: >> > + spin_lock_irqsave(&dev->power.lock, flags); >> > + dev->power.wakeirq = NULL; >> > + spin_unlock_irqrestore(&dev->power.lock, flags); >> > + >> >> Why here and not in the fuction that return the error? > > because the field was set here, why would I clear it elsewhere ? > Clear now and even more from the other patch proposal. Michael > -- > balbi -- | Michael Nazzareno Trimarchi Amarula Solutions BV | | COO - Founder Cruquiuskade 47 | | +31(0)851119172 Amsterdam 1018 AM NL | | [`as] http://www.amarulasolutions.com | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
MM: Query about different memory types(mem_types)__mmu.c
Hi All,
I have been exploring ARM reference manual about ARM weak memory model
and mmu page table setting from some time.
I think i understand different memory types, mmu settings for
page/section, TEX, AP, B, C, S bits well.
My target is to to dig further and fully understand setting of all
parameters for different memory types in ARM
[File mmu.c: "static struct mem_type mem_types"].
But i am not able to find any good source to refer for fully
understanding all below parameters.
Could you please help me to understand mappings for below mem types.
If you can point me to some references which can help me understand
more.
Thank you in advance for your help.
[MT_DEVICE] = { /* Strongly ordered / ARMv6 shared device */
.prot_pte = PROT_PTE_DEVICE | L_PTE_MT_DEV_SHARED |
L_PTE_SHARED,
.prot_pte_s2= s2_policy(PROT_PTE_S2_DEVICE) |
s2_policy(L_PTE_S2_MT_DEV_SHARED) |
L_PTE_SHARED,
.prot_l1= PMD_TYPE_TABLE,
.prot_sect = PROT_SECT_DEVICE | PMD_SECT_S,
.domain = DOMAIN_IO,
},
[MT_MEMORY_RW] = {
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
L_PTE_XN,
.prot_l1 = PMD_TYPE_TABLE,
.prot_sect = PMD_TYPE_SECT | PMD_SECT_AP_WRITE,
.domain= DOMAIN_KERNEL,
},
[MT_MEMORY_DMA_READY] = {
.prot_pte = L_PTE_PRESENT | L_PTE_YOUNG | L_PTE_DIRTY |
L_PTE_XN,
.prot_l1 = PMD_TYPE_TABLE,
.domain= DOMAIN_KERNEL,
},
Regards,
Sumit Gupta
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 6/6] clk: ti: make use of of_clk_parent_fill helper function
From: Dinh Nguyen
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen
Cc: Tero Kristo
---
drivers/clk/ti/apll.c |4 +---
drivers/clk/ti/composite.c |4 +---
drivers/clk/ti/dpll.c |4 +---
drivers/clk/ti/fapll.c |3 +--
drivers/clk/ti/mux.c |4 +---
5 files changed, 5 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/ti/apll.c b/drivers/clk/ti/apll.c
index 49baf38..523880e 100644
--- a/drivers/clk/ti/apll.c
+++ b/drivers/clk/ti/apll.c
@@ -170,7 +170,6 @@ static void __init of_dra7_apll_setup(struct device_node
*node)
struct clk_hw_omap *clk_hw = NULL;
struct clk_init_data *init = NULL;
const char **parent_names = NULL;
- int i;
ad = kzalloc(sizeof(*ad), GFP_KERNEL);
clk_hw = kzalloc(sizeof(*clk_hw), GFP_KERNEL);
@@ -195,8 +194,7 @@ static void __init of_dra7_apll_setup(struct device_node
*node)
if (!parent_names)
goto cleanup;
- for (i = 0; i < init->num_parents; i++)
- parent_names[i] = of_clk_get_parent_name(node, i);
+ of_clk_parent_fill(node, parent_names, init->num_parents);
init->parent_names = parent_names;
diff --git a/drivers/clk/ti/composite.c b/drivers/clk/ti/composite.c
index 96f83ce..dbef218 100644
--- a/drivers/clk/ti/composite.c
+++ b/drivers/clk/ti/composite.c
@@ -276,7 +276,6 @@ int __init ti_clk_add_component(struct device_node *node,
struct clk_hw *hw,
int num_parents;
const char **parent_names;
struct component_clk *clk;
- int i;
num_parents = of_clk_get_parent_count(node);
@@ -289,8 +288,7 @@ int __init ti_clk_add_component(struct device_node *node,
struct clk_hw *hw,
if (!parent_names)
return -ENOMEM;
- for (i = 0; i < num_parents; i++)
- parent_names[i] = of_clk_get_parent_name(node, i);
+ of_clk_parent_fill(node, parent_names, num_parents);
clk = kzalloc(sizeof(*clk), GFP_KERNEL);
if (!clk) {
diff --git a/drivers/clk/ti/dpll.c b/drivers/clk/ti/dpll.c
index 2aacf7a..49acdf2 100644
--- a/drivers/clk/ti/dpll.c
+++ b/drivers/clk/ti/dpll.c
@@ -341,7 +341,6 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
struct clk_init_data *init = NULL;
const char **parent_names = NULL;
struct dpll_data *dd = NULL;
- int i;
u8 dpll_mode = 0;
dd = kzalloc(sizeof(*dd), GFP_KERNEL);
@@ -370,8 +369,7 @@ static void __init of_ti_dpll_setup(struct device_node
*node,
if (!parent_names)
goto cleanup;
- for (i = 0; i < init->num_parents; i++)
- parent_names[i] = of_clk_get_parent_name(node, i);
+ of_clk_parent_fill(node, parent_names, init->num_parents);
init->parent_names = parent_names;
diff --git a/drivers/clk/ti/fapll.c b/drivers/clk/ti/fapll.c
index 730aa62..b1c741b 100644
--- a/drivers/clk/ti/fapll.c
+++ b/drivers/clk/ti/fapll.c
@@ -558,8 +558,7 @@ static void __init ti_fapll_setup(struct device_node *node)
goto free;
}
- parent_name[0] = of_clk_get_parent_name(node, 0);
- parent_name[1] = of_clk_get_parent_name(node, 1);
+ of_clk_parent_fill(node, parent_name, 2);
init->parent_names = parent_name;
fd->clk_ref = of_clk_get(node, 0);
diff --git a/drivers/clk/ti/mux.c b/drivers/clk/ti/mux.c
index 5cdeed5..99fe27e 100644
--- a/drivers/clk/ti/mux.c
+++ b/drivers/clk/ti/mux.c
@@ -190,7 +190,6 @@ static void of_mux_clk_setup(struct device_node *node)
void __iomem *reg;
int num_parents;
const char **parent_names;
- int i;
u8 clk_mux_flags = 0;
u32 mask = 0;
u32 shift = 0;
@@ -205,8 +204,7 @@ static void of_mux_clk_setup(struct device_node *node)
if (!parent_names)
goto cleanup;
- for (i = 0; i < num_parents; i++)
- parent_names[i] = of_clk_get_parent_name(node, i);
+ of_clk_parent_fill(node, parent_names, num_parents);
reg = ti_clk_get_reg_addr(node, 0);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 0/6] clk: make use of of_clk_parent_fill helper function
From: Dinh Nguyen Hello, This is v2 of the patchset that makes use of of_clk_parent_fill helper function on various platforms. Thanks, Dinh Nguyen (6): clk: at91: make use of of_clk_parent_fill helper function clk: qoriq: make use of of_clk_parent_fill helper function clk: keystone: make use of of_clk_parent_fill helper function clk: st: make use of of_clk_parent_fill helper function clk: sunxi: make use of of_clk_parent_fill helper function clk: ti: make use of of_clk_parent_fill helper function drivers/clk/at91/clk-main.c |7 +-- drivers/clk/at91/clk-master.c |7 +-- drivers/clk/at91/clk-programmable.c |7 +-- drivers/clk/at91/clk-slow.c | 14 ++ drivers/clk/at91/clk-smd.c |7 +-- drivers/clk/at91/clk-usb.c |7 +-- drivers/clk/clk-qoriq.c |5 ++--- drivers/clk/keystone/pll.c |3 +-- drivers/clk/st/clk-flexgen.c|6 ++ drivers/clk/st/clkgen-mux.c |7 ++- drivers/clk/sunxi/clk-a20-gmac.c|4 +--- drivers/clk/sunxi/clk-factors.c |4 +--- drivers/clk/sunxi/clk-sun6i-ar100.c |3 +-- drivers/clk/sunxi/clk-sunxi.c | 10 ++ drivers/clk/ti/apll.c |4 +--- drivers/clk/ti/composite.c |4 +--- drivers/clk/ti/dpll.c |4 +--- drivers/clk/ti/fapll.c |3 +-- drivers/clk/ti/mux.c|4 +--- 19 files changed, 24 insertions(+), 86 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 1/6] clk: at91: make use of of_clk_parent_fill helper function
From: Dinh Nguyen
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen
Cc: Boris Brezillon
---
drivers/clk/at91/clk-main.c |7 +--
drivers/clk/at91/clk-master.c |7 +--
drivers/clk/at91/clk-programmable.c |7 +--
drivers/clk/at91/clk-slow.c | 14 ++
drivers/clk/at91/clk-smd.c |7 +--
drivers/clk/at91/clk-usb.c |7 +--
6 files changed, 7 insertions(+), 42 deletions(-)
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
index c240045..13f481b 100644
--- a/drivers/clk/at91/clk-main.c
+++ b/drivers/clk/at91/clk-main.c
@@ -612,17 +612,12 @@ void __init of_at91sam9x5_clk_main_setup(struct
device_node *np,
int num_parents;
unsigned int irq;
const char *name = np->name;
- int i;
num_parents = of_clk_get_parent_count(np);
if (num_parents <= 0 || num_parents > 2)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
of_property_read_string(np, "clock-output-names", &name);
diff --git a/drivers/clk/at91/clk-master.c b/drivers/clk/at91/clk-master.c
index f98eafe..38f646d 100644
--- a/drivers/clk/at91/clk-master.c
+++ b/drivers/clk/at91/clk-master.c
@@ -218,7 +218,6 @@ of_at91_clk_master_setup(struct device_node *np, struct
at91_pmc *pmc,
{
struct clk *clk;
int num_parents;
- int i;
unsigned int irq;
const char *parent_names[MASTER_SOURCE_MAX];
const char *name = np->name;
@@ -228,11 +227,7 @@ of_at91_clk_master_setup(struct device_node *np, struct
at91_pmc *pmc,
if (num_parents <= 0 || num_parents > MASTER_SOURCE_MAX)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
of_property_read_string(np, "clock-output-names", &name);
diff --git a/drivers/clk/at91/clk-programmable.c
b/drivers/clk/at91/clk-programmable.c
index 8c86c0f..21492ac 100644
--- a/drivers/clk/at91/clk-programmable.c
+++ b/drivers/clk/at91/clk-programmable.c
@@ -230,7 +230,6 @@ of_at91_clk_prog_setup(struct device_node *np, struct
at91_pmc *pmc,
{
int num;
u32 id;
- int i;
struct clk *clk;
int num_parents;
const char *parent_names[PROG_SOURCE_MAX];
@@ -241,11 +240,7 @@ of_at91_clk_prog_setup(struct device_node *np, struct
at91_pmc *pmc,
if (num_parents <= 0 || num_parents > PROG_SOURCE_MAX)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
num = of_get_child_count(np);
if (!num || num > (PROG_ID_MAX + 1))
diff --git a/drivers/clk/at91/clk-slow.c b/drivers/clk/at91/clk-slow.c
index 98a84a8..84c19d7 100644
--- a/drivers/clk/at91/clk-slow.c
+++ b/drivers/clk/at91/clk-slow.c
@@ -371,17 +371,12 @@ void __init of_at91sam9x5_clk_slow_setup(struct
device_node *np,
const char *parent_names[2];
int num_parents;
const char *name = np->name;
- int i;
num_parents = of_clk_get_parent_count(np);
if (num_parents <= 0 || num_parents > 2)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
of_property_read_string(np, "clock-output-names", &name);
@@ -449,17 +444,12 @@ void __init of_at91sam9260_clk_slow_setup(struct
device_node *np,
const char *parent_names[2];
int num_parents;
const char *name = np->name;
- int i;
num_parents = of_clk_get_parent_count(np);
if (num_parents != 2)
return;
- for (i = 0; i < num_parents; ++i) {
- parent_names[i] = of_clk_get_parent_name(np, i);
- if (!parent_names[i])
- return;
- }
+ of_clk_parent_fill(np, parent_names, num_parents);
of_property_read_string(np, "clock-output-names", &name);
diff --git a/drivers/clk/at91/clk-smd.c b/drivers/clk/at91/clk-smd.c
index 3817ea8..a7f8501 100644
--- a/drivers/clk/at91/clk-smd.c
+++ b/drivers/clk/at91/clk-smd.c
@@ -145,7 +145,6 @@ void __init of_at91sam9x5_clk_smd_setup(struct device_node
*np,
struct at91_pmc *pmc)
{
s
[PATCHv2 4/6] clk: st: make use of of_clk_parent_fill helper function
From: Dinh Nguyen
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen
Tested-by Gabriel Fernandez
Cc: Peter Griffin
---
drivers/clk/st/clk-flexgen.c |6 ++
drivers/clk/st/clkgen-mux.c |7 ++-
2 files changed, 4 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/st/clk-flexgen.c b/drivers/clk/st/clk-flexgen.c
index 657ca14..ed0696c 100644
--- a/drivers/clk/st/clk-flexgen.c
+++ b/drivers/clk/st/clk-flexgen.c
@@ -243,7 +243,7 @@ static const char ** __init flexgen_get_parents(struct
device_node *np,
int *num_parents)
{
const char **parents;
- int nparents, i;
+ int nparents;
nparents = of_clk_get_parent_count(np);
if (WARN_ON(nparents <= 0))
@@ -253,10 +253,8 @@ static const char ** __init flexgen_get_parents(struct
device_node *np,
if (!parents)
return NULL;
- for (i = 0; i < nparents; i++)
- parents[i] = of_clk_get_parent_name(np, i);
+ *num_parents = of_clk_parent_fill(np, parents, nparents);
- *num_parents = nparents;
return parents;
}
diff --git a/drivers/clk/st/clkgen-mux.c b/drivers/clk/st/clkgen-mux.c
index 4fbe6e0..b83654a 100644
--- a/drivers/clk/st/clkgen-mux.c
+++ b/drivers/clk/st/clkgen-mux.c
@@ -24,7 +24,7 @@ static const char ** __init clkgen_mux_get_parents(struct
device_node *np,
int *num_parents)
{
const char **parents;
- int nparents, i;
+ int nparents;
nparents = of_clk_get_parent_count(np);
if (WARN_ON(nparents <= 0))
@@ -34,10 +34,7 @@ static const char ** __init clkgen_mux_get_parents(struct
device_node *np,
if (!parents)
return ERR_PTR(-ENOMEM);
- for (i = 0; i < nparents; i++)
- parents[i] = of_clk_get_parent_name(np, i);
-
- *num_parents = nparents;
+ *num_parents = of_clk_parent_fill(np, parents, nparents);
return parents;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 5/6] clk: sunxi: make use of of_clk_parent_fill helper function
From: Dinh Nguyen Use of_clk_parent_fill to fill in the parent clock names' array. Signed-off-by: Dinh Nguyen Cc: Maxime Ripard Cc: "Emilio López" --- v2: Add if (of_clk_parent_fill(node, parents, 2) != 2) to clk-a20-gmac.c --- drivers/clk/sunxi/clk-a20-gmac.c|4 +--- drivers/clk/sunxi/clk-factors.c |4 +--- drivers/clk/sunxi/clk-sun6i-ar100.c |3 +-- drivers/clk/sunxi/clk-sunxi.c | 10 ++ 4 files changed, 5 insertions(+), 16 deletions(-) diff --git a/drivers/clk/sunxi/clk-a20-gmac.c b/drivers/clk/sunxi/clk-a20-gmac.c index 0dcf4f2..1611b03 100644 --- a/drivers/clk/sunxi/clk-a20-gmac.c +++ b/drivers/clk/sunxi/clk-a20-gmac.c @@ -80,9 +80,7 @@ static void __init sun7i_a20_gmac_clk_setup(struct device_node *node) goto free_mux; /* gmac clock requires exactly 2 parents */ - parents[0] = of_clk_get_parent_name(node, 0); - parents[1] = of_clk_get_parent_name(node, 1); - if (!parents[0] || !parents[1]) + if (of_clk_parent_fill(node, parents, 2) != 2) goto free_gate; reg = of_iomap(node, 0); diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c index 8c20190..2589457 100644 --- a/drivers/clk/sunxi/clk-factors.c +++ b/drivers/clk/sunxi/clk-factors.c @@ -174,9 +174,7 @@ struct clk *sunxi_factors_register(struct device_node *node, int i = 0; /* if we have a mux, we will have >1 parents */ - while (i < FACTORS_MAX_PARENTS && - (parents[i] = of_clk_get_parent_name(node, i)) != NULL) - i++; + i = of_clk_parent_fill(node, parents, FACTORS_MAX_PARENTS); /* * some factor clocks, such as pll5 and pll6, may have multiple diff --git a/drivers/clk/sunxi/clk-sun6i-ar100.c b/drivers/clk/sunxi/clk-sun6i-ar100.c index 63cf149..6f229ff 100644 --- a/drivers/clk/sunxi/clk-sun6i-ar100.c +++ b/drivers/clk/sunxi/clk-sun6i-ar100.c @@ -195,8 +195,7 @@ static int sun6i_a31_ar100_clk_probe(struct platform_device *pdev) if (nparents > SUN6I_AR100_MAX_PARENTS) nparents = SUN6I_AR100_MAX_PARENTS; - for (i = 0; i < nparents; i++) - parents[i] = of_clk_get_parent_name(np, i); + of_clk_parent_fill(np, parents, nparents); of_property_read_string(np, "clock-output-names", &clk_name); diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c index 9a82f17..eed66f8 100644 --- a/drivers/clk/sunxi/clk-sunxi.c +++ b/drivers/clk/sunxi/clk-sunxi.c @@ -202,10 +202,7 @@ static void __init sun6i_ahb1_clk_setup(struct device_node *node) return; /* we have a mux, we will have >1 parents */ - while (i < SUN6I_AHB1_MAX_PARENTS && - (parents[i] = of_clk_get_parent_name(node, i)) != NULL) - i++; - + of_clk_parent_fill(node, parents, SUN6I_AHB1_MAX_PARENTS); of_property_read_string(node, "clock-output-names", &clk_name); ahb1 = kzalloc(sizeof(struct sun6i_ahb1_clk), GFP_KERNEL); @@ -790,10 +787,7 @@ static void __init sunxi_mux_clk_setup(struct device_node *node, reg = of_iomap(node, 0); - while (i < SUNXI_MAX_PARENTS && - (parents[i] = of_clk_get_parent_name(node, i)) != NULL) - i++; - + of_clk_parent_fill(node, parents, SUNXI_MAX_PARENTS); of_property_read_string(node, "clock-output-names", &clk_name); clk = clk_register_mux(NULL, clk_name, parents, i, -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 3/6] clk: keystone: make use of of_clk_parent_fill helper function
From: Dinh Nguyen
Use of_clk_parent_fill to fill in the parent clock names' array.
Signed-off-by: Dinh Nguyen
Acked-by: Santosh Shilimkar
---
drivers/clk/keystone/pll.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/clk/keystone/pll.c b/drivers/clk/keystone/pll.c
index 4a375ea..d6ef063 100644
--- a/drivers/clk/keystone/pll.c
+++ b/drivers/clk/keystone/pll.c
@@ -309,8 +309,7 @@ static void __init of_pll_mux_clk_init(struct device_node
*node)
return;
}
- parents[0] = of_clk_get_parent_name(node, 0);
- parents[1] = of_clk_get_parent_name(node, 1);
+ of_clk_parent_fill(node, parents, 2);
if (!parents[0] || !parents[1]) {
pr_err("%s: missing parent clocks\n", __func__);
return;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 2/6] clk: qoriq: make use of of_clk_parent_fill helper function
From: Dinh Nguyen Use of_clk_parent_fill to fill in the parent clock names' array. Signed-off-by: Dinh Nguyen --- drivers/clk/clk-qoriq.c |5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/clk/clk-qoriq.c b/drivers/clk/clk-qoriq.c index cda90a9..d3f4570 100644 --- a/drivers/clk/clk-qoriq.c +++ b/drivers/clk/clk-qoriq.c @@ -70,7 +70,7 @@ static void __init core_mux_init(struct device_node *np) struct clk_init_data init; struct cmux_clk *cmux_clk; struct device_node *node; - int rc, count, i; + int rc, count; u32 offset; const char *clk_name; const char **parent_names; @@ -92,8 +92,7 @@ static void __init core_mux_init(struct device_node *np) if (!parent_names) return; - for (i = 0; i < count; i++) - parent_names[i] = of_clk_get_parent_name(np, i); + of_clk_parent_fill(np, parent_names, count); cmux_clk = kzalloc(sizeof(*cmux_clk), GFP_KERNEL); if (!cmux_clk) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Warnings : Fixed 80 character length warning in rtw_ap.c
On Mon, Jul 06, 2015 at 09:53:26PM -0400, Sreenath Madasu wrote: > When the checkpatch.pl script was run, it showed lines with length > more than 80 characters in rtw_ap.c file. Fixed line number 382 by > breaking it up into two lines within 80 characters. > > Signed-off-by: Sreenath Madasu > --- > drivers/staging/rtl8188eu/core/rtw_ap.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) Any reason why you didn't cc: the maintainer of the staging subsystem for this? Please use scripts/get_maintainer to determine who to send stuff to. Also, can you fix up the Subject line to show the subsystem and driver you are modifying? Can you fix that up and resend? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: Fix detection of GCC -mpreferred-stack-boundary support
On Mon, 2015-07-06 at 10:59 -0700, Andy Lutomirski wrote: > On Mon, Jul 6, 2015 at 10:40 AM, Ingo Molnar wrote: > > > > * Andy Lutomirski wrote: > > > >> > My reasoning: on modern uarchs there's no penalty for 32-bit > >> > misalignment of > >> > 64-bit variables, only if they cross 64-byte cache lines, which should > >> > be rare > >> > with a chance of 1:16. This small penalty (of at most +1 cycle in some > >> > circumstances IIRC) should be more than counterbalanced by the > >> > compression of > >> > the stack by 5% on average. > >> > >> I'll counter with: what's the benefit? There are no operations that will > >> naturally change RSP by anything that isn't a multiple of 8 (there's no > >> pushl in > >> 64-bit mode, or at least not on AMD chips -- the Intel manual is a bit > >> vague on > >> this point), so we'll end up with RSP being a multiple of 8 regardless. > >> Even if > >> we somehow shaved 4 bytes off in asm, that still wouldn't buy us anything, > >> as a > >> dangling 4 bytes at the bottom of the stack isn't useful for anything. > > > > Yeah, so it might be utilized in frame-pointer less builds (which we might > > be able > > to utilize in the future if sane Dwarf code comes around), which does not > > use > > push/pop to manage the stack but often has patterns like: > > > > 8102aa90 : > > 8102aa90: 48 83 ec 18 sub$0x18,%rsp > > > > and uses MOVs to manage the stack. Those kinds of stack frames could be > > 4-byte > > granular as well. > > > > But yeah ... it's pretty marginal. > > To get even that, we'd need an additional ABI-changing GCC flag to > change GCC's idea of the alignment of long from 8 to 4. (I just > checked: g++ thinks that alignof(long) == 8. I was too lazy to look > up how to ask the equivalent question in C.) I just want to point out that long itself is 8 bytes on 64-bit x86, but only 4 bytes on 32-bit x86. Perhaps we should keep in mind sizeof(long) and not just alignof(long)? My opinion btw, is that if long is 8 bytes wide, it should also be 8 bytes aligned. > --Andy > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] staging: wilc1000: Delete unnecessary checks before two function calls
On Sat, Jun 27, 2015 at 04:36:14PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 27 Jun 2015 15:56:57 +0200 Why is this in the body of the email? Please fix your email client or just use git send-email properly. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] sched: prefer an idle cpu vs an idle sibling for BALANCE_WAKE
On Mon, 2015-07-06 at 15:41 -0400, Josef Bacik wrote: > So the NO_WAKE_WIDE_IDLE results are very good, almost the same as the > baseline with a slight regression at lower RPS and a slight improvement > at high RPS. Good. I can likely drop the rest then (I like dinky, so do CPUs;). I'm not real keen on the feature unless your numbers are really good, and odds are that ain't gonna happen. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: lustre: obdclass: fix macro coding style issue in uuid.c
On Fri, Jun 26, 2015 at 11:04:49PM -0700, Joe Perches wrote:
> On Sat, 2015-06-27 at 06:36 +0100, Vasiliy Korchagin wrote:
> > This patch fixes the checkpatch.pl error:
> >
> > ERROR: Macros with complex values should be enclosed in parentheses
> > +#define CONSUME(val, ptr) (val) = consume(sizeof(val), (ptr))
> >
> > by expanding it as this macro is used only once.
> []
> > Notes:
> > Here is another version with macro expansion. Inline function expansion
> > doesn't
> > seem like a good idea to me as it would make things overcomplicated.
>
> It looks like it'd be simpler to use vsprintf extension %pU
> ---
> drivers/staging/lustre/lustre/obdclass/uuid.c | 34
> +--
> 1 file changed, 1 insertion(+), 33 deletions(-)
>
> diff --git a/drivers/staging/lustre/lustre/obdclass/uuid.c
> b/drivers/staging/lustre/lustre/obdclass/uuid.c
> index ff0a01b..b0b0157 100644
> --- a/drivers/staging/lustre/lustre/obdclass/uuid.c
> +++ b/drivers/staging/lustre/lustre/obdclass/uuid.c
> @@ -43,40 +43,8 @@
> #include "../include/obd_support.h"
> #include "../include/obd_class.h"
>
> -
> -static inline __u32 consume(int nob, __u8 **ptr)
> -{
> - __u32 value;
> -
> - LASSERT(nob <= sizeof(value));
> -
> - for (value = 0; nob > 0; --nob)
> - value = (value << 8) | *((*ptr)++);
> - return value;
> -}
> -
> -#define CONSUME(val, ptr) (val) = consume(sizeof(val), (ptr))
> -
> -static void uuid_unpack(class_uuid_t in, __u16 *uu, int nr)
> -{
> - __u8 *ptr = in;
> -
> - LASSERT(nr * sizeof(*uu) == sizeof(class_uuid_t));
> -
> - while (nr-- > 0)
> - CONSUME(uu[nr], &ptr);
> -}
> -
> void class_uuid_unparse(class_uuid_t uu, struct obd_uuid *out)
> {
> - /* uu as an array of __u16's */
> - __u16 uuid[sizeof(class_uuid_t) / sizeof(__u16)];
> -
> - CLASSERT(ARRAY_SIZE(uuid) == 8);
> -
> - uuid_unpack(uu, uuid, ARRAY_SIZE(uuid));
> - sprintf(out->uuid, "%04x%04x-%04x-%04x-%04x-%04x%04x%04x",
> - uuid[0], uuid[1], uuid[2], uuid[3],
> - uuid[4], uuid[5], uuid[6], uuid[7]);
> + sprintf(out->uuid, "%pU", uu);
> }
> EXPORT_SYMBOL(class_uuid_unparse);
I agree, much better, can you resend this in a form I can apply?
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] staging: wilc1000: One function call less in mac_ioctl() after error detection
On Sat, Jun 27, 2015 at 04:37:24PM +0200, SF Markus Elfring wrote: > From: Markus Elfring > Date: Sat, 27 Jun 2015 16:00:59 +0200 Again, please fix. > > The kfree() function was called in two cases by the mac_ioctl() function > during error handling even if the passed variable did not contain a pointer > for a valid data item. > > * This implementation detail could be improved by the introduction > of another jump label. > > * Drop an unnecessary initialisation for the variable "buff" then. That's a different issue, please fix it in a separate patch. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] usb: move assignment out of if condition
On Thu, Jul 02, 2015 at 06:23:59PM -0400, Kris Borer wrote: > Fix four occurrences of checkpatch.pl error: > > ERROR: do not use assignment in if condition > > Signed-off-by: Kris Borer > --- > drivers/usb/core/hcd.c | 19 +-- > 1 file changed, 13 insertions(+), 6 deletions(-) Again, please use Coccinelle for something like this, otherwise I'm not going to trust that it is correct :) thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] dmaengine: pl330: Really fix choppy sound because of wrong residue calculation
On Mon, Jun 15, 2015 at 11:00:09PM +0900, Krzysztof Kozlowski wrote: > When pl330 driver was used during sound playback, after some time or > after a number of plays the sound became choppy or totally noisy. For > example on Odroid XU3 board the first four executions of aplay with > small WAVE worked fine, but fifth was unrecognizable with errors: > $ aplay /usr/share/sounds/alsa/Front_Right.wava > underrun!!! (at least 0.095 ms long) > > Issue was caused by wrong residue reported by pl330 driver to > pcm_dmaengine for its cyclic dma transfers. > > The pl330_tx_status(), residue reporting function, used a "last" flag in > a descriptor to indicate that there is no more data to send. > > The pl330_tx_submit() iterated over descriptors trying to remove this > flag from them and then mark last descriptor as "last". However when > iterating it actually removed the flag not from descriptors but always > from last of it (and then reset it). Thus effectively once some > descriptor was marked as last, then it stayed like this forever causing > residue to be reported too low. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 7/8] xtensa: implement counting and sampling perf events
Hi Max,
We could probably still use NMI with a separate stack. However, for
exception handling while in NMI, we might have to implement something
similar to x86_64 (https://lwn.net/Articles/484932/).
Cheers!
-Chris
On Mon, Jul 6, 2015 at 7:22 AM, Max Filippov wrote:
> On Mon, Jul 6, 2015 at 5:05 PM, Peter Zijlstra wrote:
>> On Mon, Jul 06, 2015 at 04:56:09PM +0300, Max Filippov wrote:
>>> On Mon, Jul 6, 2015 at 4:47 PM, Peter Zijlstra wrote:
>>> > On Mon, Jul 06, 2015 at 04:32:48PM +0300, Max Filippov wrote:
>>> >> +static int __init xtensa_pmu_init(void)
>>> >> +{
>>> >> + int ret;
>>> >> + int irq = irq_create_mapping(NULL, XCHAL_PROFILING_INTERRUPT);
>>> >
>>> > Does this platform have interrupt priorities which you can partially
>>> > mask in order to create NMI like behaviour?
>>>
>>> Not sure what you mean by "NMI like".
>>
>> There's a number of archs where we implement NMIs by having
>> local_irq_disable() only disable part of the interrupt priority range
>> and making sure all 'normal' IRQs are mapped in that priority range.
>>
>> We then map our NMI handlers to a priority above the 'normal' range,
>> such that these interrupts can indeed happen when interrupts are
>> 'disabled.
>>
>> See for example:
>>
>> b4f4372f96e0 ("sparc64: Make %pil level 15 a pseudo-NMI.")
>> 0c25e9e6cbe7 ("sparc64: Adjust __raw_local_irq_save() to cooperate in NMIs.")
>> c011f80ba091 ("sparc64: Add some more commentary to __raw_local_irq_save()")
>
> Ok, I see. I guess I can change IRQ disabling logic to not mask perf IRQ
> in case it's configured as the only interrupt on its level and it's the
> highest
> medium-level IRQ.
>
>>> Interrupt priorities are fixed in the current xtensa architecture, and
>>> we can in theory mask certain level and below, but practically we
>>> always mask all low- and medium- level interrupts.
>>>
>>> Also we currently can't have handlers for high priority interrupts written
>>> in C.
>>
>> Why not? Surely this can be cured with an assembly stub?
>
> IIUC that was a deliberate architecture design choice and working around
> it penalizes all interrupt handlers. But let me take another close look.
>
>> The advantage of having NMIs is that profiling information for the
>> kernel becomes much more useful. Without this local_irq_enable() will be
>> a very 'hot' function.
>
> I haven't noticed that in my testing.
>
> --
> Thanks.
> -- Max
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND][PATCH v2] arm64:Modify the dump mem for 64 bit addresses
From: Rohit Thapliyal
V1 = added new function dump_mem64
v1->v2
Removed the separate function dump_mem64 and accommodated
a field width based on which the dump shall be created of
width either 4 or 8 as suggested by Catalin.
On 64bit kernel, the dump_mem gives 32 bit addresses
on the stack dump. This gives unorganized information regarding
the 64bit values on the stack. Hence, modified to get a complete
64bit memory dump.
With patch:
[ 93.534801] Process insmod (pid: 1587, stack limit = 0xffc976be4058)
[ 93.541441] Stack: (0xffc976be7cf0 to 0xffc976be8000)
[ 93.547136] 7ce0: ffc976be7d00
ffc8163c
[ 93.554898] 7d00: ffc976be7d40 ffcf8a44 ffc00098ef38
ffbffc88
[ 93.562659] 7d20: ffc00098ef50 ffbffcc0 0001
ffbffc70
[ 93.570419] 7d40: ffc976be7e40 ffcf935c
2b424090
[ 93.578179] 7d60: 2b424010 007facc555f4 8000
0015
[ 93.585937] 7d80: 0116 0069 ffc00097b000
ffc976be4000
[ 93.593694] 7da0: 0064 0072 006e
003f
[ 93.601453] 7dc0: feff fff1 ffbffc002028
0124
[ 93.609211] 7de0: ffc976be7e10 0001 ff80
ffbb
[ 93.616969] 7e00: ffc976be7e60
[ 93.624726] 7e20:
[ 93.632484] 7e40: 007fcc474550 ffc841ec 2b424010
007facda0710
[ 93.640241] 7e60: ffcbe6dc ff80007d2000
0001c010
[ 93.647999] 7e80: ff80007e0ae0 ff80007e09d0 ff80007edf70
0288
[ 93.655757] 7ea0: 02e8
001c001b
[ 93.663514] 7ec0: 0009 0007 2b424090
0001c010
[ 93.671272] 7ee0: 2b424010 007faccd3a48
[ 93.679030] 7f00: 007fcc4743f8 007fcc4743f8 0069
0003
[ 93.686787] 7f20: 0101010101010101 0004 0020
03f3
[ 93.694544] 7f40: 007facb95664 007facda7030 007facc555d0
00498378
[ 93.702301] 7f60: 2b424010 007facda0710
2b424090
[ 93.710058] 7f80: 007fcc474698 00498000 007fcc474ebb
00474f58
[ 93.717815] 7fa0: 00498000
007fcc474550
[ 93.725573] 7fc0: 004104bc 007fcc474430 007facc555f4
8000
[ 93.70] 7fe0: 2b424090 0069 0950020128000244
41040804
[ 93.741084] Call trace:
The above output makes a debugger life a lot more easier.
Signed-off-by: Rohit Thapliyal
Signed-off-by: Maninder Singh
Reviewed-by: Akhilesh kumar
---
arch/arm64/kernel/traps.c | 44 +---
1 file changed, 33 insertions(+), 11 deletions(-)
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index 1ef2940..53d57db 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -51,8 +51,9 @@ int show_unhandled_signals = 1;
/*
* Dump out the contents of some memory nicely...
*/
+
static void dump_mem(const char *lvl, const char *str, unsigned long bottom,
-unsigned long top)
+unsigned long top, unsigned int width)
{
unsigned long first;
mm_segment_t fs;
@@ -70,18 +71,27 @@ static void dump_mem(const char *lvl, const char *str,
unsigned long bottom,
for (first = bottom & ~31; first < top; first += 32) {
unsigned long p;
- char str[sizeof(" 12345678") * 8 + 1];
+ char str[sizeof(" 1234567812345678") * 8 + 1];
memset(str, ' ', sizeof(str));
str[sizeof(str) - 1] = '\0';
- for (p = first, i = 0; i < 8 && p < top; i++, p += 4) {
+ for (p = first, i = 0; i < (width > 4 ? width-4 : width+4)
+ && p < top; i++, p += width) {
if (p >= bottom && p < top) {
- unsigned int val;
- if (__get_user(val, (unsigned int *)p) == 0)
- sprintf(str + i * 9, " %08x", val);
- else
- sprintf(str + i * 9, " ");
+ unsigned long val;
+
+ if (width == 8) {
+ if (__get_user(val, (unsigned long *)p)
== 0)
+ sprintf(str + i * 17, "
%016lx", val);
+ else
+
Re: [PATCH] dmaengine: pl330: Fix overflow when reporting residue in memcpy
On Mon, Jun 15, 2015 at 05:25:16PM +0900, Krzysztof Kozlowski wrote: > During memcpy operations the residue was always set to an u32 overflowed > value. > > In pl330_tx_status() function number of currently transferred bytes was > subtracted from internal "bytes_requested" field. However this > "bytes_requested" was not initialized at start to length of memcpy > buffer so transferred bytes were subtracted from 0 causing overflow. Applied, thanks -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf, kprobes: fuzzer generates huge number of WARNings
On Tue, 7 Jul 2015, Masami Hiramatsu wrote: > On 2015/07/07 6:27, Vince Weaver wrote: > > Hello > > > > I've been working on trying to get the perf_fuzzer to start fuzzing the > > PERF_EVENT_IOC_SET_BPF so I've added some really hackish kprobe support. > > > > However before I can get to the BPF testing the kprobe code generates a > > constant stream of WARNINGS which make the machine more or less useless > > until I stop it. I've included a small selection here. > > > > Is this expected? > > Did you get same message without BPF hack? And also, could you tell us > your kernel version and configuration? It's a Hawell machine running 4.2-rc1. I can post the .config if it's of interest. Well the BPF hack is in the fuzzer, not the kernel. And it's not really a hack, it just turned out to be a huge pain to figure out how to manually create a valid BPF program in conjunction with a valid kprobe event. I did have to sprinkle printks in the kprobe and bpf code to find out where various EINVAL returns were coming from, so potentially this is just a problem of printks happening where they shouldn't. I'll remove those changes and try to reproduce this tomorrow. This is possibly a long standing issue, until now I never ran the fuzzer as root so these particular code paths weren't tested. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf, kprobes: fuzzer generates huge number of WARNings
On Mon, 6 Jul 2015, Steven Rostedt wrote: > On Mon, 6 Jul 2015 17:27:04 -0400 (EDT) > Vince Weaver wrote: > > [ 3521.650521] ---[ end trace a413501925547ed5 ]--- > > [ 3521.655960] ftrace failed to modify [] > > handle_mm_fault+0x0/0x1750 > > [ 3521.664767] actual: e8:cb:18:ef:1e > > Hmm, it was not expecting to see this address above in the mcount slot. > Did you have other tracing going on, or did you add a kprobe to > handle_mm_fault too? it's fuzzing so there were potentially a large number of tracepoint events active at the time. Only one kprobe event, p:probe/VMW _text+1664816 and I forget what that actually mapped to originally. Vince -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] net: dsa: mv88e6xxx: add support for VLAN Table Unit
On Mon, Jul 6, 2015 at 7:00 PM, Andrew Lunn wrote:
> On Tue, Jul 07, 2015 at 01:38:04AM +0200, Andrew Lunn wrote:
>> On Sun, Jul 05, 2015 at 10:14:50PM -0400, Vivien Didelot wrote:
>> > Hi all,
>> >
>> > This patchset brings full support for hardware VLANs in DSA, and the
>> > Marvell
>> > 88E6xxx compatible switch chips.
>>
>> Hi Vivien
>>
>> I just booted these patches on my board, and i'm getting WARNINGS:
>>
>> [ 61.111302] WARNING: CPU: 0 PID: 2751 at net/switchdev/switchdev.c:265
>> switchdev_port_obj_add+0xd4/0xdc()
>
> Hi Vivien
>
> I debugged this a bit.
>
> The problem comes from:
>
> static int dsa_slave_port_obj_add(struct net_device *dev,
> struct switchdev_obj *obj)
> {
> int err;
>
> /*
> * Skip the prepare phase, since currently the DSA drivers don't need
> to
> * allocate any memory for operations and they will not fail to HW
> * (unless something horrible goes wrong on the MDIO bus, in which
> case
> * the prepare phase wouldn't have been able to predict anyway).
> */
> if (obj->trans != SWITCHDEV_TRANS_COMMIT)
> return 0;
>
> switch (obj->id) {
> case SWITCHDEV_OBJ_PORT_VLAN:
> err = dsa_slave_port_vlans_add(dev, obj);
> break;
> default:
> err = -EOPNOTSUPP;
> break;
> }
>
> return err;
> }
>
> It is being called with obj->id of 2, which is
> SWITCHDEV_OBJ_IPV4_FIB. This function is called twice. The first time
> it is with SWITCHDEV_TRANS_PREPARE and we are allowed to return an
> error. The second time, with SWITCHDEV_TRANS_COMMIT, errors are not
> allowed.
>
> EOPNOTSUPP is considered an error, so since we don't support
> SWITCHDEV_OBJ_IPV4_FIB we error out the COMMIT phase.
>
> Not sure which is cleaner. Test to see if we support the object during
> the prepare, or allow the commit to accept EOPNOTSUPP as not being an
> error?
I think we should return EOPNOTSUPP on PREPARE, so move the trans !=
COMMIT test inside the case for PORT_VLAN. That would future-proof
the func when new objects are added to switchdev (and not supported by
dsa_slave).
Does that sound OK?
-scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] perf tools: Allow passing perf's own pid to '--filter'
This patch allows passing perf's own PID to '--filter' by using
'$PERFPID'. This should be useful when system-widely capturing
tracepoints events.
Before this patch, when doing something like:
# perf record -a -e syscalls:sys_enter_write
One could easily get result like this:
# perf report --stdio
...
# Overhead Command Shared Object Symbol
# ... ..
#
99.99% perf libpthread-2.18.so [.] __write_nocancel
0.01% ls libc-2.18.so[.] write
0.01% sshd libc-2.18.so[.] write
...
Where most events are generated by perf itself.
A shell trick can be done to filter perf itself out:
# cat << EOF > ./tmp
> #!/bin/sh
> exec perf record -e ... --filter="common_pid != \$\$" -a sleep 10
> EOF
# chmod a+x ./tmp
# ./tmp
However, doing so is user unfriendly.
This patch introduces '$PERFPID' placeholder to perf's filter. Now
user is allowed to do the above work with:
# perf record -e ... --filter='common_pid != $PERFPID' -a sleep 10
This patch adds the variable replacement code to perf_evsel__apply_filter(),
before PERF_EVENT_IOC_SET_FILTER ioctl, so not only 'perf record', all
subcommands which uses filter can utilize $PERFPID.
Andi Kleen sent a similar patch at 2014, but wasn't applied, the
reason is not clear.
Signed-off-by: Wang Nan
---
This patch is based on Arnaldo Carvalho de Melo's git tree:
https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/commit/?h=perf/core
---
tools/perf/Documentation/perf-record.txt | 5 +-
tools/perf/util/evsel.c | 110 ++-
2 files changed, 111 insertions(+), 4 deletions(-)
diff --git a/tools/perf/Documentation/perf-record.txt
b/tools/perf/Documentation/perf-record.txt
index 9b9d9d0..9c67482 100644
--- a/tools/perf/Documentation/perf-record.txt
+++ b/tools/perf/Documentation/perf-record.txt
@@ -61,7 +61,10 @@ OPTIONS
"perf report" to view group events together.
--filter=::
-Event filter.
+Event filter. $PERFPID is allowed to be used to represent perf's own
pid.
+Note that '$' has special meaning for shell. Don't forget to use ''
+quotation marks or to use '\' to escape when using '$PERFPID' in
command
+line.
-a::
--all-cpus::
diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
index 83c0803..7f2a1a5 100644
--- a/tools/perf/util/evsel.c
+++ b/tools/perf/util/evsel.c
@@ -816,12 +816,116 @@ static int perf_evsel__run_ioctl(struct perf_evsel
*evsel, int ncpus, int nthrea
return 0;
}
+static int
+perf_evsel__append_filter_token(const char *key, char *new_filter,
+ ssize_t *pspace)
+{
+ if (strcmp(key, "PERFPID") == 0) {
+ char pid_buf[32];
+ pid_t self_pid = getpid();
+
+ snprintf(pid_buf, sizeof(pid_buf), "%d", self_pid);
+ strncat(new_filter, pid_buf, *pspace);
+ *pspace -= strlen(pid_buf);
+ if (*pspace < 0)
+ return -1;
+ return 0;
+ }
+
+ return -1;
+}
+
+static const char *
+perf_evsel__postproc_filter(const char *filter)
+{
+ char *dollar = NULL, *sep = NULL, *p;
+ char *old_filter = NULL, *new_filter = NULL;
+ ssize_t space;
+
+ if (!filter)
+ return NULL;
+
+ dollar = strchr(filter, '$');
+ if (!dollar)
+ return filter;
+
+ p = old_filter = strdup(filter);
+ if (!old_filter) {
+ pr_warning("Can't alloc memory when postprocing filter '%s'\n",
+ filter);
+ return filter;
+ }
+
+ dollar = old_filter + (dollar - filter);
+
+ /*
+* See perf_event_set_filter(). Length of a valid filter is
+* limited by page_size.
+*/
+ new_filter = malloc(page_size);
+ if (!new_filter) {
+ pr_warning("Can't alloc memory when postprocing filter '%s'\n",
+ filter);
+ goto errout;
+ }
+
+ *new_filter = '\0';
+ space = page_size - 1;
+
+ while (1) {
+ if (dollar)
+ *dollar = '\0';
+ strncat(new_filter, p, space);
+ space -= strlen(p);
+ if (space < 0)
+ goto errout;
+ if (!dollar)
+ break;
+
+ sep = strchr(dollar + 1, ' ');
+ if (sep)
+ *sep = '\0';
+
+ if (perf_evsel__append_filter_token(dollar + 1, new_filter,
+ &space)) {
+ pr_warning("Filter become too long: '%s'\n", filter);
+ goto errout;
+ }
+
+ if (!sep)
+ break;
+
+ p = sep;
+ *p = ' ';
+
[PATCH 2/6] xen/x86: Remove unnecessary memset() call
Since ctxt is kzalloc'd there is no need to call a memset for
ctxt->fpu_ctxt.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/smp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index ca7ee1f..7cf0765 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -377,7 +377,6 @@ cpu_initialize_context(unsigned int cpu, struct task_struct
*idle)
ctxt->user_regs.fs = __KERNEL_PERCPU;
ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
#endif
- memset(&ctxt->fpu_ctxt, 0, sizeof(ctxt->fpu_ctxt));
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/6] xen/x86/pvh: Allow building 32-bit PVH guests
Signed-off-by: Boris Ostrovsky --- arch/x86/xen/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/xen/Kconfig b/arch/x86/xen/Kconfig index e88fda8..891031e 100644 --- a/arch/x86/xen/Kconfig +++ b/arch/x86/xen/Kconfig @@ -48,5 +48,5 @@ config XEN_DEBUG_FS config XEN_PVH bool "Support for running as a PVH guest" - depends on X86_64 && XEN && XEN_PVHVM + depends on XEN && XEN_PVHVM def_bool n -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] xen/x86/pvh: Save %rbx in xen_pvh_early_cpu_init()
x86-64 ABI requires that functions preserve %rbx. When
xen_pvh_early_cpu_init() is executed on boot cpu it is invoked as a
function and 'cpuid' instruction will clobber %rbx. (This is not a
concern on secondary processors since there xen_pvh_early_cpu_init() is
the entry point and thus does not need to preserve registers.)
Since we cannot access stack on secondary processors (PTE's NX bit will
cause #GP on AMD --- see commit a2ef5dc2c7cb ("x86/xen: Set EFER.NX and
EFER.SCE in PVH guests")) we can't always save %rbx on the stack. We
work around this by creating a new entry point for those processors ---
xen_pvh_early_cpu_init_secondary(). Note that on secondary CPUs we will
load %rbx with garbage, which is OK.
As a side effect of these changes we don't need to save %rsi anymore,
since we can use %rbx instead of %rsi as a temporary register.
(We could store %rbx into another scratch register such as %r8 but since
we will need new entry point for 32-bit PVH anyway we go with this
approach for symmetry)
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/smp.c | 3 ++-
arch/x86/xen/smp.h | 4
arch/x86/xen/xen-head.S | 14 +++---
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 8648438..ca7ee1f 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -423,7 +423,8 @@ cpu_initialize_context(unsigned int cpu, struct task_struct
*idle)
* bit set. This means before DS/SS is touched, NX in
* EFER must be set. Hence the following assembly glue code.
*/
- ctxt->user_regs.eip = (unsigned long)xen_pvh_early_cpu_init;
+ ctxt->user_regs.eip =
+ (unsigned long)xen_pvh_early_cpu_init_secondary;
ctxt->user_regs.rdi = cpu;
ctxt->user_regs.rsi = true; /* entry == true */
}
diff --git a/arch/x86/xen/smp.h b/arch/x86/xen/smp.h
index 963d62a..bf2b43c 100644
--- a/arch/x86/xen/smp.h
+++ b/arch/x86/xen/smp.h
@@ -10,10 +10,14 @@ extern void xen_send_IPI_self(int vector);
#ifdef CONFIG_XEN_PVH
extern void xen_pvh_early_cpu_init(int cpu, bool entry);
+extern void xen_pvh_early_cpu_init_secondary(int cpu, bool entry);
#else
static inline void xen_pvh_early_cpu_init(int cpu, bool entry)
{
}
+static inline void xen_pvh_early_cpu_init_secondary(int cpu, bool entry)
+{
+}
#endif
#endif
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index 8afdfcc..b1508a8 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -56,28 +56,28 @@ ENTRY(startup_xen)
* @entry: true if this is a secondary vcpu coming up on this entry
* point, false if this is the boot CPU being initialized for
* the first time (%rsi)
- *
- * Note: This is called as a function on the boot CPU, and is the entry point
- * on the secondary CPU.
*/
ENTRY(xen_pvh_early_cpu_init)
- mov %rsi, %r11
+ mov %rbx, -8(%rsp)
+/* Entry point for secondary CPUs */
+ENTRY(xen_pvh_early_cpu_init_secondary)
/* Gather features to see if NX implemented. */
mov $0x8001, %eax
cpuid
- mov %edx, %esi
+ mov %edx, %ebx
mov $MSR_EFER, %ecx
rdmsr
bts $_EFER_SCE, %eax
- bt $20, %esi
+ bt $20, %ebx
jnc 1f /* No NX, skip setting it */
bts $_EFER_NX, %eax
1: wrmsr
+ mov -8(%rsp), %rbx
#ifdef CONFIG_SMP
- cmp $0, %r11b
+ cmp $0, %esi
jne cpu_bringup_and_idle
#endif
ret
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/6] 32-bit PVH domU support
A set of PVH-related patches. The first patch is x86-64 ABI fix for PVH guests. The second is a small update that removes redundant memset (both on PV and PVH code paths) The rest is to enable non-privileged 32-bit PVH guests. This requires hypervisor patches from http://lists.xenproject.org/archives/html/xen-devel/2015-06/msg04817.html Boris Ostrovsky (6): xen/x86/pvh: Save %rbx in xen_pvh_early_cpu_init() xen/x86: Remove unnecessary memset() call xen/x86/pvh: Properly set page tables for 32-bit PVH guests xen/x86/pvh: Set up descriptors for 32-bit PVH guests xen/x86/pvh: Add 32-bit PVH initialization code xen/x86/pvh: Allow building 32-bit PVH guests arch/x86/xen/Kconfig | 2 +- arch/x86/xen/enlighten.c | 20 arch/x86/xen/mmu.c | 22 +- arch/x86/xen/smp.c | 21 - arch/x86/xen/smp.h | 4 arch/x86/xen/xen-head.S | 29 + 6 files changed, 63 insertions(+), 35 deletions(-) -- 1.8.1.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] xen/x86/pvh: Set up descriptors for 32-bit PVH guests
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 0b95c9b..7953e68 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1362,12 +1362,12 @@ static void __init xen_boot_params_init_edd(void)
static void __ref xen_setup_gdt(int cpu)
{
if (xen_feature(XENFEAT_auto_translated_physmap)) {
-#ifdef CONFIG_X86_64
unsigned long dummy;
- load_percpu_segment(cpu); /* We need to access per-cpu area */
+ setup_stack_canary_segment(cpu);
switch_to_new_gdt(cpu); /* GDT and GS set */
+#ifdef CONFIG_X86_64
/* We are switching of the Xen provided GDT to our HVM mode
* GDT. The new GDT has __KERNEL_CS with CS.L = 1
* and we are jumping to reload it.
@@ -1392,8 +1392,16 @@ static void __ref xen_setup_gdt(int cpu)
loadsegment(ds, 0);
loadsegment(fs, 0);
#else
- /* PVH: TODO Implement. */
- BUG();
+ asm volatile ("ljmp %1,$1f\n"
+ "1:\n"
+ "movl %2,%0\n"
+ "movl %0,%%ss\n"
+ "movl %3,%0\n"
+ "movl %0,%%ds\n"
+ "movl %0,%%es\n"
+ : "=&r" (dummy)
+ : "i" (__KERNEL_CS), "i" (__KERNEL_DS),
+ "i" (__USER_DS));
#endif
return; /* PVH does not need any PV GDT ops. */
}
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/6] xen/x86/pvh: Properly set page tables for 32-bit PVH guests
32-bit PVH guests don't want to write-protect/pin page tables.
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/mmu.c | 22 +-
1 file changed, 13 insertions(+), 9 deletions(-)
diff --git a/arch/x86/xen/mmu.c b/arch/x86/xen/mmu.c
index dd151b2..b473df8 100644
--- a/arch/x86/xen/mmu.c
+++ b/arch/x86/xen/mmu.c
@@ -1762,8 +1762,9 @@ void __init xen_setup_machphys_mapping(void)
machine_to_phys_nr = MACH2PHYS_NR_ENTRIES;
}
#ifdef CONFIG_X86_32
- WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
- < machine_to_phys_mapping);
+ if (!xen_feature(XENFEAT_auto_translated_physmap))
+ WARN_ON((machine_to_phys_mapping + (machine_to_phys_nr - 1))
+ < machine_to_phys_mapping);
#endif
}
@@ -1958,15 +1959,18 @@ void __init xen_setup_kernel_pagetable(pgd_t *pgd,
unsigned long max_pfn)
initial_page_table[KERNEL_PGD_BOUNDARY] =
__pgd(__pa(initial_kernel_pmd) | _PAGE_PRESENT);
- set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
- set_page_prot(initial_page_table, PAGE_KERNEL_RO);
- set_page_prot(empty_zero_page, PAGE_KERNEL_RO);
+ if (!xen_feature(XENFEAT_auto_translated_physmap)) {
+ set_page_prot(initial_kernel_pmd, PAGE_KERNEL_RO);
+ set_page_prot(initial_page_table, PAGE_KERNEL_RO);
+ set_page_prot(empty_zero_page, PAGE_KERNEL_RO);
- pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
+ pin_pagetable_pfn(MMUEXT_UNPIN_TABLE, PFN_DOWN(__pa(pgd)));
- pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
- PFN_DOWN(__pa(initial_page_table)));
- xen_write_cr3(__pa(initial_page_table));
+ pin_pagetable_pfn(MMUEXT_PIN_L3_TABLE,
+ PFN_DOWN(__pa(initial_page_table)));
+ xen_write_cr3(__pa(initial_page_table));
+ } else
+ native_write_cr3(__pa(initial_page_table));
memblock_reserve(__pa(xen_start_info->pt_base),
xen_start_info->nr_pt_frames * PAGE_SIZE);
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/6] xen/x86/pvh: Add 32-bit PVH initialization code
Signed-off-by: Boris Ostrovsky
---
arch/x86/xen/enlighten.c | 4
arch/x86/xen/smp.c | 17 ++---
arch/x86/xen/xen-head.S | 17 +++--
3 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/arch/x86/xen/enlighten.c b/arch/x86/xen/enlighten.c
index 7953e68..807337e 100644
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@ -1464,10 +1464,6 @@ static void __init xen_pvh_early_guest_init(void)
xen_pvh_early_cpu_init(0, false);
xen_pvh_set_cr_flags(0);
-
-#ifdef CONFIG_X86_32
- BUG(); /* PVH: Implement proper support. */
-#endif
}
#endif/* CONFIG_XEN_PVH */
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 7cf0765..99be53b 100644
--- a/arch/x86/xen/smp.c
+++ b/arch/x86/xen/smp.c
@@ -372,11 +372,8 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle)
gdt = get_cpu_gdt_table(cpu);
-#ifdef CONFIG_X86_32
- /* Note: PVH is not yet supported on x86_32. */
- ctxt->user_regs.fs = __KERNEL_PERCPU;
- ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
-#endif
+ ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
+ ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
if (!xen_feature(XENFEAT_auto_translated_physmap)) {
ctxt->user_regs.eip = (unsigned long)cpu_bringup_and_idle;
@@ -403,6 +400,8 @@ cpu_initialize_context(unsigned int cpu, struct task_struct
*idle)
ctxt->kernel_sp = idle->thread.sp0;
#ifdef CONFIG_X86_32
+ ctxt->user_regs.fs = __KERNEL_PERCPU;
+ ctxt->user_regs.gs = __KERNEL_STACK_CANARY;
ctxt->event_callback_cs = __KERNEL_CS;
ctxt->failsafe_callback_cs = __KERNEL_CS;
#else
@@ -424,12 +423,16 @@ cpu_initialize_context(unsigned int cpu, struct
task_struct *idle)
*/
ctxt->user_regs.eip =
(unsigned long)xen_pvh_early_cpu_init_secondary;
+#ifdef CONFIG_X86_64
ctxt->user_regs.rdi = cpu;
ctxt->user_regs.rsi = true; /* entry == true */
+#else
+ *((uint32_t *)ctxt->user_regs.esp + 1) = cpu;
+ *((uint32_t *)ctxt->user_regs.esp + 2) = true;
+#endif
}
#endif
- ctxt->user_regs.esp = idle->thread.sp0 - sizeof(struct pt_regs);
- ctxt->ctrlreg[3] = xen_pfn_to_cr3(virt_to_mfn(swapper_pg_dir));
+
if (HYPERVISOR_vcpu_op(VCPUOP_initialise, cpu, ctxt))
BUG();
diff --git a/arch/x86/xen/xen-head.S b/arch/x86/xen/xen-head.S
index b1508a8..12c4e2a 100644
--- a/arch/x86/xen/xen-head.S
+++ b/arch/x86/xen/xen-head.S
@@ -51,14 +51,18 @@ ENTRY(startup_xen)
#ifdef CONFIG_XEN_PVH
/*
- * xen_pvh_early_cpu_init() - early PVH VCPU initialization
+ * xen_pvh_early_cpu_init(cpu, entry) - early PVH VCPU initialization
* @cpu: this cpu number (%rdi)
* @entry: true if this is a secondary vcpu coming up on this entry
* point, false if this is the boot CPU being initialized for
* the first time (%rsi)
*/
ENTRY(xen_pvh_early_cpu_init)
+#ifdef CONFIG_X86_64
mov %rbx, -8(%rsp)
+#else
+ mov %ebx, -4(%esp)
+#endif
/* Entry point for secondary CPUs */
ENTRY(xen_pvh_early_cpu_init_secondary)
@@ -69,15 +73,24 @@ ENTRY(xen_pvh_early_cpu_init_secondary)
mov $MSR_EFER, %ecx
rdmsr
+#ifdef CONFIG_X86_64
bts $_EFER_SCE, %eax
+#endif
bt $20, %ebx
jnc 1f /* No NX, skip setting it */
bts $_EFER_NX, %eax
1: wrmsr
+
+#ifdef CONFIG_X86_64
mov -8(%rsp), %rbx
-#ifdef CONFIG_SMP
cmp $0, %esi
+#else
+ mov -4(%esp), %ebx
+ cmp $0, 8(%esp) /* second argument */
+#endif
+
+#ifdef CONFIG_SMP
jne cpu_bringup_and_idle
#endif
ret
--
1.8.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] regmap: add fast_io_disable_irq property for regmap_config
(please ignore the last email which contain HTML format and was rejected, sorry
for the inconvenience caused)
This patch aims to fix an issue when using the regmap function in different
drivers.
I describe the issue here:
We want to use the the same regmap handler to access the same hardware module
using syscon interface in different drivers.
Some driver will read the register in interrupt handler to get the hardware
information while other drivers will access some other registers by regmap at
the same time, so there will be a synchronization issue because the
spin_lock/spin_unlock is used in regmap_read/regmap_write. a dead lock maybe
happen on the current CPU.
This patch adds a property named fast_io_disable_irq and when this property is
set to true the spin_lock_irqsave/spin_lockirqrestore lock function will be
used in regmap_read/regmap_write to disable the local IRQ when accessing the
register to avoid the lock issue.
Change-Id: I07424191f3ab65d3f89bfee81fe2b4422cf84e74
Signed-off-by: Xuewen Zhou
---
drivers/base/regmap/internal.h | 1 +
drivers/base/regmap/regmap.c | 18 +-
include/linux/regmap.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 5a22bd3..6a66e6b 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -54,6 +54,7 @@ struct regmap {
regmap_lock lock;
regmap_unlock unlock;
void *lock_arg; /* This is passed to lock/unlock functions */
+ unsigned long flags;
struct device *dev; /* Device we do I/O on */
void *work_buf; /* Scratch buffer used to format I/O */
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 58cfb32..b9b188e 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -297,6 +297,18 @@ static void regmap_unlock_spinlock(void *__map)
spin_unlock(&map->spinlock);
}
+static void regmap_lock_spinlock_irqsave(void *__map)
+{
+ struct regmap *map = __map;
+ spin_lock_irqsave(&map->spinlock, map->flags);
+}
+
+static void regmap_unlock_spinlock_irqrestore(void *__map)
+{
+ struct regmap *map = __map;
+ spin_unlock_irqrestore(&map->spinlock, map->flags);
+}
+
static void dev_get_regmap_release(struct device *dev, void *res)
{
/*
@@ -403,7 +415,11 @@ struct regmap *regmap_init(struct device *dev,
map->unlock = config->unlock;
map->lock_arg = config->lock_arg;
} else {
- if ((bus && bus->fast_io) ||
+ if (config->fast_io_disable_irq) {
+ spin_lock_init(&map->spinlock);
+ map->lock = regmap_lock_spinlock_irqsave;
+ map->unlock = regmap_unlock_spinlock_irqrestore;
+ } else if ((bus && bus->fast_io) ||
config->fast_io) {
spin_lock_init(&map->spinlock);
map->lock = regmap_lock_spinlock;
diff --git a/include/linux/regmap.h b/include/linux/regmap.h
index bf77dfd..ca3c637 100644
--- a/include/linux/regmap.h
+++ b/include/linux/regmap.h
@@ -193,6 +193,7 @@ struct regmap_config {
int (*reg_write)(void *context, unsigned int reg, unsigned int val);
bool fast_io;
+ bool fast_io_disable_irq;
unsigned int max_register;
const struct regmap_access_table *wr_table;
--
Best regards,
Xuewen Zhou From fcac70930f1a8e48795585234335aef92797e296 Mon Sep 17 00:00:00 2001
From: Xuewen Zhou
Date: Thu, 2 Jul 2015 15:50:36 +0800
Subject: [PATCH] regmap: add fast_io_disable_irq property for regmap_config
different drivers can share the same regmap handler to access the same
hardware module registers by syscon or other mechanism.
there will be a synchronization issue if one of the driver access the
register in interrupt handler because the spin_lock maybe has been hold
by other regsiter access using the same regmap handler and it will cause
a dead lock.
when fast_io_disable_irq is set to true, the regmap_read/reagmap_write
will use spin_lock_irqsave/spin_lockirqrestore to do the syncrhonization
to avoid the lock issue.
Change-Id: I07424191f3ab65d3f89bfee81fe2b4422cf84e74
Signed-off-by: Xuewen Zhou
---
drivers/base/regmap/internal.h | 1 +
drivers/base/regmap/regmap.c | 18 +-
include/linux/regmap.h | 1 +
3 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 5a22bd3..6a66e6b 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -54,6 +54,7 @@ struct regmap {
regmap_lock lock;
regmap_unlock unlock;
void *lock_arg; /* This is passed to lock/unlock functions */
+ unsigned long flags;
struct device *dev; /* Device we do I/O on */
void *work_buf; /* Scratch buffer used to format I/O */
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 58cfb32..b9b188e 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -297,6 +297,18 @@ static void regmap_unlock_spinlock(void *__map)
spin_unlock(&map->spinlock);
}
+static void regmap_lock_spinloc
Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
Hi, On Tue, Jul 07, 2015 at 02:10:26AM +, John Youn wrote: > On 7/1/2015 8:00 PM, Felipe Balbi wrote: > > On Thu, Jul 02, 2015 at 02:03:14AM +, John Youn wrote: > >> On 6/29/2015 2:48 PM, Felipe Balbi wrote: > >>> Hi again, > >>> > >>> On Mon, Jun 29, 2015 at 04:47:01PM -0500, Felipe Balbi wrote: > On Thu, May 21, 2015 at 03:46:48PM +0530, Subbaraya Sundeep Bhatta wrote: > > We need to return error to caller if command is not sent to > > controller succesfully. > > > > Signed-off-by: Subbaraya Sundeep Bhatta > > Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) > > Cc: > > --- > > v2 changes: > > Added Fixes and Cc in commit message. > > I noticed that this breaks at least my AM437x silicon with DWC3 2.40a > when used with g_zero and testusb. As of now, it could be that silicon > is mis-behaving because I got a Transfer Complete before the failing Set > Endpoint Transfer Resource command. > > In any case, can you run on your setup with g_zero and test.sh/testusb > [1]/[2] just to verify that it really works for you ? > > Meanwhile, I'll continue testing on my end. > > cheers > > [1] > https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:testusb.c > [2] > https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:test.sh > >>> > >>> Adding John here. John, any chance you could fire up dwc3 on HAPS and > >>> see wether it works or fails for you ? > >>> > >>> cheers > >>> > >> > >> Hi Felipe, > >> > >> Just an update on this. > >> > >> I'm trying to get this working with our latest IP with dwc3 from your > >> testing/next branch. It fails the usbtest with a problem unrelated to > >> this patch. > >> > >> It passes on 4.1.1. > >> > >> I'll have to look into the failure but I won't get to it until next > >> week as I'm off the rest of this week. > > > > interesting... If you could post failure signature, I can help looking > > at it, but I guess it's too late to ask :-) > > > > thanks for helping though > > > > > Hi Felipe, > > Nevermind about my issue, it ended up being a setup-related > problem. > > I actually do see the same error as you due to this series of > patches. Except I see it happening before even the first > iteration. I get a completion status of 1 for the Set Endpoint > Transfer Resources command. I'm not sure why this is. > > I don't see any conflict with any previous Transfer Complete. > > I will have to consult with some hardware engineers tomorrow to > look into it further. cool, thanks. Just let me know if it ends up being something larger, then we can revert that commit for the time being until we come to a conclusion. Thanks a lot for helping with testing. > The trace is attached. thanks a lot :-) Do you mind letting me know which version are you using? 3.00a ? -- balbi signature.asc Description: Digital signature
Re: [PATCH] arm64: dts: mt8173-evb: Add PMIC support
On Mon, 2015-07-06 at 18:39 +0200, Matthias Brugger wrote:
> On Monday, July 06, 2015 03:43:57 PM Eddie Huang wrote:
> > On Mon, 2015-06-22 at 21:19 +0800, Henry Chen wrote:
> > > From: Eddie Huang
> > >
[...]
> > > diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts index 43d5401..b967914
> > > 100644
> > > --- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > +++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
> > > @@ -33,6 +33,180 @@
> > >
> > > chosen { };
> > >
> > > };
> > >
> > > +&pwrap {
> > > + pmic: mt6397 {
> > > + compatible = "mediatek,mt6397";
> > > + interrupt-parent = <&pio>;
> > > + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>;
> > > + interrupt-controller;
> > > + #interrupt-cells = <2>;
> > > +
> > > + mt6397regulator: mt6397regulator {
> > > + compatible = "mediatek,mt6397-regulator";
> > > + mt6397_vpca15_reg: buck_vpca15 {
> > > + regulator-compatible = "buck_vpca15";
> > > + regulator-name = "vpca15";
> > > + regulator-min-microvolt = < 70>;
> > > + regulator-max-microvolt = <135>;
> > > + regulator-ramp-delay = <12500>;
> > > + regulator-always-on;
> >
> > I see you pull da9211 regulator dts patch, but not this one. How about
> > this patch ?
>
> I inserted some new-lines and added it to v4.2-next/arm64
>
Thanks the pull. Normally we put alias node in alphabetical order, make
later merge more easily. I think you can do the modification and squeeze
into the same commit.
Thanks
Eddie
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Jul 7
Hi all, Now that -rc1 is out, please clean up your trees if necessary. Changes since 20150706: My fixes tree contains: Merge branch 'perf-urgent-for-linus' of ../../tip The device-mapper tree lost its build failure. Non-merge commits (relative to Linus' tree): 676 725 files changed, 51320 insertions(+), 11448 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 and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 221 trees (counting Linus' and 31 trees of patches pending for Linus' tree). 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 Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (1c4c7159ed24 Merge tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4) Merging fixes/master (a7142cb42468 Merge branch 'perf-urgent-for-linus' of ../../tip) Merging kbuild-current/rc-fixes (c517d838eb7d Linux 4.0-rc1) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (11b8b25ce4f8 ARM: fix lockdep unannotated irqs-off warning) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-merge-mpe/fixes (a8956a7b7232 powerpc/powernv: Fix opal-elog interrupt handler) Merging powerpc-merge/merge (c517d838eb7d Linux 4.0-rc1) Merging sparc/master (4a10a91756ef Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/audit) Merging net/master (fda8b18c515a cxgb4: Fix incorrect sequence numbers shown in devlog) Merging ipsec/master (31a418986a58 xen: netback: read hotplug script once at start of day.) Merging sound-current/for-linus (e828b23734bf ALSA: hda - add codec ID for Broxton display audio codec) Merging pci-current/for-linus (552bc94ebeeb PCI: Preserve resource size during alignment reordering) Merging wireless-drivers/master (38fe44e61a89 Merge tag 'iwlwifi-for-kalle-2015-05-28' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging driver-core.current/driver-core-linus (d770e558e219 Linux 4.2-rc1) Merging tty.current/tty-linus (d770e558e219 Linux 4.2-rc1) Merging usb.current/usb-linus (d770e558e219 Linux 4.2-rc1) Merging usb-gadget-fixes/fixes (d770e558e219 Linux 4.2-rc1) Merging usb-serial-fixes/usb-linus (f98a7aa81eee USB: cp210x: add ID for Aruba Networks controllers) Merging staging.current/staging-linus (59b750006ae2 staging: make board support depend on OF_IRQ and CLKDEV_LOOKUP) Merging char-misc.current/char-misc-linus (d770e558e219 Linux 4.2-rc1) Merging input-current/for-linus (a5cba18c4de2 Merge branch 'next' into for-linus) Merging crypto-current/master (acb33cc541d7 crypto: omap-des - Fix unmapping of dma channels) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (f36963c9d3f6 cpumask_set_cpu_local_first => cpumask_local_spread, lament) Merging vfio-fixes/for-linus (db7d4d7f4021 vfio: Fix runaway interruptible timeout) Merging kselftest-fixes/fixes (ba155e2d21f6 Linux 4.1-rc5) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging drm-intel-fixes/for-linux-next-fixes (b953c0d234bc Linux 4.1) Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess
Re: [Intel-gfx] [Announcement] 2015-Q2 release of XenGT - a Mediated Graphics Passthrough Solution from Intel
Hi all, We're pleased to announce a public update to Intel Graphics Virtualization Technology(Intel GVT-g, formerly known as XenGT). Intel GVT-g is a full GPU virtualization solution with mediated pass-through, starting from 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Xen is currently supported on Intel Processor Graphics (a.k.a. XenGT); and the core logic can be easily ported to other hypervisors, for example, the experimental code has been released to support GVT-g running on a KVM hypervisor (a.k.a KVMGT). Tip of repositories - Kernel: 5b73653d5ca, Branch: master-2015Q2-3.18.0 Qemu: 2a75bbff62c1, Branch: master Xen: 38c36f0f511b1, Branch: master-2015Q2-4.5 This update consists of: - Change time based scheduler timer to be configurable to enhance stability - Fix stability issues that VM/Dom0 got tdr when hang up at some specific instruction on BDW - Optimize the emulation of el_status register to enhance stability - 2D/3D performance in linux VMs has been improved about 50% on BDW - Fix abnormal idle power consumption issue due to wrong forcewake policy - Fix tdr issue when running 2D/3D/Media workloads in Windows VMs simultaneously - KVM support is still in a separate branch as prototype work. We plan to integrate KVM/Xen support together in the future releases - Next update will be around early Oct, 2015 Notice that this release can support both Intel 4th generation Core CPU(code name: Haswell) and Intel 5th generation Core CPU (code name: Broadwell), while the limitation of the latter include: * 3D conformance may have some failure * Under high demand 3D workloads, stability issues are detected * Multi-monitor scenario is not fully tested, while single monitor of VGA/HDMI/DP/eDP should just work * Hotplug DP may cause black screen even on native environment Where to get kernel: https://github.com/01org/XenGT-Preview-kernel.git xen: https://github.com/01org/XenGT-Preview-xen.git qemu: https://github.com/01org/XenGT-Preview-qemu.git We have a mailing list for GVT-g development, bug report and technical discussion: https://lists.01.org/mailman/listinfo/igvt-g More information about Intel GVT-g background, architecture, etc can be found at: https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt Note: The XenGT project should be considered a work in progress. As such it is not a complete product nor should it be considered one. Extra care should be taken when testing and configuring a system to use the XenGT project. -- Thanks, Jike On 04/10/2015 09:23 PM, Jike Song wrote: Hi all, We're pleased to announce a public update to Intel Graphics Virtualization Technology (Intel GVT-g, formerly known as XenGT). Intel GVT-g is a complete vGPU solution with mediated pass-through, supported today on 4th generation Intel Core(TM) processors with Intel Graphics processors. A virtual GPU instance is maintained for each VM, with part of performance critical resources directly assigned. The capability of running native graphics driver inside a VM, without hypervisor intervention in performance critical paths, achieves a good balance among performance, feature, and sharing capability. Though we only support Xen on Intel Processor Graphics so far, the core logic can be easily ported to other hypervisors. Tip of repositories - Kernel: a011c9f953e, Branch: master-2015Q1-3.18.0 Qemu: 2a75bbff62c1, Branch: master Xen: 38c36f0f511b1, Branch: master-2015Q1-4.5 Summary this update - - Preliminary Broadwell support. - kernel update from drm-intel 3.17.0 to drm-intel 3.18.0(tag: drm-intel-next-fixes-2014-12-17, notice that i915 driver code is much newer than kernel stable version). - Next update will be around early July, 2015. - KVM support is still in a separate branch as prototype work. We plan to integrate KVM/Xen support together in future releases. This update consists of: - gvt-g core logic code was moved into i915 driver directory. - Host mediation is used for dom0 i915 driver access, instead of de-privileged dom0. - The Xen-specific code was separated from vgt core logic into a new file "driver/xen/xengt.c". - Broadwell is preliminarily supported in this release. Users could start multiple linux/windows 64-bit
Re: [PATCH] perf record: Allow passing perf's own pid to '--filter'
On 2015/7/6 23:40, Arnaldo Carvalho de Melo wrote: Em Mon, Jul 06, 2015 at 11:00:10PM +0800, pi3orama escreveu: 发自我的 iPhone 在 2015年7月6日，下午9:56，Arnaldo Carvalho de Melo 写道： I.e. having something in the filter expression that gets transformed into the tools' pid, I have no problem with that, just curious about what would be the best character to signal that a substitution needs to be performed, if it is really '@VAR', as my first selection would be '$VAR', $ has special meaning for shell. Using $ in cmdline require users use escaping or '' quoted string. Therefore I believe @ should be better. What do you think? Yeah, that gets in the way, as it gets in the way for '!', i.e. negating, and even tho, that is what is used in strace (and in 'perf trace'): strace -e \!open,write ls Or: strace -e '!open,write' ls But apart from that, it would be good if expressions used in 'perf probe' and here could have as much as possible the same semantics for those markers, i.e. 'perf probe' already uses @ for some stuff, probably the meaning is for "at", i.e. something at some place. '$' strongly associated with variables, so I don't think it would be a big problem to enclose expressions where variables (we may end having others, no?) in '', i.e. perf record -e sched:*switch --filter 'common_pid != $PERF_PID' -a Doesn't look so ugly or cumbersome :-) But what about user want to use real shell variables also? perf record -e raw_syscalls:* "common_pid !="'$PERF_PID'" && common_pid != $X_PID" Or perf record -e raw_syscalls:* "common_pid !=\$PERF_PID && common_pid != $X_PID" right? However, since you and Steven prefer '$' than '@' and '@' has its own meaning 'at' in 'perf probe', I'll use '$' in my next version. I looked your new code. You added perf_evsel__append_filter() to enable us append a filter expression in '(%s) (%s)' manner, and also perf_evlist__set_filter_pid() to add 'common_pid != %d' expression. They are nice scaffolds if we'd like to add a new cmdline option '--filter-pids' and '--filter-perf'. However, I think we should let users who use --filter take full control of their filters, instead of providing many helpers which can do similar things to confuse them. So I decide not to use those functions you added these days in my next version. Thank you. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: perf, kprobes: fuzzer generates huge number of WARNings
On 2015/07/07 6:27, Vince Weaver wrote: > Hello > > I've been working on trying to get the perf_fuzzer to start fuzzing the > PERF_EVENT_IOC_SET_BPF so I've added some really hackish kprobe support. > > However before I can get to the BPF testing the kprobe code generates a > constant stream of WARNINGS which make the machine more or less useless > until I stop it. I've included a small selection here. > > Is this expected? Did you get same message without BPF hack? And also, could you tell us your kernel version and configuration? > > Vince > > > [ 3521.350839] ftrace: Failed on adding breakpoints (6056): > [ 3521.357877] [ cut here ] > [ 3521.363007] WARNING: CPU: 1 PID: 5080 at kernel/trace/ftrace.c:1951 > ftrace_bug+0x245/0x320() > [ 3521.449830] CPU: 1 PID: 5080 Comm: perf_fuzzer Not tainted 4.2.0-rc1+ #168 > [ 3521.457543] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS > 01/26/2014 > [ 3521.465820] 81a28cf6 8800cd9f7b48 816a10a3 > > [ 3521.474274] 8800cd9f7b88 8106ec8a > 8800cd9f7b68 > [ 3521.482680] 880119bd7a80 81196730 880119bd7a80 > 17a8 > [ 3521.491143] Call Trace: > [ 3521.494128] [] dump_stack+0x45/0x57 > [ 3521.500016] [] warn_slowpath_common+0x8a/0xc0 > [ 3521.506810] [] ? vm_insert_mixed+0x40/0x40 > [ 3521.513389] [] warn_slowpath_null+0x1a/0x20 > [ 3521.520025] [] ftrace_bug+0x245/0x320 > [ 3521.526147] [] ftrace_replace_code+0x24c/0x360 > [ 3521.533102] [] ftrace_modify_all_code+0x9c/0x120 > [ 3521.540241] [] arch_ftrace_update_code+0x10/0x20 > [ 3521.547396] [] ftrace_run_update_code+0x20/0x80 > [ 3521.554425] [] ftrace_startup_enable+0x2f/0x40 > [ 3521.561376] [] ftrace_startup+0xd6/0x230 > [ 3521.567772] [] register_ftrace_function+0x54/0x70 > [ 3521.575025] [] perf_ftrace_event_register+0x47/0x140 > [ 3521.582537] [] perf_trace_init+0xc4/0x2c0 > [ 3521.589050] [] perf_tp_event_init+0x2a/0x50 > [ 3521.595771] [] perf_try_init_event+0x8b/0xa0 > [ 3521.602572] [] perf_init_event+0x133/0x160 > [ 3521.609181] [] ? perf_bp_event+0x90/0x90 > [ 3521.615647] [] perf_event_alloc+0x42a/0x680 > [ 3521.622388] [] SYSC_perf_event_open+0x3c7/0xd20 > [ 3521.629487] [] ? __do_page_fault+0x1ab/0x3f0 > [ 3521.636320] [] SyS_perf_event_open+0x9/0x10 > [ 3521.643087] [] entry_SYSCALL_64_fastpath+0x16/0x7a > [ 3521.650521] ---[ end trace a413501925547ed5 ]--- > [ 3521.655960] ftrace failed to modify [] > handle_mm_fault+0x0/0x1750 > [ 3521.664767] actual: e8:cb:18:ef:1e Hmm, this seems to happen when disarming kprobes from handle_mm_fault+0. However, with this easy test, I couldn't reproduce it on the latest tip/master. [root@localhost tracing]# echo p handle_mm_fault > kprobe_events [root@localhost tracing]# echo 1 > events/kprobes/p_handle_mm_fault_0/enable [root@localhost tracing]# echo 0 > events/kprobes/p_handle_mm_fault_0/enable We'd better know how to reproduce this issue. Thank you, > [ 3521.669202] ftrace record flags: ec02 > [ 3521.673993] (2) R tramp: 0xa009 expected tramp: > a009 > > > [ 3521.834024] [ cut here ] > [ 3521.839442] WARNING: CPU: 2 PID: 5177 at kernel/kprobes.c:955 > disarm_kprobe+0xf8/0x100() > [ 3521.848577] Failed to init kprobe-ftrace (-19) > [ 3521.931384] CPU: 2 PID: 5177 Comm: perf_fuzzer Tainted: GW > 4.2.0-rc1+ #168 > [ 3521.940498] Hardware name: LENOVO 10AM000AUS/SHARKBAY, BIOS FBKT72AUS > 01/26/2014 > [ 3521.948854] 81a28976 8800bf6d7a48 816a10a3 > > [ 3521.957335] 8800bf6d7a98 8800bf6d7a88 8106ec8a > 81124f6a > [ 3521.965839] 8800cd4e2010 8800cd4e2010 8800cd4e2000 > 8800cd28a000 > [ 3521.974275] Call Trace: > [ 3521.977335] [] dump_stack+0x45/0x57 > [ 3521.983302] [] warn_slowpath_common+0x8a/0xc0 > [ 3521.990170] [] ? unregister_ftrace_function+0x1a/0x50 > [ 3521.997784] [] warn_slowpath_fmt+0x46/0x50 > [ 3522.004418] [] ? mutex_unlock+0xe/0x10 > [ 3522.010640] [] disarm_kprobe+0xf8/0x100 > [ 3522.016972] [] __disable_kprobe+0x99/0xc0 > [ 3522.023491] [] disable_kprobe+0x27/0x50 > [ 3522.029827] [] disable_trace_kprobe+0xc3/0xf0 > [ 3522.036708] [] kprobe_register+0x2d/0xe0 > [ 3522.043102] [] perf_trace_event_unreg.isra.1+0x33/0x90 > [ 3522.050808] [] perf_trace_destroy+0x3c/0x50 > [ 3522.057482] [] tp_perf_event_destroy+0x9/0x10 > [ 3522.064354] [] _free_event+0xc1/0x250 > [ 3522.070474] [] ? put_event+0x2b/0x150 > [ 3522.076625] [] free_event+0x1f/0x50 > [ 3522.082531] [] perf_event_exit_task+0x245/0x300 > [ 3522.089575] [] do_exit+0x3b2/0xa90 > [ 3522.095444] [] ? get_signal+0xe2/0x720 > [ 3522.101659] [] do_group_exit+0x54/0xe0 > [ 3522.107892] [] get_signal+0x280/0x720 > [ 3522.114046] [] do_signal+0x28/0xb50 > [ 3522.119984] [] ? __lock_acquire.isra.31+0x3a6/0xf90 > [ 3522.127411] [] ? sys_getppid+0x5/
Re: [PATCH v2] add stealth mode
From: Matteo Croce Date: Mon, 6 Jul 2015 21:44:06 +0200 > 2015-07-06 12:49 GMT+02:00 : >> On Thu, 02 Jul 2015 10:56:01 +0200, Matteo Croce said: >>> Add option to disable any reply not related to a listening socket, >>> like RST/ACK for TCP and ICMP Port-Unreachable for UDP. >>> Also disables ICMP replies to echo request and timestamp. >>> The stealth mode can be enabled selectively for a single interface. >> >> A few notes. >> >> 1) Do you have an actual use case where an iptables '-j DROP' isn't usable? > > If you mean using a default DROP policy and allowing only the traffic > do you want, > then the use case is where the port can change at runtime and you may not want > to update the firewall every time Dynamically updated firewalls are "a thing" and quite effective for solving problems like this one. With nftables such updates are even extremely efficient. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] net: dsa: mv88e6xxx: add debugfs interface for VTU
> +static int _mv88e6xxx_vtu_getnext(struct dsa_switch *ds, u16 vid,
> + struct mv88e6xxx_vtu_entry *entry)
> +{
> + int ret, i;
> +
> + ret = _mv88e6xxx_vtu_wait(ds);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_VID,
> +vid & GLOBAL_VTU_VID_MASK);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_vtu_cmd(ds, GLOBAL_VTU_OP_VTU_GET_NEXT);
> + if (ret < 0)
> + return ret;
> +
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_VID);
> + if (ret < 0)
> + return ret;
> +
> + entry->vid = ret & GLOBAL_VTU_VID_MASK;
> + entry->valid = !!(ret & GLOBAL_VTU_VID_VALID);
> +
> + if (entry->valid) {
> + /* Ports 0-3, offsets 0, 4, 8, 12 */
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3);
> + if (ret < 0)
> + return ret;
> +
> + for (i = 0; i < 4; ++i)
> + entry->tags[i] = (ret >> (i * 4)) & 3;
> +
> + /* Ports 4-6, offsets 0, 4, 8 */
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_VTU_DATA_4_7);
> + if (ret < 0)
> + return ret;
> +
> + for (i = 4; i < 7; ++i)
> + entry->tags[i] = (ret >> ((i - 4) * 4)) & 3;
Hi Vivien
It looks like you still have up to 7 ports, rather than use
ps->num_ports. I have a ten port switch i would like to use VLANs with
:-)
> +
> + if (mv88e6xxx_6097_family(ds) || mv88e6xxx_6165_family(ds) ||
> + mv88e6xxx_6351_family(ds) || mv88e6xxx_6352_family(ds)) {
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
> + GLOBAL_VTU_FID);
> + if (ret < 0)
> + return ret;
> +
> + entry->fid = ret & GLOBAL_VTU_FID_MASK;
> +
> + ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL,
> + GLOBAL_VTU_SID);
> + if (ret < 0)
> + return ret;
> +
> + entry->sid = ret & GLOBAL_VTU_SID_MASK;
> + } else {
> + entry->fid = 0;
> + entry->sid = 0;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int _mv88e6xxx_vtu_loadpurge(struct dsa_switch *ds,
> + struct mv88e6xxx_vtu_entry *entry)
> +{
> + u16 data = 0;
> + int ret, i;
> +
> + ret = _mv88e6xxx_vtu_wait(ds);
> + if (ret < 0)
> + return ret;
> +
> + if (entry->valid) {
> + /* Set Data Register, ports 0-3, offsets 0, 4, 8, 12 */
> + for (data = i = 0; i < 4; ++i)
> + data |= entry->tags[i] << (i * 4);
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_0_3,
> +data);
> + if (ret < 0)
> + return ret;
> +
> + /* Set Data Register, ports 4-6, offsets 0, 4, 8 */
> + for (data = 0, i = 4; i < 7; ++i)
> + data |= entry->tags[i] << ((i - 4) * 4);
> + ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_VTU_DATA_4_7,
> +data);
Same again here.
Andrew
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] usb: dwc3: gadget: return error if command sent to DEPCMD register fails
On 7/1/2015 8:00 PM, Felipe Balbi wrote: > On Thu, Jul 02, 2015 at 02:03:14AM +, John Youn wrote: >> On 6/29/2015 2:48 PM, Felipe Balbi wrote: >>> Hi again, >>> >>> On Mon, Jun 29, 2015 at 04:47:01PM -0500, Felipe Balbi wrote: On Thu, May 21, 2015 at 03:46:48PM +0530, Subbaraya Sundeep Bhatta wrote: > We need to return error to caller if command is not sent to > controller succesfully. > > Signed-off-by: Subbaraya Sundeep Bhatta > Fixes: 72246da40f37 (usb: Introduce DesignWare USB3 DRD Driver) > Cc: > --- > v2 changes: > Added Fixes and Cc in commit message. I noticed that this breaks at least my AM437x silicon with DWC3 2.40a when used with g_zero and testusb. As of now, it could be that silicon is mis-behaving because I got a Transfer Complete before the failing Set Endpoint Transfer Resource command. In any case, can you run on your setup with g_zero and test.sh/testusb [1]/[2] just to verify that it really works for you ? Meanwhile, I'll continue testing on my end. cheers [1] https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:testusb.c [2] https://gitorious.org/usb/usb-tools/source/47ef073d9b6c0eae816204c81374aafb795c6e40:test.sh >>> >>> Adding John here. John, any chance you could fire up dwc3 on HAPS and >>> see wether it works or fails for you ? >>> >>> cheers >>> >> >> Hi Felipe, >> >> Just an update on this. >> >> I'm trying to get this working with our latest IP with dwc3 from your >> testing/next branch. It fails the usbtest with a problem unrelated to >> this patch. >> >> It passes on 4.1.1. >> >> I'll have to look into the failure but I won't get to it until next >> week as I'm off the rest of this week. > > interesting... If you could post failure signature, I can help looking > at it, but I guess it's too late to ask :-) > > thanks for helping though > Hi Felipe, Nevermind about my issue, it ended up being a setup-related problem. I actually do see the same error as you due to this series of patches. Except I see it happening before even the first iteration. I get a completion status of 1 for the Set Endpoint Transfer Resources command. I'm not sure why this is. I don't see any conflict with any previous Transfer Complete. I will have to consult with some hardware engineers tomorrow to look into it further. The trace is attached. John # tracer: nop # # entries-in-buffer/entries-written: 518/518 #P:8 # # _-=> irqs-off # / _=> need-resched #| / _---=> hardirq/softirq #|| / _--=> preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | -0 [000] d.h. 2443.493013: dwc3_readl: addr c9ea040c value 0008 -0 [000] d.h. 2443.493019: dwc3_readl: addr c9ea0408 value 0100 -0 [000] d.h. 2443.493020: dwc3_writel: addr c9ea0408 value 8100 -0 [003] d.h. 2443.493128: dwc3_readl: addr c9ea040c value 0008 -0 [003] d.h. 2443.493132: dwc3_readl: addr c9ea0408 value 8100 -0 [003] d.h. 2443.493133: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493186: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493188: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493189: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493192: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493194: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493195: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493198: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493200: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493201: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493204: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493206: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493207: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493210: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493212: dwc3_readl: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493213: dwc3_writel: addr c9ea0408 value 8100 -0 [003] dNh. 2443.493216: dwc3_readl: addr c9ea040c value 0008 -0 [003] dNh. 2443.493218: dwc3_readl: addr
