some kind of policy on setting this would
be nice. I personally think it's something that userspace should initiate via
an explicit
command.
Writing the NV for the AD5272 is something I planned to add at some stage.
But so far the default factory values have worked ok.
It'd be nice for cross device consistency for any interface for this.
--
Regards
Phil Reid
On Fri, Aug 09, 2019 at 06:21:22PM +0200 Dietmar Eggemann wrote:
> On 8/8/19 1:01 PM, tip-bot for Phil Auld wrote:
>
> [...]
>
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 19c58599e967..d9407517dae9 100644
> > --- a/kernel/sched/fair.c
On Tue, Aug 06, 2019 at 03:03:34PM +0200 Peter Zijlstra wrote:
> On Thu, Aug 01, 2019 at 09:37:49AM -0400, Phil Auld wrote:
> > Enabling WARN_DOUBLE_CLOCK in /sys/kernel/debug/sched_features causes
>
> ISTR there were more issues; but it sure is good to start picking them
> off
Commit-ID: 6b8fd01b21f5f2701b407a7118f236ba4c41226d
Gitweb: https://git.kernel.org/tip/6b8fd01b21f5f2701b407a7118f236ba4c41226d
Author: Phil Auld
AuthorDate: Thu, 1 Aug 2019 09:37:49 -0400
Committer: Peter Zijlstra
CommitDate: Thu, 8 Aug 2019 09:09:31 +0200
sched/fair: Use rq_lock
On Tue, Aug 06, 2019 at 10:41:25PM +0800 Aaron Lu wrote:
> On 2019/8/6 22:17, Phil Auld wrote:
> > On Tue, Aug 06, 2019 at 09:54:01PM +0800 Aaron Lu wrote:
> >> On Mon, Aug 05, 2019 at 04:09:15PM -0400, Phil Auld wrote:
> >>> Hi,
> >>>
> >&g
On Tue, Aug 06, 2019 at 09:54:01PM +0800 Aaron Lu wrote:
> On Mon, Aug 05, 2019 at 04:09:15PM -0400, Phil Auld wrote:
> > Hi,
> >
> > On Fri, Aug 02, 2019 at 11:37:15AM -0400 Julien Desfossez wrote:
> > > We tested both Aaron's and Tim's patches and here
On Tue, Aug 06, 2019 at 03:03:34PM +0200 Peter Zijlstra wrote:
> On Thu, Aug 01, 2019 at 09:37:49AM -0400, Phil Auld wrote:
> > Enabling WARN_DOUBLE_CLOCK in /sys/kernel/debug/sched_features causes
>
> ISTR there were more issues; but it sure is good to start picking them
> o
On Tue, Aug 06, 2019 at 02:04:16PM +0800 Hillf Danton wrote:
>
> On Mon, 5 Aug 2019 22:07:05 +0800 Phil Auld wrote:
> >
> > If we're to clear that flag right there, outside of the lock pinning code,
> > then I think we might as well just remove the flag and all as
31.06
> Tim's full patchset:679.43 70.07
> Tim's full patchset + sched:664.34 210.14
>
Sorry if I'm missing something obvious here but with only 2 processes
of interest shouldn't one tagged and one untagged be about the same
as both tagged?
On Fri, Aug 02, 2019 at 05:20:38PM +0800 Hillf Danton wrote:
>
> On Thu, 1 Aug 2019 09:37:49 -0400 Phil Auld wrote:
> >
> > Enabling WARN_DOUBLE_CLOCK in /sys/kernel/debug/sched_features causes
> > warning to fire in update_rq_clock. This seems to be caused by onlining
&g
e raw locking
removes this warning.
Signed-off-by: Phil Auld
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc: Vincent Guittot
---
Resend with PATCH instead of CHANGE in subject, and more recent upstream x86
backtrace.
kernel/sched/fair.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
G'day Stephen,
One comment below.
On 31/07/2019 22:32, Stephen Boyd wrote:
Quoting Phil Reid (2019-07-30 23:42:16)
G'day Stephen,
A comment unrelated to your change.
On 31/07/2019 02:15, Stephen Boyd wrote:
diff --git a/drivers/iio/adc/at91_adc.c b/drivers/iio/adc/at91_a
; 0)
return -ENODEV;
Should this be returning st->irq instead of -ENODEV?
eg: platform_get_irq can return -EPROBE_DEFER
Pattern is repeated in a number of other places.
- }
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
Regards
Phil Reid
On Fri, Jul 26, 2019 at 04:54:11PM +0200 Peter Zijlstra wrote:
> Make sure the entire for loop has stop_cpus_in_progress set.
>
> Cc: Valentin Schneider
> Cc: Aaron Lu
> Cc: keesc...@chromium.org
> Cc: mi...@kernel.org
> Cc: Pawan Gupta
> Cc: Phil Auld
> Cc: torva..
0/0x130
[ 612.546585] online_fair_sched_group+0x70/0x140
[ 612.551092] sched_online_group+0xd0/0xf0
[ 612.555082] sched_autogroup_create_attach+0xd0/0x198
[ 612.560108] sys_setsid+0x140/0x160
[ 612.563579] el0_svc_naked+0x44/0x48
Signed-off-by: Phil Auld
Cc: Peter Zijlstra
Cc: Ingo Molnar
Cc:
mit message and
hence was dropped during git-am. Thanks for the heads-up, Stephen!
Pablo, can we fix this somehow?
Sorry for the mess, Phil
Commit 425e0968a25fa3f111f9919964cac079738140b5 ("sched: move code into
kernel/sched_stats.h") appears to have inadvertently changed the unit of
time from jiffies to nanoseconds as part of the implementation of CFS.
Signed-off-by: Phil Frost
---
Documentation/scheduler/sched-stat
7 @@ static int vprbrd_gpiob_direction_input(struct gpio_chip
*chip,
}
static int vprbrd_gpiob_direction_output(struct gpio_chip *chip,
- unsigned offset, int value)
+ unsigned int offset, int value)
{
int ret;
struct vprbrd_gpio *gpio = gpiochip_get_data(chip);
--
Regards
Phil Reid
the FIFO because it is full, which would guarantee that
an interrupt is generated once the fill level drops below the half-way mark.
> I'm ok with a reaction like "I've thought about this, it's not a
> problem, now shut up".
I don't think that reaction would be justified - these things are difficult,
and having
many minds on the problem helps to avoid bugs like this.
Phil
Hi Dave,
Thanks for the reply.
On 12/07/2019 12:21, Dave Martin wrote:
> On Thu, Jul 11, 2019 at 02:45:32PM +0100, Phil Elwell wrote:
>> pl011_tx_chars takes a "from_irq" parameter to reduce the number of
>> register accesses. When from_irq is true the function assumes
pl011_tx_chars, causing polling to be used in the unsafe case.
Fixes: 1e84d22322ce ("serial/amba-pl011: Refactor and simplify TX FIFO
handling")
Signed-off-by: Phil Elwell
---
drivers/tty/serial/amba-pl011.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/driver
On 10/07/2019 18:21, Geert Uytterhoeven wrote:
Hi Phil,
On Wed, Jul 10, 2019 at 4:00 AM Phil Reid wrote:
On 6/07/2019 00:05, Geert Uytterhoeven wrote:
GPIO controllers are exported to userspace using /dev/gpiochip*
character devices. Access control to these devices is provided by
standard
st struct of_device_id em_gio_dt_ids[] = {
@@ -376,7 +376,6 @@ MODULE_DEVICE_TABLE(of, em_gio_dt_ids);
static struct platform_driver em_gio_device_driver = {
.probe = em_gio_probe,
- .remove = em_gio_remove,
.driver = {
.name = "em_gio",
.of_match_table = em_gio_dt_ids,
--
Regards
Phil Reid
d *data)
+{
+ struct gpio_virt_agg_entry *gva = p;
+
+ platform_device_unregister(gva->pdev);
+ kfree(gva);
+ return 0;
+}
+
+static void __exit gpio_virt_agg_exit(void)
+{
+ mutex_lock(&gpio_virt_agg_lock);
+ idr_for_each(&gpio_virt_agg_idr, gpio_virt_agg_idr_remove, NULL);
+ idr_destroy(&gpio_virt_agg_idr);
+ mutex_unlock(&gpio_virt_agg_lock);
+
+ platform_driver_unregister(&gpio_virt_agg_driver);
+}
+module_exit(gpio_virt_agg_exit);
+
+MODULE_AUTHOR("Geert Uytterhoeven ");
+MODULE_DESCRIPTION("GPIO Virtual Aggregator");
+MODULE_LICENSE("GPL v2");
--
Regards
Phil Reid
ElectroMagnetic Imaging Technology Pty Ltd
Development of Geophysical Instrumentation & Software
www.electromag.com.au
3 The Avenue, Midland WA 6056, AUSTRALIA
Ph: +61 8 9250 8100
Fax: +61 8 9250 7100
Email: pr...@electromag.com.au
the kernel just fine in cgroup v2. A user who wishes
> for the previous affinity mask to be restored in this fallback case can use
> that mechanism instead.
>
> This patch modifies scheduler behavior by instead resetting the mask to
> task_cs(tsk)->cpus_allowed by default, and cpu_pos
On Tue, Jun 11, 2019 at 04:24:43PM +0200 Peter Zijlstra wrote:
> On Tue, Jun 11, 2019 at 10:12:19AM -0400, Phil Auld wrote:
>
> > That looks reasonable to me.
> >
> > Out of curiosity, why not bool? Is sizeof bool architecture dependent?
>
> Yeah, sizeof(_Bool)
On Tue, Jun 11, 2019 at 03:53:25PM +0200 Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 10:21:01AM -0700, bseg...@google.com wrote:
> > diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
> > index efa686eeff26..60219acda94b 100644
> > --- a/kernel/sched/sched.h
> > +++ b/kernel/sched/sched.h
>
> booldistribute_running;
> + boolslack_started;
> #endif
> };
>
> --
> 2.22.0.rc1.257.g3120a18244-goog
>
I think this looks good. I like not delaying that further even if it
does not fix Dave's use case.
It does make it glaring that I should have used false/true for setting
distribute_running though :)
Acked-by: Phil Auld
--
Hi Frank,
On 04/06/2019 19:20, Frank Rowand wrote:
Hi Phil,
On 6/4/19 5:15 AM, Phil Elwell wrote:
Hi,
In the downstream Raspberry Pi kernel we are using configfs to apply overlays at
runtime, using a patchset from Pantelis that hasn't been accepted upstream yet.
Apart from the occas
to also back-port [2] to 4.19, but that leaves open the
question of
whether either the overlay application mechanism or the unit test framework
should have
detected the missing phandle.
Phil
[1] 8814dc46bd9e ("of: overlay: do not duplicate properties from overlay for
new nodes")
[2] f
Hi Geert,
On 03 June 2019 09:39 Geert Uytterhoeven wrote:
> On Mon, Jun 3, 2019 at 10:29 AM Phil Edworthy wrote:
> > On 28 May 2019 08:29 Geert Uytterhoeven wrote:
> > > On Fri, May 24, 2019 at 5:32 PM Gareth Williams wrote:
> > > > The driver is gaining power
io controller, i2c controller, gmac, dmac, Arasan sdio controller). The
commit to add this clock to the i2c controller driver is my fault, as I was
following the pattern of the others.
Of the few drivers that don't already get the hclk/pclk used to access the
peripherals is the Synopsys spi
On Fri, May 24, 2019 at 10:14:36AM -0500 Dave Chiluk wrote:
> On Fri, May 24, 2019 at 9:32 AM Phil Auld wrote:
> > On Thu, May 23, 2019 at 02:01:58PM -0700 Peter Oskolkov wrote:
>
> > > If the machine runs at/close to capacity, won't the overallocation
> >
06g032 clock driver.
>
> Signed-off-by: Gareth Williams
Your patch appears to be on top of some other work that is not in next
or elsewhere.
Please can you rebase it onto Geert's renesas-drivers branch
(kernel/git/geert/renesas-drivers.git).
Thanks
Phil
> ---
> drivers/clk/ren
}
> > + return next;
> > + }
> > +
>
> The following patch improved my test cases.
> Welcome any comments.
>
This is certainly better than violating the point of the core scheduler :)
If I'm understanding this right what will happe
10963.9 [18.5%/ 1.4%] -28.7% 100.0% |
> |256/25615990.8 [22.0%/ 2.2%] 100.0% | 12227.9 [10.3%/ 1.0%]
> -23.5% 73.2% | 10469.9 [19.6%/ 1.7%] -34.5% 100.0% |
> '--'
>
That's really nice and clear.
We start to see the penalty for the coresched at 32/32, leaving some cpus more
idle than otherwise.
But it's pretty good overall, for this benchmark at least.
Is this with stock v2 or with any of the fixes posted after? I wonder how much
the fixes for
the race that violates the rule effects this, for example.
Cheers,
Phil
> Thanks,
> -Aubrey
--
On Fri, Apr 26, 2019 at 04:13:07PM +0200 Peter Zijlstra wrote:
> On Thu, Apr 25, 2019 at 10:26:53AM -0400, Phil Auld wrote:
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index e8e5f26db052..b312ea1e28a4 100644
> > --- a/kernel/sched/core.c
> >
==
min q1 median q3 max
51.77 51.77 51.77 51.77 51.77
This a bit off topic, but since balancing bugs was mentioned and I've been
trying to track this down for a while (and learning the scheduler code in
the process) I figured I'd just throw it out there :)
Cheers,
Phil
--
takes the third arguement 'bool on_same_rq'?
>
Fwiw, I find the two names easier to read than a boolean flag. Could still
be wrapped to a single implementation I suppose.
An enum to control cpu or core would be more readable, but probably overkill...
Cheers,
Phil
> Thanks
--
ifdef CONFIG_SCHED_CORE
> + int tagged;
> +#endif
> +
> #ifdef CONFIG_FAIR_GROUP_SCHED
> /* schedulable entities of this group on each CPU */
> struct sched_entity **se;
> --
> 2.17.1
>
Since CPU0 never goes through the cpu
s statement?
This, to me, is the whole point of the patch series. If it's not
doing this then ... what?
Thanks,
Phil
> - A crash when disabling cpus with core-scheduling on
>- https://paste.debian.net/plainh/fa6bcfa8
>
> ---
>
> Peter Zijlstra (16):
> stop_mac
Hi Sasha,
On Tue, Apr 16, 2019 at 08:32:09AM -0700 tip-bot for Phil Auld wrote:
> Commit-ID: 2e8e19226398db8265a8e675fcc0118b9e80c9e8
> Gitweb:
> https://git.kernel.org/tip/2e8e19226398db8265a8e675fcc0118b9e80c9e8
> Author: Phil Auld
> AuthorDate: Tue, 19 Mar 2019
On Tue, Apr 09, 2019 at 03:05:27PM +0200 Peter Zijlstra wrote:
> On Tue, Apr 09, 2019 at 08:48:16AM -0400, Phil Auld wrote:
> > Hi Ingo, Peter,
> >
> > On Wed, Apr 03, 2019 at 01:38:39AM -0700 tip-bot for Phil Auld wrote:
> > > Commit-ID: 06ec5d30e8d57b820d44df6
Commit-ID: 2e8e19226398db8265a8e675fcc0118b9e80c9e8
Gitweb: https://git.kernel.org/tip/2e8e19226398db8265a8e675fcc0118b9e80c9e8
Author: Phil Auld
AuthorDate: Tue, 19 Mar 2019 09:00:05 -0400
Committer: Ingo Molnar
CommitDate: Tue, 16 Apr 2019 16:50:05 +0200
sched/fair: Limit
On Tue, Apr 09, 2019 at 03:05:27PM +0200 Peter Zijlstra wrote:
> On Tue, Apr 09, 2019 at 08:48:16AM -0400, Phil Auld wrote:
> > Hi Ingo, Peter,
> >
> > On Wed, Apr 03, 2019 at 01:38:39AM -0700 tip-bot for Phil Auld wrote:
> > > Commit-ID: 06ec5d30e8d57b820d44df6
sed if
> + * _every_ other avenue has been traveled.
> + **/
> +
> void cpuset_cpus_allowed_fallback(struct task_struct *tsk)
> {
> rcu_read_lock();
> - do_set_cpus_allowed(tsk, task_cs(tsk)->effective_cpus);
> + do_set_cpus_allowed(tsk, is_in_v2_mode() ?
> + task_cs(tsk)->cpus_allowed : cpu_possible_mask);
> rcu_read_unlock();
>
> /*
> --
> 2.18.1
>
Fwiw,
Acked-by: Phil Auld
--
On Tue, Apr 09, 2019 at 03:05:27PM +0200 Peter Zijlstra wrote:
> On Tue, Apr 09, 2019 at 08:48:16AM -0400, Phil Auld wrote:
> > Hi Ingo, Peter,
> >
> > On Wed, Apr 03, 2019 at 01:38:39AM -0700 tip-bot for Phil Auld wrote:
> > > Commit-ID: 06ec5d30e8d57b820d44df6
Hi Ingo, Peter,
On Wed, Apr 03, 2019 at 01:38:39AM -0700 tip-bot for Phil Auld wrote:
> Commit-ID: 06ec5d30e8d57b820d44df6340dcb25010d6d0fa
> Gitweb:
> https://git.kernel.org/tip/06ec5d30e8d57b820d44df6340dcb25010d6d0fa
> Author: Phil Auld
> AuthorDate: Tue, 19 Mar 2019
Commit-ID: 06ec5d30e8d57b820d44df6340dcb25010d6d0fa
Gitweb: https://git.kernel.org/tip/06ec5d30e8d57b820d44df6340dcb25010d6d0fa
Author: Phil Auld
AuthorDate: Tue, 19 Mar 2019 09:00:05 -0400
Committer: Ingo Molnar
CommitDate: Wed, 3 Apr 2019 09:50:23 +0200
sched/fair: Limit
On Thu, Mar 21, 2019 at 07:01:37PM +0100 Peter Zijlstra wrote:
> On Tue, Mar 19, 2019 at 09:00:05AM -0400, Phil Auld wrote:
> > sched/fair: Limit sched_cfs_period_timer loop to avoid hard lockup
> >
> > With extremely short cfs_period_us setting on a parent task group with a
is state and the new values.
v2: Math reworked/simplified by Peter Zijlstra.
Signed-off-by: Phil Auld
Cc: Ben Segall
Cc: Ingo Molnar
Cc: Peter Zijlstra (Intel)
Cc: Anton Blanchard
---
kernel/sched/fair.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/kernel/sc
On Mon, Mar 18, 2019 at 10:14:22AM -0700 bseg...@google.com wrote:
> Phil Auld writes:
>
> > On Fri, Mar 15, 2019 at 05:03:47PM +0100 Peter Zijlstra wrote:
> >> On Fri, Mar 15, 2019 at 11:30:42AM -0400, Phil Auld wrote:
> >>
> >> >> I'll rewor
On Fri, Mar 15, 2019 at 05:03:47PM +0100 Peter Zijlstra wrote:
> On Fri, Mar 15, 2019 at 11:30:42AM -0400, Phil Auld wrote:
>
> >> I'll rework the maths in the averaged version and post v2 if that makes
> >> sense.
> >
> > It may have the extra timer f
On Fri, Mar 15, 2019 at 04:59:33PM +0100 Peter Zijlstra wrote:
> On Fri, Mar 15, 2019 at 09:51:25AM -0400, Phil Auld wrote:
> > On Fri, Mar 15, 2019 at 11:33:57AM +0100 Peter Zijlstra wrote:
> > > On Fri, Mar 15, 2019 at 11:11:50AM +0100, Peter Zijlstra wrote:
> > >
On Fri, Mar 15, 2019 at 05:03:47PM +0100 Peter Zijlstra wrote:
> On Fri, Mar 15, 2019 at 11:30:42AM -0400, Phil Auld wrote:
>
> > In my defense here, all the fair.c imbalance pct code also uses 100 :)
>
> Yes, I know, I hate on that too ;-) Just never got around to fixing
>
On Fri, Mar 15, 2019 at 11:11:50AM +0100 Peter Zijlstra wrote:
> On Wed, Mar 13, 2019 at 11:08:26AM -0400, Phil Auld wrote:
...
> Computers _suck_ at /100. And since you're free to pick the constant,
> pick a power of two, computers love those.
>
> > +
> > +
edge case that this approach will make the problem go away. The only
alternative we
came up with to reduce the time taken in unthrottle involved a fair bit of
complexity
added to the every day code paths. And might not help if the children all had
their
own quota/period settings active.
Thou
On Fri, Mar 15, 2019 at 11:11:50AM +0100 Peter Zijlstra wrote:
> On Wed, Mar 13, 2019 at 11:08:26AM -0400, Phil Auld wrote:
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index 310d0637fe4b..90cc67bbf592 100644
> > --- a/kernel/sched/fair.c
> >
On Wed, Mar 13, 2019 at 01:26:51PM -0700 bseg...@google.com wrote:
> Phil Auld writes:
>
> > On Wed, Mar 13, 2019 at 10:44:09AM -0700 bseg...@google.com wrote:
> >> Phil Auld writes:
> >>
> >> > On Mon, Mar 11, 2019 at 04:25:36PM -0400 Phil Auld wr
On Wed, Mar 13, 2019 at 10:44:09AM -0700 bseg...@google.com wrote:
> Phil Auld writes:
>
> > On Mon, Mar 11, 2019 at 04:25:36PM -0400 Phil Auld wrote:
> >> On Mon, Mar 11, 2019 at 10:44:25AM -0700 bseg...@google.com wrote:
> >> > Letting it spin for 100ms and
as suggested by Ben Segall
.
Signed-off-by: Phil Auld
Cc: Ben Segall
Cc: Ingo Molnar
Cc: Peter Zijlstra (Intel)
---
Note: This is against v5.0 as suggested by the documentation. It won't apply to
5.0+ due to
the change to raw_spin_lock_irqsave. I can respin as needed.
kernel/
On Mon, Mar 11, 2019 at 04:25:36PM -0400 Phil Auld wrote:
> On Mon, Mar 11, 2019 at 10:44:25AM -0700 bseg...@google.com wrote:
> > Letting it spin for 100ms and then only increasing by 6% seems extremely
> > generous. If we went this route I'd probably say "after loo
On Mon, Mar 11, 2019 at 10:44:25AM -0700 bseg...@google.com wrote:
> Phil Auld writes:
>
> > On Wed, Mar 06, 2019 at 11:25:02AM -0800 bseg...@google.com wrote:
> >> Phil Auld writes:
> >>
> >> > On Tue, Mar 05, 2019 at 12:45:34PM -0800 bseg...@g
On Wed, Mar 06, 2019 at 11:25:02AM -0800 bseg...@google.com wrote:
> Phil Auld writes:
>
> > On Tue, Mar 05, 2019 at 12:45:34PM -0800 bseg...@google.com wrote:
> >> Phil Auld writes:
> >>
> >> > Interestingly, if I limit the number of child cgroups
On Tue, Mar 05, 2019 at 12:45:34PM -0800 bseg...@google.com wrote:
> Phil Auld writes:
>
> > Interestingly, if I limit the number of child cgroups to the number of
> > them I'm actually putting processes into (16 down from 2500) the problem
> > does not r
On Tue, Mar 05, 2019 at 10:49:01AM -0800 bseg...@google.com wrote:
> Phil Auld writes:
>
> >> >
> >> > raw_spin_lock(&cfs_b->lock);
> >> > for (;;) {
> >> > overrun = hrtimer_forward_now(timer, cfs_b->peri
On Mon, Mar 04, 2019 at 10:13:49AM -0800 bseg...@google.com wrote:
> Phil Auld writes:
>
> > Hi,
> >
> > I have a reproducible case of this:
> >
> > [ 217.264946] NMI watchdog: Watchdog detected hard LOCKUP on cpu 24
> > [ 217.264948] M
iod_timer never takes longer
than period
would be good but I'm not sure what that would be and we still have this
potential forever
loop.
Below is the bandaid version.
Thoughts?
Cheers,
Phil
---
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 310d0637fe4b..33e556
Hi Marc,
On 20 February 2019 11:33 Phil Edworthy wrote:
> On 20 February 2019 10:05 Marc Zyngier wrote:
> > On Wed, 20 Feb 2019 09:07:02 +0000, Phil Edworthy wrote:
> > > On 19 February 2019 20:29 Marc Zyngier wrote:
> >
> > [...]
> >
> > > &
Hi Marc,
On 20 February 2019 10:05 Marc Zyngier wrote:
> On Wed, 20 Feb 2019 09:07:02 +0000, Phil Edworthy wrote:
> > On 19 February 2019 20:29 Marc Zyngier wrote:
>
> [...]
>
> > > > + for (i = 0; i < MAX_NR_INPUT_IRQS; i++)
> > > > +
Hi Marc
On 19 February 2019 20:29 Marc Zyngier wrote:
> On Tue, 19 Feb 2019 15:55:11 +0000 Phil Edworthy wrote:
>
> + LinusW, who seem to have taken an interest in irqchip hierarchies...
>
> > On RZ/N1 devices, there are 3 Synopsys DesignWare GPIO blocks each
> > configu
On Tue, Feb 19, 2019 at 05:22:50PM +0100 Peter Zijlstra wrote:
> On Tue, Feb 19, 2019 at 11:13:43AM -0500, Phil Auld wrote:
> > On Mon, Feb 18, 2019 at 05:56:23PM +0100 Peter Zijlstra wrote:
> > > In preparation of playing games with rq->lock, abstract the thing
&g
ome branch on tip, I guess?
Thanks,
Phil
> ---
> kernel/sched/core.c | 44 ++--
> kernel/sched/deadline.c | 18
> kernel/sched/debug.c|4 -
> kernel/sched/fair.c | 41 +--
> kernel/sched/idle.c |4 -
>
. It's likely that the firmware will use some of these GPIO
interrupts and so we don't want them to move around.
Signed-off-by: Phil Edworthy
---
v4:
- Fix DT binding nits
v3:
- Use 'interrupt-map' DT property to map the interrupts, this is very similar
to PCIe MSI. The only d
d, so there is nothing to do in this driver when an interrupt
is received, other than tell the corresponding GPIO block.
Signed-off-by: Phil Edworthy
---
v4:
- No change.
v3:
- Use 'interrupt-map' DT property to map the interrupts, this is very similar
to PCIe MSI. The only differ
Hi Marc,
> On Tue, 19 Feb 2019 15:27:25 +
> Phil Edworthy wrote:
>
> > Hello,
> >
> > Any comments on this patch?
>
> Err... I'm afraid it fell through the cracks. It's been three months, and I've
> paged out most of last year.
>
>
Hello,
Any comments on this patch?
Thanks
Phil
> -Original Message-
> From: Phil Edworthy
> Sent: 13 November 2018 13:09
> To: Marc Zyngier ; Thomas Gleixner
> ; Jason Cooper
> Cc: Geert Uytterhoeven ; linux-renesas-
> s...@vger.kernel.org; linux-kernel@vger.kern
Hi Stefan,
On 29/01/2019 09:44, Stefan Wahren wrote:
> Hi Phil,
>
> Am 29.01.2019 um 10:10 schrieb Phil Elwell:
>> "cat /sys/kernel/debug/bcm2835_thermal/regset" causes a NULL pointer
>> dereference in bcm2835_thermal_debugfs. The driver makes use of the
>>
Hi Daniel,
On 29/01/2019 09:52, Daniel Lezcano wrote:
> On 29/01/2019 10:10, Phil Elwell wrote:
>> "cat /sys/kernel/debug/bcm2835_thermal/regset" causes a NULL pointer
>> dereference in bcm2835_thermal_debugfs. The driver makes use of the
>> implementation deta
ing to the crash. Instead, store its private data as the
drvdata and retrieve the thermal_zone_device pointer from it.
Fixes: bcb7dd9ef206 ("thermal: bcm2835: add thermal driver for bcm2835 SoC")
Signed-off-by: Phil Elwell
---
drivers/thermal/broadcom/bcm2835_thermal.c | 9
ing to the crash. Instead, store its private data as the
drvdata and retrieve the thermal_zone_device pointer from it.
Fixes: bcb7dd9ef206 ("thermal: bcm2835: add thermal driver for bcm2835 SoC")
Signed-off-by: Phil Elwell
---
drivers/thermal/broadcom/bcm2835_thermal.c | 9
Hi,
Any other comments on this patch and patch 2/2
(https://lkml.org/lkml/2018/12/3/326)?
Thanks
Phil
> -Original Message-
> From: Phil Edworthy
> Sent: 06 December 2018 12:31
> To: 'Andy Shevchenko'
> Cc: Michael Turquette ; Stephen Boyd
> ; Russell King
and since the armed flag was being
cleared this lead to a deadlock.
Fixes: 852b2876a8a8 ("staging: vchiq: rework remove_event handling")
Signed-off-by: Phil Elwell
---
drivers/staging/vc04_services/interface/vchiq_arm/vchiq_core.c | 1 +
1 file changed, 1 insertion(+)
diff --g
s is part of a longer, untested, series to remove semaphores
> > from the kernel, please review as such before applying.
> > ---
> > lib/test_rhashtable.c | 28
> > 1 file changed, 16 insertions(+), 12 deletions(-)
>
> This was created
nk we
should just
use one regulator vdd, then it will be much easier for the driver, what do you
think?
Yes I think that makes sense.
--
Regards
Phil
G'day Anson,
Just pulled up the datasheet for this chip.
The absolute max for Vdda is speced as Vddd +/-0.5
With a note that Vdda should be externally shorted to Vddd.
On 11/12/2018 11:43 am, Anson Huang wrote:
Hi, Phil
Best Regards!
Anson Huang
-Original Message-
From: Phil
ev, indio_dev);
+ err = devm_iio_device_register(&client->dev, indio_dev);
+ if (!err)
+ return 0;
+
+disable_regulators:
+ if (!IS_ERR(chip->vdd_reg))
+ regulator_disable(chip->vdd_reg);
+ if (!IS_ERR(chip->vdda_reg))
+ regulator_disable(chip->vdda_reg);
+
+ return err;
}
[snip]
--
Regards
Phil
EFER;
+ }
+
IANAE, but normally the return pattern for devm_regulator_get_optional
if (!IS_ERR(reg)) {
regulator_enable ...
} else {
ret = PTR_ERR(reg);
if (ret != -ENODEV)
return ret;
}
--
Regards
Phil
Hi Andy,
On 03 December 2018 13:31 Andy Shevchenko wrote:
> On Mon, Dec 03, 2018 at 11:13:08AM +0000, Phil Edworthy wrote:
> > It's not immediately obvious from the code that failure to get a clock
> > provider can return either -ENOENT or -EINVAL. Therefore, add a
> >
t's a function.
- Add kernel doc for clk_get_optional().
Phil Edworthy (2):
clk: Add comment about __of_clk_get_by_name() error values
clk: Add (devm_)clk_get_optional() functions
drivers/clk/clk-devres.c | 11 +++
drivers/clk/clkdev.c | 6 ++
include/linux/clk.h
It's not immediately obvious from the code that failure to get a
clock provider can return either -ENOENT or -EINVAL. Therefore, add
a comment to highlight this.
Signed-off-by: Phil Edworthy
---
drivers/clk/clkdev.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/clk/clk
clk_prepare_enable, etc to be called on the returned reference
without additional checks.
Signed-off-by: Phil Edworthy
Reviewed-by: Andy Shevchenko
---
v9:
- Add brackets after devm_clk_get so people know it's a function.
- Add kernel doc for clk_get_optional().
v8:
- Remove else clause
v7:
- In
Hi Stephen,
On 30 November 2018 09:09 Stephen Boyd wrote:
> Quoting Phil Edworthy (2018-11-20 06:14:45)
> > This adds clk_get_optional() and devm_clk_get_optional() functions to
> > get optional clocks.
> > They behave the same as (devm_)clk_get except where there is no c
interrupt-controller"
Signed-off-by: Phil Edworthy
---
arch/arm64/boot/dts/al/alpine-v2.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/al/alpine-v2.dtsi
b/arch/arm64/boot/dts/al/alpine-v2.dtsi
index 5b7bef684256..6f35bab10e9d 100644
--- a/arch
interrupt-controller"
Signed-off-by: Phil Edworthy
---
arch/arm/boot/dts/alpine.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/alpine.dtsi b/arch/arm/boot/dts/alpine.dtsi
index 731df7a8c4e6..533c876497ff 100644
--- a/arch/arm/boot/dts/alpine.dtsi
interrupt-controller"
Signed-off-by: Phil Edworthy
---
arch/arm/boot/dts/ox820.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/ox820.dtsi b/arch/arm/boot/dts/ox820.dtsi
index 085bbd33eadc..3a17ab4e7c2f 100644
--- a/arch/arm/boot/dts/ox820.dtsi
+++
Hi Geert,
On 23 November 2018 09:41 Geert Uytterhoeven wrote:
> Subject: Re: [PATCH] pinctrl: rzn1: Fix check for used MDIO bus
> On Mon, Nov 19, 2018 at 5:18 PM Phil Edworthy wrote:
> > This fixes the check for unused mdio bus setting and the following
> > static checker war
Hi Simon,
On 22 November 2018 14:09 Simon Horman wrote:
> On Mon, Nov 19, 2018 at 04:18:38PM +0000, Phil Edworthy wrote:
> > This fixes the check for unused mdio bus setting and the following
> > static checker warning:
> > drivers/pinctrl/pinctrl-rzn1.c:198 rzn1_pinctrl_md
clk_prepare_enable, etc to be called on the returned reference
without additional checks.
Signed-off-by: Phil Edworthy
Reviewed-by: Andy Shevchenko
---
v8:
- Remove else clause
v7:
- Instead of messing with the core functions, simply wrap them for the
_optional() versions. By putting clk_get_optional
The sub-nodes should not be called gpio-controller, but simply gpio.
Signed-off-by: Phil Edworthy
---
Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpio/snps-dwapb-gpio.txt
b
101 - 200 of 728 matches
Mail list logo
