AXP813 and AXP803 PMICs can control input current and minimum voltage.
Both of these values are configurable.
Signed-off-by: Oskari Lemmela
Reviewed-by: Quentin Schulz
Reviewed-by: Chen-Yu Tsai
Acked-by: Lee Jones
---
drivers/power/supply/axp20x_ac_power.c | 94 ++
AXP813 and AXP803 PMICs can control input current and minimum voltage.
Both of these values are configurable.
Signed-off-by: Oskari Lemmela
Reviewed-by: Quentin Schulz
Reviewed-by: Chen-Yu Tsai
Acked-by: Lee Jones
---
drivers/power/supply/axp20x_ac_power.c | 94 ++
As axp20x-ac-power-supply now supports AXP813, add a cell for it.
Signed-off-by: Oskari Lemmela
Reviewed-by: Quentin Schulz
Reviewed-by: Chen-Yu Tsai
Tested-by: Vasily Khoruzhick
---
drivers/mfd/axp20x.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mfd/axp20x.c
As axp20x-ac-power-supply now supports AXP813, add a cell for it.
Signed-off-by: Oskari Lemmela
Reviewed-by: Quentin Schulz
Reviewed-by: Chen-Yu Tsai
Tested-by: Vasily Khoruzhick
---
drivers/mfd/axp20x.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mfd/axp20x.c
AXP803 ACIN pins are routed from SOM to the DC jack on the baseboard.
AXP803 charger pins BATSENSE, LOADSENSE, N_BATDRV, LX_CHG, VIN_CHG
and IPSOUT are connected via PMOS driver to SOM VBAT pins. VBAT and
AXP803 TS pins are routed to the baseboard 3-pin battery connector.
Signed-off-by: Oskari
The cgroup-v2.rst file is updated to document the new bypass mode.
Signed-off-by: Waiman Long
---
Documentation/admin-guide/cgroup-v2.rst | 66 -
1 file changed, 48 insertions(+), 18 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
Parts of the AXP803 are compatible with their counterparts on the AXP813.
These include the GPIO, ADC, AC and battery power supplies.
Signed-off-by: Oskari Lemmela
Reviewed-by: Chen-Yu Tsai
Tested-by: Vasily Khoruzhick
---
drivers/mfd/axp20x.c | 15 +++
1 file changed, 15
AXP803 ACIN pins are routed from SOM to the DC jack on the baseboard.
AXP803 charger pins BATSENSE, LOADSENSE, N_BATDRV, LX_CHG, VIN_CHG
and IPSOUT are connected via PMOS driver to SOM VBAT pins. VBAT and
AXP803 TS pins are routed to the baseboard 3-pin battery connector.
Signed-off-by: Oskari
The cgroup-v2.rst file is updated to document the new bypass mode.
Signed-off-by: Waiman Long
---
Documentation/admin-guide/cgroup-v2.rst | 66 -
1 file changed, 48 insertions(+), 18 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
Parts of the AXP803 are compatible with their counterparts on the AXP813.
These include the GPIO, ADC, AC and battery power supplies.
Signed-off-by: Oskari Lemmela
Reviewed-by: Chen-Yu Tsai
Tested-by: Vasily Khoruzhick
---
drivers/mfd/axp20x.c | 15 +++
1 file changed, 15
AXP813 AC power supply support with input current and
voltage limiting support.
AXP803 AC and battery power supply support.
Changes in v6:
* Collected tags
* Rebase to master
* Dropped AXP803 compatible patches
Changes in v5:
* Return correct input current limit for values 0x6 and 0x7
* Add
AXP813 AC power supply support with input current and
voltage limiting support.
AXP803 AC and battery power supply support.
Changes in v6:
* Collected tags
* Rebase to master
* Dropped AXP803 compatible patches
Changes in v5:
* Return correct input current limit for values 0x6 and 0x7
* Add
On Sun, 2018-11-11 at 21:17 +0100, Rafał Miłecki wrote:
> On Sun, 11 Nov 2018 at 21:05, Ben Hutchings wrote:
> > 3.16.61-rc1 review patch. If anyone has any objections, please let me know.
>
> Nack. This patch has caused a regression and had to be reverted.
> Please check upstream repository
On Sun, 2018-11-11 at 21:17 +0100, Rafał Miłecki wrote:
> On Sun, 11 Nov 2018 at 21:05, Ben Hutchings wrote:
> > 3.16.61-rc1 review patch. If anyone has any objections, please let me know.
>
> Nack. This patch has caused a regression and had to be reverted.
> Please check upstream repository
Hi Eric,
> Eric Anholt hat am 20. November 2018 um 18:19 geschrieben:
>
>
> This series moves the BCM2835 WDT driver that controls a fraction of
> the PM block out to soc/ and adds most of the rest of its
> functionality. My motivation has been to have V3D be functional
> without firmware
Hi Eric,
> Eric Anholt hat am 20. November 2018 um 18:19 geschrieben:
>
>
> This series moves the BCM2835 WDT driver that controls a fraction of
> the PM block out to soc/ and adds most of the rest of its
> functionality. My motivation has been to have V3D be functional
> without firmware
Hi Cyrille,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mtd/spi-nor/next]
[also build test ERROR on v4.20-rc3 next-20181120]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Hi Cyrille,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on mtd/spi-nor/next]
[also build test ERROR on v4.20-rc3 next-20181120]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
On Tue, Nov 20, 2018 at 12:56:04PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 20, 2018 at 11:56:18AM +0100, Jiri Olsa escreveu:
> > On Mon, Nov 19, 2018 at 08:10:06AM -0800, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Nov 01, 2018 at 06:00:01PM +0100, Jiri Olsa escreveu:
> > > > Adding
On Tue, Nov 20, 2018 at 12:56:04PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 20, 2018 at 11:56:18AM +0100, Jiri Olsa escreveu:
> > On Mon, Nov 19, 2018 at 08:10:06AM -0800, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Nov 01, 2018 at 06:00:01PM +0100, Jiri Olsa escreveu:
> > > > Adding
On Tue, Nov 20, 2018 at 08:48:59AM -0800, Tejun Heo wrote:
> Hello,
>
> On Tue, Nov 20, 2018 at 04:43:52PM +, Roman Gushchin wrote:
> > > But that wouldn't udpate the cgroup's frozen state and generate
> > > notifications, right?
> >
> > Why? The task will be eventually trapped into
On Tue, Nov 20, 2018 at 08:48:59AM -0800, Tejun Heo wrote:
> Hello,
>
> On Tue, Nov 20, 2018 at 04:43:52PM +, Roman Gushchin wrote:
> > > But that wouldn't udpate the cgroup's frozen state and generate
> > > notifications, right?
> >
> > Why? The task will be eventually trapped into
On 20/11/2018 17:30, John Garry wrote:
> On 20/11/2018 16:23, Jan Glauber wrote:
>> Hi Marc,
>>
>> with 4.20-rc3 I see two WARN_ON's firing on a ThunderX2 system that come from
>> commit 3fb68faee867 (irqchip/gic-v3-its: Register LPI tables with EFI config
>> table).
>>
>> Global
On 20/11/2018 17:30, John Garry wrote:
> On 20/11/2018 16:23, Jan Glauber wrote:
>> Hi Marc,
>>
>> with 4.20-rc3 I see two WARN_ON's firing on a ThunderX2 system that come from
>> commit 3fb68faee867 (irqchip/gic-v3-its: Register LPI tables with EFI config
>> table).
>>
>> Global
On 20/11/2018 16:23, Jan Glauber wrote:
Hi Marc,
with 4.20-rc3 I see two WARN_ON's firing on a ThunderX2 system that come from
commit 3fb68faee867 (irqchip/gic-v3-its: Register LPI tables with EFI config
table).
Global efi_memreserve_root is NULL as it will only be set when early initcalls
On 20/11/2018 16:23, Jan Glauber wrote:
Hi Marc,
with 4.20-rc3 I see two WARN_ON's firing on a ThunderX2 system that come from
commit 3fb68faee867 (irqchip/gic-v3-its: Register LPI tables with EFI config
table).
Global efi_memreserve_root is NULL as it will only be set when early initcalls
On Tue, Nov 20, 2018 at 09:19:53AM -0800, Eric Anholt wrote:
> The binding for the bcm2835 "wdt" actually covers a large range of the
> PM block's register space. The WDT is not a separate HW block from
> the rest of power domain management, so move the driver to the soc/
> directory in
On Tue, Nov 20, 2018 at 09:19:53AM -0800, Eric Anholt wrote:
> The binding for the bcm2835 "wdt" actually covers a large range of the
> PM block's register space. The WDT is not a separate HW block from
> the rest of power domain management, so move the driver to the soc/
> directory in
On Tue, 20 Nov 2018 06:11:02 PST (-0800), tiny.win...@gmail.com wrote:
use of_node_put() to release the refcount.
Signed-off-by: Yangtao Li
---
arch/riscv/kernel/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/kernel/time.c b/arch/riscv/kernel/time.c
index
On Tue, 20 Nov 2018 06:11:02 PST (-0800), tiny.win...@gmail.com wrote:
use of_node_put() to release the refcount.
Signed-off-by: Yangtao Li
---
arch/riscv/kernel/time.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/riscv/kernel/time.c b/arch/riscv/kernel/time.c
index
[ Adding Clark and John who manage the rt-tests repo ]
-- Steve
On Mon, 19 Nov 2018 19:46:23 +
Joe Korty wrote:
> Hi Julia & the RT team,
>
> The following program might make a good addition to the rt
> test suite. It tests the reliability of PTRACE_SINGLESTEP.
> It does by default
[ Adding Clark and John who manage the rt-tests repo ]
-- Steve
On Mon, 19 Nov 2018 19:46:23 +
Joe Korty wrote:
> Hi Julia & the RT team,
>
> The following program might make a good addition to the rt
> test suite. It tests the reliability of PTRACE_SINGLESTEP.
> It does by default
pply 'DBVDD1': -517
wm8994 4-001a: Failed to get supplies: -517
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:2421
regulator_ena_gpio_free+0x70/0xa0
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.20.0-rc3-next-20181120-1-g330f37c7fb0c #5
pply 'DBVDD1': -517
wm8994 4-001a: Failed to get supplies: -517
[ cut here ]
WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:2421
regulator_ena_gpio_free+0x70/0xa0
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted
4.20.0-rc3-next-20181120-1-g330f37c7fb0c #5
> -Original Message-
> From: Andrea Merello
> Sent: Friday, November 16, 2018 7:26 PM
> To: vk...@kernel.org; dan.j.willi...@intel.com; dmaeng...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Radhey Shyam Pandey
> ; Andrea Merello
> Subject: [PATCH] dmaengine: fix
> -Original Message-
> From: Andrea Merello
> Sent: Friday, November 16, 2018 7:26 PM
> To: vk...@kernel.org; dan.j.willi...@intel.com; dmaeng...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org; Radhey Shyam Pandey
> ; Andrea Merello
> Subject: [PATCH] dmaengine: fix
Hi Charles,
On 2018-11-20 18:03, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
>> On 20/11/18 16:34, Marek Szyprowski wrote:
>>> On 2018-11-20 17:16, Richard Fitzgerald wrote:
On 20/11/18 15:56, Marek Szyprowski wrote:
> On 2018-11-20 16:36,
Hi Charles,
On 2018-11-20 18:03, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
>> On 20/11/18 16:34, Marek Szyprowski wrote:
>>> On 2018-11-20 17:16, Richard Fitzgerald wrote:
On 20/11/18 15:56, Marek Szyprowski wrote:
> On 2018-11-20 16:36,
The binding for the bcm2835 "wdt" actually covers a large range of the
PM block's register space. The WDT is not a separate HW block from
the rest of power domain management, so move the driver to the soc/
directory in preparation for expanding its role to cover power
domains.
This move does
The binding for the bcm2835 "wdt" actually covers a large range of the
PM block's register space. The WDT is not a separate HW block from
the rest of power domain management, so move the driver to the soc/
directory in preparation for expanding its role to cover power
domains.
This move does
This is more legible than trying to remember to set PM_PASSWORD on
everything.
Signed-off-by: Eric Anholt
---
drivers/soc/bcm/bcm2835-pm.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/soc/bcm/bcm2835-pm.c b/drivers/soc/bcm/bcm2835-pm.c
This binding supersedes the bcm2835-pm-wdt binding which only covered
enough to provide a watchdog, but the HW block is actually mostly
about power domains.
Signed-off-by: Eric Anholt
---
.../bindings/soc/bcm/brcm,bcm2835-pm.txt | 42 +++
1 file changed, 42 insertions(+)
This is more legible than trying to remember to set PM_PASSWORD on
everything.
Signed-off-by: Eric Anholt
---
drivers/soc/bcm/bcm2835-pm.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/soc/bcm/bcm2835-pm.c b/drivers/soc/bcm/bcm2835-pm.c
This binding supersedes the bcm2835-pm-wdt binding which only covered
enough to provide a watchdog, but the HW block is actually mostly
about power domains.
Signed-off-by: Eric Anholt
---
.../bindings/soc/bcm/brcm,bcm2835-pm.txt | 42 +++
1 file changed, 42 insertions(+)
It was covering part of the PM block's range, up to the WDT regs. To
support the rest of the PM block's functionality, we need the full
register range plus the AXI Async Bridge regs for PM sequencing.
This doesn't convert any of the consumers over to the new binding yet,
since we will need to be
It was covering part of the PM block's range, up to the WDT regs. To
support the rest of the PM block's functionality, we need the full
register range plus the AXI Async Bridge regs for PM sequencing.
This doesn't convert any of the consumers over to the new binding yet,
since we will need to be
The GRAFX domain only contains V3D, and this driver should be the only
accessor of V3D (firmware usage gets disabled when V3D is in the DT),
so we can safely make Linux control the GRAFX and GRAFX_V3D power
domains.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
This series moves the BCM2835 WDT driver that controls a fraction of
the PM block out to soc/ and adds most of the rest of its
functionality. My motivation has been to have V3D be functional
without firmware calls, probably improve its interactivity (since
we'll be able to power on/off without
The GRAFX domain only contains V3D, and this driver should be the only
accessor of V3D (firmware usage gets disabled when V3D is in the DT),
so we can safely make Linux control the GRAFX and GRAFX_V3D power
domains.
Signed-off-by: Eric Anholt
---
arch/arm/boot/dts/bcm2835-rpi.dtsi | 4
This series moves the BCM2835 WDT driver that controls a fraction of
the PM block out to soc/ and adds most of the rest of its
functionality. My motivation has been to have V3D be functional
without firmware calls, probably improve its interactivity (since
we'll be able to power on/off without
This is the name of the block we're controlling.
Signed-off-by: Eric Anholt
---
drivers/soc/bcm/bcm2835-pm.c | 92 ++--
1 file changed, 47 insertions(+), 45 deletions(-)
diff --git a/drivers/soc/bcm/bcm2835-pm.c b/drivers/soc/bcm/bcm2835-pm.c
index
This provides a free software alternative to raspberrypi-power.c's
firmware calls to manage power domains. It also exposes a reset line,
where previously the vc4 driver had to try to force power off the
domain in order to trigger a reset.
Signed-off-by: Eric Anholt
---
We definitely don't want I/O to be reordered here (like the setting of
the WDT timeout before enabling the WDT). None of this is performance
critical, anyway.
Signed-off-by: Eric Anholt
---
drivers/soc/bcm/bcm2835-pm.c | 24
1 file changed, 12 insertions(+), 12
This is the name of the block we're controlling.
Signed-off-by: Eric Anholt
---
drivers/soc/bcm/bcm2835-pm.c | 92 ++--
1 file changed, 47 insertions(+), 45 deletions(-)
diff --git a/drivers/soc/bcm/bcm2835-pm.c b/drivers/soc/bcm/bcm2835-pm.c
index
This provides a free software alternative to raspberrypi-power.c's
firmware calls to manage power domains. It also exposes a reset line,
where previously the vc4 driver had to try to force power off the
domain in order to trigger a reset.
Signed-off-by: Eric Anholt
---
We definitely don't want I/O to be reordered here (like the setting of
the WDT timeout before enabling the WDT). None of this is performance
critical, anyway.
Signed-off-by: Eric Anholt
---
drivers/soc/bcm/bcm2835-pm.c | 24
1 file changed, 12 insertions(+), 12
On Tue, Nov 20, 2018 at 07:44:10AM -0800, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, Nov 20, 2018 at 01:46:24PM +0100, Peter Zijlstra wrote:
> > Why though? The Changelog doesn't give rationale for the actual changes.
>
> Ah yeah, sorry about that.
>
> > And I'm not sure I agree with either
On Tue, Nov 20, 2018 at 07:44:10AM -0800, Tejun Heo wrote:
> Hello, Peter.
>
> On Tue, Nov 20, 2018 at 01:46:24PM +0100, Peter Zijlstra wrote:
> > Why though? The Changelog doesn't give rationale for the actual changes.
>
> Ah yeah, sorry about that.
>
> > And I'm not sure I agree with either
On Tue, Nov 20, 2018 at 02:40:31PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The irq_sim irqchip doesn't allow to configure the sensitivity so every
> call to irq_sim_fire() fires a dummy interrupt. This used to not matter
> for gpio-mockup (one of the irq_sim users)
On Tue, Nov 20, 2018 at 02:40:31PM +0100, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The irq_sim irqchip doesn't allow to configure the sensitivity so every
> call to irq_sim_fire() fires a dummy interrupt. This used to not matter
> for gpio-mockup (one of the irq_sim users)
Hello Romain,
On 20/11/2018 17:57:37+0100, Romain Izard wrote:
> The SAMA5D2 is different from SAMA5D3 and SAMA5D4, as there are two
> different clocks for the peripherals in the SoC. The Static Memory
> controller is connected to the divided master clock.
>
> Unfortunately, the device tree does
Hello Romain,
On 20/11/2018 17:57:37+0100, Romain Izard wrote:
> The SAMA5D2 is different from SAMA5D3 and SAMA5D4, as there are two
> different clocks for the peripherals in the SoC. The Static Memory
> controller is connected to the divided master clock.
>
> Unfortunately, the device tree does
I am eagar to build under the scripts/ directory only with $(HOSTCC),
but scripts/mod/ highly depends on the $(CC) and target arch headers.
That it why the 'scripts' target must depend on 'asm-generic',
'gcc-plugins', and $(autoksyms_h).
Move it to the 'prepare0' stage. I know this is a cheesy
I am eagar to build under the scripts/ directory only with $(HOSTCC),
but scripts/mod/ highly depends on the $(CC) and target arch headers.
That it why the 'scripts' target must depend on 'asm-generic',
'gcc-plugins', and $(autoksyms_h).
Move it to the 'prepare0' stage. I know this is a cheesy
Hi Richard,
On 2018-11-20 17:57, Richard Fitzgerald wrote:
> On 20/11/18 16:34, Marek Szyprowski wrote:
>> Hi Richard,
>>
>> On 2018-11-20 17:16, Richard Fitzgerald wrote:
>>> On 20/11/18 15:56, Marek Szyprowski wrote:
Hi Charles,
On 2018-11-20 16:36, Charles Keepax wrote:
> On
Hi Richard,
On 2018-11-20 17:57, Richard Fitzgerald wrote:
> On 20/11/18 16:34, Marek Szyprowski wrote:
>> Hi Richard,
>>
>> On 2018-11-20 17:16, Richard Fitzgerald wrote:
>>> On 20/11/18 15:56, Marek Szyprowski wrote:
Hi Charles,
On 2018-11-20 16:36, Charles Keepax wrote:
> On
On Mon, Nov 19, 2018 at 09:16:35AM -0600, Rob Herring wrote:
> On Wed, Nov 14, 2018 at 9:10 AM Johan Hovold wrote:
> >
> > This series make the synchronous serdev_device_write() helper more
> > usable by
> >
> > 1) allowing drivers to pass a zero timeout to indicate that they
> >
On Mon, Nov 19, 2018 at 09:16:35AM -0600, Rob Herring wrote:
> On Wed, Nov 14, 2018 at 9:10 AM Johan Hovold wrote:
> >
> > This series make the synchronous serdev_device_write() helper more
> > usable by
> >
> > 1) allowing drivers to pass a zero timeout to indicate that they
> >
On 20/11/18 17:01, Mark Brown wrote:
On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
On 20/11/18 16:34, Marek Szyprowski wrote:
Deferred probe was there already. This patch however introduced the
warning from gpiolib and I would like to have it fixed somehow. In both
I
On 20/11/18 17:01, Mark Brown wrote:
On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
On 20/11/18 16:34, Marek Szyprowski wrote:
Deferred probe was there already. This patch however introduced the
warning from gpiolib and I would like to have it fixed somehow. In both
I
The patch
regulator: core: Don't double-disable supplies in
regulator_disable_deferred()
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree
The patch
regulator: core: Don't double-disable supplies in
regulator_disable_deferred()
has been applied to the regulator tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree
On Mon, Nov 19, 2018 at 09:15:37AM -0600, Rob Herring wrote:
> On Wed, Nov 14, 2018 at 9:10 AM Johan Hovold wrote:
> >
> > Make the synchronous serdev_device_write() helper behave analogous to
> > the asynchronous serdev_device_write_buf() by returning the number of
> > bytes written (or rather
On Mon, Nov 19, 2018 at 09:15:37AM -0600, Rob Herring wrote:
> On Wed, Nov 14, 2018 at 9:10 AM Johan Hovold wrote:
> >
> > Make the synchronous serdev_device_write() helper behave analogous to
> > the asynchronous serdev_device_write_buf() by returning the number of
> > bytes written (or rather
On Tue, Nov 20, 2018 at 08:19:39AM -0800, Kyle Huey wrote:
> tl;dr: rr is currently broken on 4.20rc2, which I bisected to
> af3bdb991a5cb57c189d34aadbd3aa88995e0d9f. I further confirmed that
> booting the 4.20rc2 kernel with `disable_counter_freezing=true` allows
> rr to work.
>
> rr, a
On Tue, Nov 20, 2018 at 08:19:39AM -0800, Kyle Huey wrote:
> tl;dr: rr is currently broken on 4.20rc2, which I bisected to
> af3bdb991a5cb57c189d34aadbd3aa88995e0d9f. I further confirmed that
> booting the 4.20rc2 kernel with `disable_counter_freezing=true` allows
> rr to work.
>
> rr, a
Hi,
On Tue, Nov 20, 2018 at 8:58 AM Mark Brown wrote:
>
> On Tue, Nov 20, 2018 at 08:52:14AM -0800, Doug Anderson wrote:
>
> > I don't want to send v2 of things while you're still reviewing. If
> > you have a chance give me a ping when you're ready for me to send out
> > v2 of things.
Hi,
On Tue, Nov 20, 2018 at 8:58 AM Mark Brown wrote:
>
> On Tue, Nov 20, 2018 at 08:52:14AM -0800, Doug Anderson wrote:
>
> > I don't want to send v2 of things while you're still reviewing. If
> > you have a chance give me a ping when you're ready for me to send out
> > v2 of things.
On Tue, Nov 20, 2018 at 12:11:22PM +0300, Kirill A. Shutemov wrote:
> On Sat, Nov 10, 2018 at 11:44:12AM -0500, Andrea Arcangeli wrote:
> > I would prefer to add intelligence to detect when COWs after fork
> > should be done at 2m or 4k granularity (in the latter case by
> > splitting the pmd
On Tue, Nov 20, 2018 at 08:33:19AM -0800, Tejun Heo wrote:
> On Mon, Nov 19, 2018 at 08:45:54AM -0800, Daniel Jordan wrote:
> > So instead of flush_work_at_nice, how about this?:
> >
> > void renice_work_sync(work_struct *work, long nice);
>
> Wouldn't renice_or_cancel make more sense?
I guess
On Tue, Nov 20, 2018 at 12:11:22PM +0300, Kirill A. Shutemov wrote:
> On Sat, Nov 10, 2018 at 11:44:12AM -0500, Andrea Arcangeli wrote:
> > I would prefer to add intelligence to detect when COWs after fork
> > should be done at 2m or 4k granularity (in the latter case by
> > splitting the pmd
On Tue, Nov 20, 2018 at 08:33:19AM -0800, Tejun Heo wrote:
> On Mon, Nov 19, 2018 at 08:45:54AM -0800, Daniel Jordan wrote:
> > So instead of flush_work_at_nice, how about this?:
> >
> > void renice_work_sync(work_struct *work, long nice);
>
> Wouldn't renice_or_cancel make more sense?
I guess
On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
> On 20/11/18 16:34, Marek Szyprowski wrote:
> >On 2018-11-20 17:16, Richard Fitzgerald wrote:
> >>On 20/11/18 15:56, Marek Szyprowski wrote:
> >>>On 2018-11-20 16:36, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 03:32:15PM
On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
> On 20/11/18 16:34, Marek Szyprowski wrote:
> >On 2018-11-20 17:16, Richard Fitzgerald wrote:
> >>On 20/11/18 15:56, Marek Szyprowski wrote:
> >>>On 2018-11-20 16:36, Charles Keepax wrote:
> On Tue, Nov 20, 2018 at 03:32:15PM
We need to manage the life time of the enable GPIO against the regulator
device but the OF node lives on the parent MFD device. As such we can't
use the devm functions which assume the same device will be used for
both.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
This patch
We need to manage the life time of the enable GPIO against the regulator
device but the OF node lives on the parent MFD device. As such we can't
use the devm functions which assume the same device will be used for
both.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
This patch
ADT7316 driver no more uses platform data and hence use device tree
data instead of platform data for assigning irq_type field.
Switch case figures out the type of irq and if it's the default case
then assign the default value to the irq_type i.e.
irq_type = IRQF_TRIGGER_LOW
Signed-off-by:
ADT7316 driver no more uses platform data and hence use device tree
data instead of platform data for assigning irq_type field.
Switch case figures out the type of irq and if it's the default case
then assign the default value to the irq_type i.e.
irq_type = IRQF_TRIGGER_LOW
Signed-off-by:
On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
> On 20/11/18 16:34, Marek Szyprowski wrote:
> > Deferred probe was there already. This patch however introduced the
> > warning from gpiolib and I would like to have it fixed somehow. In both
> I don't follow what it is you
On Tue, Nov 20, 2018 at 04:57:16PM +, Richard Fitzgerald wrote:
> On 20/11/18 16:34, Marek Szyprowski wrote:
> > Deferred probe was there already. This patch however introduced the
> > warning from gpiolib and I would like to have it fixed somehow. In both
> I don't follow what it is you
On Tue, Nov 20, 2018 at 08:57:32AM -0800, Doug Anderson wrote:
> OK. I guess for now I'll just change this to disable the parent
> supply as many times as this individual consumer enabled it and call
> it good enough? It can be for someone else to figure out how to make
> it really usable for
On Tue, Nov 20, 2018 at 08:57:32AM -0800, Doug Anderson wrote:
> OK. I guess for now I'll just change this to disable the parent
> supply as many times as this individual consumer enabled it and call
> it good enough? It can be for someone else to figure out how to make
> it really usable for
On Tue, Nov 20, 2018 at 08:57:32AM -0800, Doug Anderson wrote:
> On Tue, Nov 20, 2018 at 8:25 AM Mark Brown wrote:
> > I do wish there
> > were a way to flag API calls as needing review :(
> Would it be worth adding a WARN_ON(1) splat here or at least a
> "dev_warn" so people knew it wasn't
On Tue, Nov 20, 2018 at 08:57:32AM -0800, Doug Anderson wrote:
> On Tue, Nov 20, 2018 at 8:25 AM Mark Brown wrote:
> > I do wish there
> > were a way to flag API calls as needing review :(
> Would it be worth adding a WARN_ON(1) splat here or at least a
> "dev_warn" so people knew it wasn't
On Tue, Nov 20, 2018 at 08:14:19AM -0800, Tejun Heo wrote:
> On Thu, Nov 15, 2018 at 09:09:54PM -0500, Radu Rendec wrote:
> > kernfs_notify() does two notifications: poll and fsnotify. Originally,
> > both notifications were done from scheduled work context and all that
> > kernfs_notify() did was
Most of the drivers in IIO uses irq_type as the name for
storing the interrupt type and hence change the name from
irq_flags to irq_type for maintaining the consistency.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316.c | 8
1 file changed, 4 insertions(+), 4
On Tue, Nov 20, 2018 at 08:14:19AM -0800, Tejun Heo wrote:
> On Thu, Nov 15, 2018 at 09:09:54PM -0500, Radu Rendec wrote:
> > kernfs_notify() does two notifications: poll and fsnotify. Originally,
> > both notifications were done from scheduled work context and all that
> > kernfs_notify() did was
Most of the drivers in IIO uses irq_type as the name for
storing the interrupt type and hence change the name from
irq_flags to irq_type for maintaining the consistency.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316.c | 8
1 file changed, 4 insertions(+), 4
On Tue, Nov 20, 2018 at 08:52:14AM -0800, Doug Anderson wrote:
> I don't want to send v2 of things while you're still reviewing. If
> you have a chance give me a ping when you're ready for me to send out
> v2 of things. ...otherwise I'll plan to send it out later today or
> tomorrow morning.
On Tue, Nov 20, 2018 at 08:52:14AM -0800, Doug Anderson wrote:
> I don't want to send v2 of things while you're still reviewing. If
> you have a chance give me a ping when you're ready for me to send out
> v2 of things. ...otherwise I'll plan to send it out later today or
> tomorrow morning.
601 - 700 of 1736 matches
Mail list logo
