Both USB Host (pci0) and Function (USBHS) drivers are enabled.
The USB PHY driver determines which IP block should be connected
based on vbus and id signals read via gpios.
Note that switch SW5 and SW6 on Koelsch board needs to be set to
position 3 for this to work.
---
Not for upstream until th
Hi Laurent,
On 02 July 2015 09:15, Laurent wrote:
> Hi Phil,
>
> (CC'ing Morimoto-san)
>
> Thank you for the patch.
>
> On Thursday 02 July 2015 08:36:42 Phil Edworthy wrote:
> > These changes allow a PHY driver to trigger a VBUS interrupt and
> > to pro
These changes allow a PHY driver to trigger a VBUS interrupt and
to provide the value of VBUS.
Signed-off-by: Phil Edworthy
---
v3:
- Changed how indirect vbus is plumbed in.
- Removed unnecessary (void) on call to otg_set_peripheral.
- Moved code that connects to bus through transceiver
Hi Sergei,
On 02 July 2015 12:17, Sergei wrote:
> To: Phil Edworthy; Yoshihiro Shimoda
> Hello.
>
> On 7/2/2015 10:36 AM, Phil Edworthy wrote:
>
> > These changes allow a PHY driver to trigger a VBUS interrupt and
> > to provide the value of VBUS.
>
&g
Hi Sergei.
On 02 July 2015 12:32, Sergei wrote:
> Hello.
>
> On 7/2/2015 11:14 AM, Phil Edworthy wrote:
>
> > Both USB Host (pci0) and Function (USBHS) drivers are enabled.
> > The USB PHY driver determines which IP block should be connected
> > based on vbus
Hi Kishon,
On 02 July 2015 09:22, Kishon wrote:
> Hi,
>
> On Monday 22 June 2015 08:12 PM, Phil Edworthy wrote:
> > Instead of statically selecting the PHY connection to either the
> > USBHS (Function) or PCI0 (Host) IP blocks, this change allows the
> > dts to spec
Hi Wolfram,
On 07 November 2015 14:00, Wolfram wrote:
> On Tue, Nov 03, 2015 at 09:28:19AM +0000, Phil Edworthy wrote:
> > The OF node passed to irq_domain_add_linear() should be a
> > pointer to interrupt controller's device tree node, or NULL,
> > but not the PCI contr
Hi Wolfram,
On 07 November 2015 13:29, Wolfram wrote:
> On Mon, Nov 02, 2015 at 04:36:13PM +0000, Phil Edworthy wrote:
> > The main purpose of this change is to avoid calling pci_ioremap_io() as
> > this is not available on arm64. However, instead of doing the range passing
> &
"PCI: generic: Convert to DT resource parsing API".
Signed-off-by: Phil Edworthy
---
v2:
- Remove incorrect res_valid check
---
drivers/pci/host/pcie-rcar.c | 116 +++
1 file changed, 73 insertions(+), 43 deletions(-)
diff --git a/drivers/pci
Hi Liviu, Will,
On 04 November 2015 15:19, Phil wrote:
> On 04 November 2015 15:02, Liviu wrote:
> > On Wed, Nov 04, 2015 at 02:48:38PM +0000, Phil Edworthy wrote:
> > > Hi Liviu,
> > >
> > > On 04 November 2015 14:24, Liviu wrote:
> > > > On Wed,
cc'ing others (Tegra, Altera, Designware) who may have the same bug
On 03 November 2015 09:28, Phil Edworthy wrote:
> The OF node passed to irq_domain_add_linear() should be a
> pointer to interrupt controller's device tree node, or NULL,
> but not the PCI controller's
Hi Thierry,
On 09 November 2015 16:11, Thierry wrote:
> On Mon, Nov 09, 2015 at 03:20:24PM +0000, Phil Edworthy wrote:
> > cc'ing others (Tegra, Altera, Designware) who may have the same bug
> >
> > On 03 November 2015 09:28, Phil Edworthy wrote:
> > > The OF n
Hi Thierry,
On 09 November 2015 17:24, Phil wrote:
> On 09 November 2015 16:11, Thierry wrote:
> > On Mon, Nov 09, 2015 at 03:20:24PM +0000, Phil Edworthy wrote:
> > > cc'ing others (Tegra, Altera, Designware) who may have the same bug
> > >
> > > On 03
ller")
> > d8a1cb757550 ("PCI/MSI: Let pci_msi_get_domain use struct
> device::msi_domain")
>
> Does that solve the MSI problems you mentioned?
It avoids the problem, but I have a proper fix in the pipeline which just needs
more testing.
Thanks
Phil
--
To unsubscr
The OF node passed to irq_domain_add_linear() should be a
pointer to interrupt controller's device tree node, or NULL,
but not the PCI controller's node.
This fixes an oops in msi_domain_alloc_irqs() when it tries
to call msi_check().
Signed-off-by: Phil Edworthy
---
drivers/pci
If the dtb specifies dma-ranges, we use those values. Otherwise, we
default to the values that were previously hardcoded into the driver.
Signed-off-by: Phil Edworthy
---
.../devicetree/bindings/pci/pci-rcar-gen2.txt | 6 ++
drivers/pci/host/pci-rcar-gen2.c | 76
oller driver uses the iommu_ops
version of dma_ops.
However, I can't see how to make the endpoints to utilise the dma_ops that
the controller uses. Shouldn't the endpoints inherit the dma_ops from the
controller? Any pointers for this?
Thanks
Phil
--
To unsubscribe from this list
Hi Liviu,
On 04 November 2015 14:24, Liviu wrote:
> On Wed, Nov 04, 2015 at 01:57:48PM +0000, Phil Edworthy wrote:
> > Hi,
> >
> > I am trying to hook up a PCIe host controller that sits behind an IOMMU,
> > but having some problems.
> >
> > I'm usi
Hi Liviu,
On 04 November 2015 15:02, Liviu wrote:
> On Wed, Nov 04, 2015 at 02:48:38PM +0000, Phil Edworthy wrote:
> > Hi Liviu,
> >
> > On 04 November 2015 14:24, Liviu wrote:
> > > On Wed, Nov 04, 2015 at 01:57:48PM +, Phil Edworthy wrote:
> > > >
Hi Will,
On 04 November 2015 15:30, Will wrote:
> On Wed, Nov 04, 2015 at 03:19:13PM +0000, Phil Edworthy wrote:
> > On 04 November 2015 15:02, Liviu wrote:
> > > On Wed, Nov 04, 2015 at 02:48:38PM +, Phil Edworthy wrote:
> > > > Sure, though since this is bo
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 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
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 Wed, Aug 28, 2019 at 06:01:14PM +0200 Peter Zijlstra wrote:
> On Wed, Aug 28, 2019 at 11:30:34AM -0400, Phil Auld wrote:
> > On Tue, Aug 27, 2019 at 11:50:35PM +0200 Peter Zijlstra wrote:
>
> > > And given MDS, I'm still not entirely convinced it all makes sense.
wrong
group in find_busiest_group due to using the average load. The second was in
fix_small_imbalance(). The "load" of the lu.C tasks was so low it often failed
to move anything even when it did find a group that was overloaded (nr_running
> width). I have two small patches which fix this but since Vincent was
> embarking
on a re-work which also addressed this I dropped them.
We've also run a series of performance tests we use to check for regressions
and
did not find any bad results on our workloads and systems.
So...
Tested-by: Phil Auld
Cheers,
Phil
--
f_node;
+ indio_dev->dev.of_node = np;
if (id->driver_data == ina226) {
indio_dev->channels = ina226_channels;
indio_dev->num_channels = ARRAY_SIZE(ina226_channels);
--
Regards
Phil Reid
ElectroMagnetic Imaging Technology Pty Ltd
Develop
ndio_dev->setup_ops = &ina2xx_setup_ops;
buffer = devm_iio_kfifo_allocate(&indio_dev->dev);
--
Regards
Phil Reid
->dev);
I like this personally. It'd be nice if it was a core function so
it could be an opt in to any iio device.
Don't know how well received that'd be thou.
--
Regards
Phil Reid
On 19/08/2019 03:32, Jonathan Cameron wrote:
On Mon, 12 Aug 2019 19:08:12 +0800
Phil Reid wrote:
G'day Martin / Jonathan,
On 12/08/2019 18:37, Martin Kaiser wrote:
Hi Jonathan,
Thus wrote Jonathan Cameron (ji...@kernel.org):
The patch is fine, but I'm wondering about wheth
On Fri, Aug 09, 2019 at 06:43:09PM +0100 Valentin Schneider wrote:
> On 09/08/2019 14:33, Phil Auld wrote:
> > 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_DOU
er does:
raw_spin_lock(&rq->lock);
update_rq_clock(rq);
which triggers the warning because of not using the rq_lock wrappers.
So, use the wrappers.
Signed-off-by: Phil Auld
Cc: Peter Zijlstra (Intel)
Cc: Ingo Molnar
Cc: Valentin Schneider
Cc: Dietmar Eggemann
---
urn -EINVAL.
> This peculiarity is documented by commit 5c56dfe63b6e ("clk: Add comment
> about __of_clk_get_by_name() error values").
>
> Let's further document this function so that it's clear what the return
> value is and how to use the arguments to parse
error = PAC_RESET_KEYS(me, arg2);
> > break;
> > + case PR_CORE_ISOLATE:
> > +#ifdef CONFIG_SCHED_CORE
> > + current->core_cookie = (unsigned long)current;
>
> This needs to then also force a reschedule of current. And there&#x
ure overrun, and
> > WARN on any overruns? We wouldn't expect overruns, but their
> > existence would indicate an over-loaded node or too short of a
> > cfs_period. Additionally, it would be interesting to see if we could
> > capture the offset between when the bandwidth was refilled, and when
> > the timer was supposed to fire. I've always done all my calculations
> > assuming that the timer fires and is handled exceedingly close to the
> > time it was supposed to fire. Although, if the node is running that
> > overloaded you probably have many more problems than worrying about
> > timer warnings.
>
> That "overrun" there is not really an overrun - it's the number of
> complete periods the timer has been inactive for. It was used so that a
> given tg's period timer would keep the same
> phase/offset/whatever-you-call-it, even if it goes idle for a while,
> rather than having the next period start N ms after a task wakes up.
>
> Also, poor choices by userspace is not generally something the kernel
> generally WARNs on, as I understand it.
I don't think it matters in the start_cfs_bandwidth case, anyway. We do
effectively check in sched_cfs_period_timer.
Cleanup looks okay to me as well.
Cheers,
Phil
--
On 26/08/2019 02:07, Jonathan Cameron wrote:
On Wed, 21 Aug 2019 11:12:00 +0200
Michal Simek wrote:
On 21. 08. 19 4:11, Phil Reid wrote:
On 20/08/2019 22:11, Michal Simek wrote:
Add support for using label property for easier device identification via
iio framework.
Signed-off-by: Michal
max_cfs_quota_period/2 and max_cfs_quota_period that would get us out of
the loop. Possibly in practice it won't matter but here you trigger the
warning and take no action to keep it from continuing.
Also, if you are actually hitting this then you might want to just start at
a higher but propo
17.32 19.37 23.92 21.08
There is high variance so it may not be anythign specific between v1 and v3
here.
The initial fixes I made for this issue did not exhibit this behavior. They
would have had other issues dealing with overload cases though. In this case
however there are only 154 or
On Tue, Oct 08, 2019 at 05:53:11PM +0200 Vincent Guittot wrote:
> Hi Phil,
>
...
> While preparing v4, I have noticed that I have probably oversimplified
> the end of find_idlest_group() in patch "sched/fair: optimize
> find_idlest_group" when it compares local
On Thu, Oct 03, 2019 at 07:05:56PM -0700 Xuewei Zhang wrote:
> +cc neeln...@google.com and hao...@google.com, they helped a lot
> for this issue. Sorry I forgot to include them when sending out the patch.
>
> On Thu, Oct 3, 2019 at 5:55 PM Phil Auld wrote:
> >
> > Hi
Hi Xuewei,
On Fri, Oct 04, 2019 at 05:28:15PM -0700 Xuewei Zhang wrote:
> On Fri, Oct 4, 2019 at 6:14 AM Phil Auld wrote:
> >
> > On Thu, Oct 03, 2019 at 07:05:56PM -0700 Xuewei Zhang wrote:
> > > +cc neeln...@google.com and hao...@google.com, they helped a lot
>
20, cfs_quota_us = 3200)
[ 1393.965140] cfs_period_timer[cpu11]: period too short, but cannot scale up
without losing precision (cfs_period_us = 20, cfs_quota_us = 3200)
I suspect going higher could cause the original lockup, but that'd be the case
with the old code as well.
An
ev, "Not using confd gpio");
}
/* Register manager with unique name */
Best regards,
Pavel
--
Regards
Phil Reid
find_idlest_group
> > >
> > > kernel/sched/fair.c | 1181
> > > +--
> > > 1 file changed, 682 insertions(+), 499 deletions(-)
> >
> > Thanks, that's an excellent series!
> >
> > I've queued it up
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 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.
>
>
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
. 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
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 -
>
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
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
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++)
> > > > +
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 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
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,
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
}
> > + 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
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
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
> >
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
==
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
--
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
> >
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
--
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
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
On Mon, Aug 12, 2019 at 05:52:04AM -0700 tip-bot for Phil Auld wrote:
> Commit-ID: a46d14eca7b75fffe35603aa8b81df654353d80f
> Gitweb:
> https://git.kernel.org/tip/a46d14eca7b75fffe35603aa8b81df654353d80f
> Author: Phil Auld
> AuthorDate: Thu, 1 Aug 2019 09:37:49 -0
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
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
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
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
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(-)
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
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:
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
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 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
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)
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 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 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 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
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
>
> 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
--
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
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)
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
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
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
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
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 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 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
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:
> >
> > [...]
> >
> > > &
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
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
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 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
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
between the interrupt handler and access to the
Enhanced Features Register.
Phil Elwell (2):
sc16is7xx: Fix for multi-channel stall
sc16is7xx: Fix for "Unexpected interrupt: 8"
drivers/tty/serial/sc16is7xx.c | 50 +-
1 file changed, 44 insert
em (or at least make it much less likely to happen)
by reducing the granularity of per-channel interrupt processing
to one condition per iteration, only exiting the overall loop when
both channels are no longer interrupting.
Signed-off-by: Phil Elwell
---
drivers/tty/serial/s
401 - 500 of 731 matches
Mail list logo
