On Mon, Nov 19, 2018 at 05:28:42PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.126 release.
> There are 90 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, Nov 20, 2018 at 04:51:07PM +, Ioana Ciornei wrote:
> > On Tue, Nov 20, 2018 at 03:39:45PM +, Ioana Ciornei wrote:
> > > +
> > > + error = fsl_mc_uapi_create_device_file(mc_bus);
> > > + if (error < 0) {
> > > + error =
On Mon, Nov 19, 2018 at 05:28:42PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 3.18.126 release.
> There are 90 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me
On Tue, Nov 20, 2018 at 04:51:07PM +, Ioana Ciornei wrote:
> > On Tue, Nov 20, 2018 at 03:39:45PM +, Ioana Ciornei wrote:
> > > +
> > > + error = fsl_mc_uapi_create_device_file(mc_bus);
> > > + if (error < 0) {
> > > + error =
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 Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote:
On Tue, Nov 20, 2018 at
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 not correctly show this and uses the
master clock directly. This clock is
On Tue 2018-11-20 09:49:50, Jonathan Corbet wrote:
> On Tue, 20 Nov 2018 10:05:21 +0100
> Vlastimil Babka wrote:
>
> > Why can't the documentation describe the current implementation, and
> > change in the future if the implementation changes? I doubt somebody
> > would ever rely on the pid
Hi,
On Tue, Nov 20, 2018 at 8:25 AM Mark Brown wrote:
>
> If something has been forced off the system is in very serious trouble
> and had a cricial safety problem, though the fact that there's error
> handling code that did the force disable might mean that there's some
> ability to recover the
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 Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote:
On Tue, Nov 20, 2018 at
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 not correctly show this and uses the
master clock directly. This clock is
On Tue 2018-11-20 09:49:50, Jonathan Corbet wrote:
> On Tue, 20 Nov 2018 10:05:21 +0100
> Vlastimil Babka wrote:
>
> > Why can't the documentation describe the current implementation, and
> > change in the future if the implementation changes? I doubt somebody
> > would ever rely on the pid
Hi,
On Tue, Nov 20, 2018 at 8:25 AM Mark Brown wrote:
>
> If something has been forced off the system is in very serious trouble
> and had a cricial safety problem, though the fact that there's error
> handling code that did the force disable might mean that there's some
> ability to recover the
There is no need to store irq_flags into the structure as it
is always set to the same thing. Hence switch irq_flags to a
local variable.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316-i2c.c | 1 -
drivers/staging/iio/addac/adt7316-spi.c | 1 -
There is no need to store irq_flags into the structure as it
is always set to the same thing. Hence switch irq_flags to a
local variable.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316-i2c.c | 1 -
drivers/staging/iio/addac/adt7316-spi.c | 1 -
Define the length of the DBI registers. This makes sure that
the kernel does not access registers beyond that point, avoiding
the following abort on a i.MX 6Quad:
# cat /sys/devices/soc0/soc/1ffc000.pcie/pci\:00/\:00\:00.0/config
[ 100.021433] Unhandled fault: imprecise external abort
Introduce driver data struct. This will simplify handling of device
specific differences.
Signed-off-by: Stefan Agner
Reviewed-by: Lucas Stach
---
Changes in v2:
- Split drvdata introduction in a separate patch
- Use an array instead of individual struct imx6_pcie_drvdata declarations
Changes
Introduce driver data struct. This will simplify handling of device
specific differences.
Signed-off-by: Stefan Agner
Reviewed-by: Lucas Stach
---
Changes in v2:
- Split drvdata introduction in a separate patch
- Use an array instead of individual struct imx6_pcie_drvdata declarations
Changes
Define the length of the DBI registers. This makes sure that
the kernel does not access registers beyond that point, avoiding
the following abort on a i.MX 6Quad:
# cat /sys/devices/soc0/soc/1ffc000.pcie/pci\:00/\:00\:00.0/config
[ 100.021433] Unhandled fault: imprecise external abort
Hello Michal,
On Tue, Nov 20, 2018 at 01:14:33PM +, Vokáč Michal wrote:
> On 16.11.2018 10:51, Thierry Reding wrote:
> > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
> >> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:
> > My impression was that he was
Hello Michal,
On Tue, Nov 20, 2018 at 01:14:33PM +, Vokáč Michal wrote:
> On 16.11.2018 10:51, Thierry Reding wrote:
> > On Thu, Nov 15, 2018 at 09:37:33PM +0100, Uwe Kleine-König wrote:
> >> On Thu, Nov 15, 2018 at 04:25:45PM +0100, Thierry Reding wrote:
> > My impression was that he was
Make the driver use device tree instead of the platform data.
Hence, use devm_gpiod_get_optional function to get the data from
device tree for ldac-pin and accordingly make the needed changes
in the driver.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316.c | 14 ++
Make the driver use device tree instead of the platform data.
Hence, use devm_gpiod_get_optional function to get the data from
device tree for ldac-pin and accordingly make the needed changes
in the driver.
Signed-off-by: Shreeya Patel
---
drivers/staging/iio/addac/adt7316.c | 14 ++
On Mon, 19 Nov 2018 at 16:22, Mathieu Poirier
wrote:
>
> On Sun, Nov 11, 2018 at 01:07:56PM +0800, Leo Yan wrote:
> > We have prepared the flags in the packet structure, so need to copy
> > the related value into sample structure thus perf tool can facilitate
> > sample flags.
> >
> > The
On Mon, 19 Nov 2018 at 16:22, Mathieu Poirier
wrote:
>
> On Sun, Nov 11, 2018 at 01:07:56PM +0800, Leo Yan wrote:
> > We have prepared the flags in the packet structure, so need to copy
> > the related value into sample structure thus perf tool can facilitate
> > sample flags.
> >
> > The
Hi,
On Tue, Nov 20, 2018 at 8:10 AM Mark Brown wrote:
>
> On Mon, Nov 19, 2018 at 04:26:52PM -0800, Douglas Anderson wrote:
> > Now that consumers all keep track of their own enable count, let's add
> > it into the regulator_summary.
>
> This patch series contains a bunch of random stuff that's
Hi,
On Tue, Nov 20, 2018 at 8:10 AM Mark Brown wrote:
>
> On Mon, Nov 19, 2018 at 04:26:52PM -0800, Douglas Anderson wrote:
> > Now that consumers all keep track of their own enable count, let's add
> > it into the regulator_summary.
>
> This patch series contains a bunch of random stuff that's
When the kernel starts up, it kicks off compiled-in drivers
that match “compatible” entries it finds in the device tree.
At a later stage (when /lib/modules is available), all kernel modules
that match “compatible” entries in the device tree are loaded.
But if there is no dt table then there
When the kernel starts up, it kicks off compiled-in drivers
that match “compatible” entries it finds in the device tree.
At a later stage (when /lib/modules is available), all kernel modules
that match “compatible” entries in the device tree are loaded.
But if there is no dt table then there
On Tue, Nov 20, 2018 at 05:10:32PM +0100, Alexandre Belloni wrote:
> jetztechnologies.com doesn't exist anymore and emails to Ranganathan are
> bouncing.
>
> Signed-off-by: Alexandre Belloni
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
>
On Tue, Nov 20, 2018 at 05:10:32PM +0100, Alexandre Belloni wrote:
> jetztechnologies.com doesn't exist anymore and emails to Ranganathan are
> bouncing.
>
> Signed-off-by: Alexandre Belloni
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
>
Hi,
On Tue, Nov 20, 2018 at 8:47 AM Mark Brown wrote:
>
> On Tue, Nov 20, 2018 at 04:41:25PM +, Mark Brown wrote:
> > On Tue, Nov 20, 2018 at 08:37:04AM -0800, Doug Anderson wrote:
> >
> > > Hold up! How does this compile for you? It looks as if you landed it
> > > before ("regulator:
Hi,
On Tue, Nov 20, 2018 at 8:47 AM Mark Brown wrote:
>
> On Tue, Nov 20, 2018 at 04:41:25PM +, Mark Brown wrote:
> > On Tue, Nov 20, 2018 at 08:37:04AM -0800, Doug Anderson wrote:
> >
> > > Hold up! How does this compile for you? It looks as if you landed it
> > > before ("regulator:
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 cgroup_enter_frozen(),
> and from there cgroup_update_frozen() will be called.
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 cgroup_enter_frozen(),
> and from there cgroup_update_frozen() will be called.
On Mon, Nov 19, 2018 at 04:22:49PM -0800, Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um,
On Mon, Nov 19, 2018 at 04:22:49PM -0800, Andy Lutomirski wrote:
> Hi all-
>
> We currently have some giant turds in the way that syscalls are
> numbered. We have the x86_32 table, which is totally sane other than
> some legacy multiplexers. Then we have the x86_64 table, which is,
> um,
On Tue, Nov 20, 2018 at 04:41:25PM +, Mark Brown wrote:
> On Tue, Nov 20, 2018 at 08:37:04AM -0800, Doug Anderson wrote:
>
> > Hold up! How does this compile for you? It looks as if you landed it
> > before ("regulator: core: Only count load for enabled consumers")
> > which is the patch
On Tue, Nov 20, 2018 at 04:41:25PM +, Mark Brown wrote:
> On Tue, Nov 20, 2018 at 08:37:04AM -0800, Doug Anderson wrote:
>
> > Hold up! How does this compile for you? It looks as if you landed it
> > before ("regulator: core: Only count load for enabled consumers")
> > which is the patch
This patchset introduces device tree bindings for adt7316
driver and removes the usage of platform data from it.
Also, it sets the data field to it's appropriate value in
the i2c read function which was nowhere being set before.
Changes in v2:
- Make the commit message of patch *[1/5]
[+ Ard]
Hi Jan,
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
This patchset introduces device tree bindings for adt7316
driver and removes the usage of platform data from it.
Also, it sets the data field to it's appropriate value in
the i2c read function which was nowhere being set before.
Changes in v2:
- Make the commit message of patch *[1/5]
[+ Ard]
Hi Jan,
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
On Tue, Nov 20, 2018 at 08:36:04AM -0800, Tejun Heo wrote:
> On Tue, Nov 20, 2018 at 04:33:11PM +, Roman Gushchin wrote:
> > > If a non-frozen task is being moved into a frozen cgroup, shouldn't
> > > that also trigger frozen state update?
> >
> > It does! Just below these lines:
> >
> >
On Tue, Nov 20, 2018 at 08:36:04AM -0800, Tejun Heo wrote:
> On Tue, Nov 20, 2018 at 04:33:11PM +, Roman Gushchin wrote:
> > > If a non-frozen task is being moved into a frozen cgroup, shouldn't
> > > that also trigger frozen state update?
> >
> > It does! Just below these lines:
> >
> >
Hi,
On Tue, Nov 20, 2018 at 8:41 AM Mark Brown wrote:
>
> On Tue, Nov 20, 2018 at 08:37:04AM -0800, Doug Anderson wrote:
>
> > Hold up! How does this compile for you? It looks as if you landed it
> > before ("regulator: core: Only count load for enabled consumers")
> > which is the patch that
Hi,
On Tue, Nov 20, 2018 at 8:41 AM Mark Brown wrote:
>
> On Tue, Nov 20, 2018 at 08:37:04AM -0800, Doug Anderson wrote:
>
> > Hold up! How does this compile for you? It looks as if you landed it
> > before ("regulator: core: Only count load for enabled consumers")
> > which is the patch that
On Tue, Nov 20, 2018 at 08:37:04AM -0800, Doug Anderson wrote:
> Hold up! How does this compile for you? It looks as if you landed it
> before ("regulator: core: Only count load for enabled consumers")
> which is the patch that adds "enable_count" to the consumer structure.
> I'm just working
On Tue, Nov 20, 2018 at 08:37:04AM -0800, Doug Anderson wrote:
> Hold up! How does this compile for you? It looks as if you landed it
> before ("regulator: core: Only count load for enabled consumers")
> which is the patch that adds "enable_count" to the consumer structure.
> I'm just working
On Tue, Nov 20, 2018 at 08:18:57PM +0530, Harsh Shandilya wrote:
> On 20 November 2018 4:46:13 PM IST, Greg Kroah-Hartman
> wrote:
> >On Tue, Nov 20, 2018 at 04:09:05PM +0530, Harsh Shandilya wrote:
> >> On 19 November 2018 9:58:42 PM IST, Greg Kroah-Hartman
> > wrote:
> >> >This is the start of
On Tue, Nov 20, 2018 at 08:18:57PM +0530, Harsh Shandilya wrote:
> On 20 November 2018 4:46:13 PM IST, Greg Kroah-Hartman
> wrote:
> >On Tue, Nov 20, 2018 at 04:09:05PM +0530, Harsh Shandilya wrote:
> >> On 19 November 2018 9:58:42 PM IST, Greg Kroah-Hartman
> > wrote:
> >> >This is the start of
Hi,
On Tue, Nov 20, 2018 at 8:28 AM Mark Brown wrote:
>
> The patch
>
>regulator: core: add enable_count for consumers to debug fs
>
> 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
Hi,
On Tue, Nov 20, 2018 at 8:28 AM Mark Brown wrote:
>
> The patch
>
>regulator: core: add enable_count for consumers to debug fs
>
> 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
On Tue, Nov 20, 2018 at 04:33:11PM +, Roman Gushchin wrote:
> > If a non-frozen task is being moved into a frozen cgroup, shouldn't
> > that also trigger frozen state update?
>
> It does! Just below these lines:
>
> /*
>* If the task isn't in the desired state, force it to it.
On Tue, Nov 20, 2018 at 04:33:11PM +, Roman Gushchin wrote:
> > If a non-frozen task is being moved into a frozen cgroup, shouldn't
> > that also trigger frozen state update?
>
> It does! Just below these lines:
>
> /*
>* If the task isn't in the desired state, force it to it.
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 Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote:
On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek
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 Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote:
On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek
On Tue, Nov 20, 2018 at 08:25:29AM -0800, Tejun Heo wrote:
> On Fri, Nov 16, 2018 at 04:38:27PM -0800, Roman Gushchin wrote:
> > +void cgroup_freezer_migrate_task(struct task_struct *task,
> > +struct cgroup *src, struct cgroup *dst)
> > +{
> > +
On Tue, Nov 20, 2018 at 08:25:29AM -0800, Tejun Heo wrote:
> On Fri, Nov 16, 2018 at 04:38:27PM -0800, Roman Gushchin wrote:
> > +void cgroup_freezer_migrate_task(struct task_struct *task,
> > +struct cgroup *src, struct cgroup *dst)
> > +{
> > +
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?
Thanks.
--
tejun
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?
Thanks.
--
tejun
Commit-ID: 68239654acafe6aad5a3c1dc7237e60accfebc03
Gitweb: https://git.kernel.org/tip/68239654acafe6aad5a3c1dc7237e60accfebc03
Author: Sebastian Andrzej Siewior
AuthorDate: Tue, 20 Nov 2018 11:26:35 +0100
Committer: Borislav Petkov
CommitDate: Tue, 20 Nov 2018 17:22:42 +0100
x86/fpu:
Commit-ID: 68239654acafe6aad5a3c1dc7237e60accfebc03
Gitweb: https://git.kernel.org/tip/68239654acafe6aad5a3c1dc7237e60accfebc03
Author: Sebastian Andrzej Siewior
AuthorDate: Tue, 20 Nov 2018 11:26:35 +0100
Committer: Borislav Petkov
CommitDate: Tue, 20 Nov 2018 17:22:42 +0100
x86/fpu:
The patch
regulator: lochnagar: Add initial binding documentation
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 (usually sometime in the next
The patch
regulator: lochnagar: Add initial binding documentation
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 (usually sometime in the next
The patch
regulator: core: add enable_count for consumers to debug fs
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 (usually sometime in the
The patch
regulator: core: add enable_count for consumers to debug fs
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 (usually sometime in the
The patch
regulator: core: Properly expose requested_microamps in sysfs
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 (usually sometime in the
The patch
regulator: s2mps11: Fix GPIO descriptor initialization
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 (usually sometime in the next 24
The patch
regulator: core: Properly expose requested_microamps in sysfs
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 (usually sometime in the
The patch
regulator: s2mps11: Fix GPIO descriptor initialization
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 (usually sometime in the next 24
The patch
regulator: Fix return value of _set_load() stub
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 (usually sometime in the next 24 hours)
The patch
regulator: core: Export regulator_lock and regulator_unlock
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 (usually sometime in the
The patch
regulator: lochnagar: Move driver to binding from DT
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 (usually sometime in the next 24
Hello, Paolo.
On Mon, Nov 19, 2018 at 11:34:14AM +0100, Paolo Valente wrote:
> - if all entities produce the same output, the this common output is
> shown only once;
> - if the outputs differ, then every per-entity output is shown,
> followed by the name of the entity that produced that
The patch
regulator: core: Export regulator_lock and regulator_unlock
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 (usually sometime in the
The patch
regulator: lochnagar: Move driver to binding from DT
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 (usually sometime in the next 24
Hello, Paolo.
On Mon, Nov 19, 2018 at 11:34:14AM +0100, Paolo Valente wrote:
> - if all entities produce the same output, the this common output is
> shown only once;
> - if the outputs differ, then every per-entity output is shown,
> followed by the name of the entity that produced that
The patch
regulator: Fix return value of _set_load() stub
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 (usually sometime in the next 24 hours)
On Fri, Nov 16, 2018 at 04:38:27PM -0800, Roman Gushchin wrote:
> +void cgroup_freezer_migrate_task(struct task_struct *task,
> + struct cgroup *src, struct cgroup *dst)
> +{
> + lockdep_assert_held(_set_lock);
> +
> + /*
> + * Kernel threads are not
On Fri, Nov 16, 2018 at 04:38:27PM -0800, Roman Gushchin wrote:
> +void cgroup_freezer_migrate_task(struct task_struct *task,
> + struct cgroup *src, struct cgroup *dst)
> +{
> + lockdep_assert_held(_set_lock);
> +
> + /*
> + * Kernel threads are not
On Tue, Nov 20, 2018 at 08:04:57AM -0800, Doug Anderson wrote:
> In general it's hard for me to reason about how the system in general
> should behave after regulator_force_disable() is called. Is it
> basically expected that the system will panic soon after?
> Specifically other consumers of
On Tue, Nov 20, 2018 at 08:04:57AM -0800, Doug Anderson wrote:
> In general it's hard for me to reason about how the system in general
> should behave after regulator_force_disable() is called. Is it
> basically expected that the system will panic soon after?
> Specifically other consumers of
On Fri, 9 Nov 2018 10:30:41 +0530
Naga Sureshkumar Relli wrote:
> +static int anfc_setup_data_interface(struct nand_chip *chip, int csline,
> + const struct nand_data_interface *conf)
> +{
> + struct anfc_nand_controller *nfc = to_anfc(chip->controller);
> +
On Fri, 9 Nov 2018 10:30:41 +0530
Naga Sureshkumar Relli wrote:
> +static int anfc_setup_data_interface(struct nand_chip *chip, int csline,
> + const struct nand_data_interface *conf)
> +{
> + struct anfc_nand_controller *nfc = to_anfc(chip->controller);
> +
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
are
running, but from the backtrace the
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
are
running, but from the backtrace the
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 userspace record and replay debugger[0], uses the PMU interrupt
(PMI) to stop a
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 userspace record and replay debugger[0], uses the PMU interrupt
(PMI) to stop a
On Fri, Nov 16, 2018 at 04:38:26PM -0800, Roman Gushchin wrote:
> Now the number of descendant cgroups and the number of dying
> descendant cgroups are synchronized using the cgroup_mutex.
>
> The number of descendant cgroups will be required by the cgroup v2
> freezer, which will use it to
On Fri, Nov 16, 2018 at 04:38:26PM -0800, Roman Gushchin wrote:
> Now the number of descendant cgroups and the number of dying
> descendant cgroups are synchronized using the cgroup_mutex.
>
> The number of descendant cgroups will be required by the cgroup v2
> freezer, which will use it to
On 20/11/18 15:56, Marek Szyprowski wrote:
Hi Charles,
On 2018-11-20 16:36, Charles Keepax wrote:
On Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote:
On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote:
On 2018-11-20 15:47, Charles Keepax wrote:
On Tue, Nov 20, 2018
On Mon, Nov 19, 2018 at 04:49:27PM -0800, Sagi Grimberg wrote:
>
>> The only user in your final tree seems to be the loop driver, and
>> even that one only uses the helper for read/write bios.
>>
>> I think something like this would be much simpler in the end:
>
> The recently submitted nvme-tcp
On 20/11/18 15:56, Marek Szyprowski wrote:
Hi Charles,
On 2018-11-20 16:36, Charles Keepax wrote:
On Tue, Nov 20, 2018 at 03:32:15PM +, Charles Keepax wrote:
On Tue, Nov 20, 2018 at 03:58:59PM +0100, Marek Szyprowski wrote:
On 2018-11-20 15:47, Charles Keepax wrote:
On Tue, Nov 20, 2018
On Mon, Nov 19, 2018 at 04:49:27PM -0800, Sagi Grimberg wrote:
>
>> The only user in your final tree seems to be the loop driver, and
>> even that one only uses the helper for read/write bios.
>>
>> I think something like this would be much simpler in the end:
>
> The recently submitted nvme-tcp
On Tue, Nov 20, 2018 at 09:42:05AM +0530, Rajendra Nayak wrote:
>
>
> On 11/9/2018 10:09 PM, Niklas Cassel wrote:
> > On Mon, Nov 05, 2018 at 05:17:45PM -0600, Rob Herring wrote:
> > > On Mon, Oct 15, 2018 at 02:47:49PM +0200, Niklas Cassel wrote:
> > > > Extend qcom-opp bindings with properties
On Tue, Nov 20, 2018 at 09:42:05AM +0530, Rajendra Nayak wrote:
>
>
> On 11/9/2018 10:09 PM, Niklas Cassel wrote:
> > On Mon, Nov 05, 2018 at 05:17:45PM -0600, Rob Herring wrote:
> > > On Mon, Oct 15, 2018 at 02:47:49PM +0200, Niklas Cassel wrote:
> > > > Extend qcom-opp bindings with properties
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
bl_idle_init() doesn't do that, so fix it.
Signed-off-by: Yangtao Li
---
Changes in v3:
-update changelog
---
drivers/cpuidle/cpuidle-big_little.c | 6 +-
1 file
of_find_node_by_path() acquires a reference to the node
returned by it and that reference needs to be dropped by its caller.
bl_idle_init() doesn't do that, so fix it.
Signed-off-by: Yangtao Li
---
Changes in v3:
-update changelog
---
drivers/cpuidle/cpuidle-big_little.c | 6 +-
1 file
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 schedule the work.
>
> This patch simply moves the poll
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 schedule the work.
>
> This patch simply moves the poll
701 - 800 of 1736 matches
Mail list logo
