On 29/11/2018 14:11, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.142 release.
> There are 92 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 know.
>
> Responses
On 29/11/2018 14:11, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.142 release.
> There are 92 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 know.
>
> Responses
On 26/11/2018 10:50, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.165 release.
> There are 70 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 know.
>
> Responses
On 26/11/2018 10:50, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.165 release.
> There are 70 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 know.
>
> Responses
On 26/11/2018 10:50, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.84 release.
> There are 62 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 know.
>
> Responses
On 26/11/2018 10:50, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.84 release.
> There are 62 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 know.
>
> Responses
On 26/11/2018 10:50, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.141 release.
> There are 46 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 know.
>
> Responses
On 26/11/2018 10:50, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.141 release.
> There are 46 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 know.
>
> Responses
On 26/11/2018 19:32, Tony Lindgren wrote:
> * Thierry Reding [181126 10:25]:
>> On Mon, Nov 26, 2018 at 11:49:54AM +0200, Peter Ujfalusi wrote:
>>> The register map documentation I have states the following:
>>> bit7 INT_POLARITY Select the polarity of the INT output line
>>> 0: Interrupt line
On 26/11/2018 19:32, Tony Lindgren wrote:
> * Thierry Reding [181126 10:25]:
>> On Mon, Nov 26, 2018 at 11:49:54AM +0200, Peter Ujfalusi wrote:
>>> The register map documentation I have states the following:
>>> bit7 INT_POLARITY Select the polarity of the INT output line
>>> 0: Interrupt line
On 23/11/2018 16:48, Tony Lindgren wrote:
> * Jon Hunter [181120 11:14]:
>> On 19/11/2018 17:14, Tony Lindgren wrote:
>>> Well so commit 7e9d474954f4 ("ARM: tegra: Correct polarity for
>>> Tegra114 PMIC interrupt") states that tegra114 inverts the
>>
On 23/11/2018 16:48, Tony Lindgren wrote:
> * Jon Hunter [181120 11:14]:
>> On 19/11/2018 17:14, Tony Lindgren wrote:
>>> Well so commit 7e9d474954f4 ("ARM: tegra: Correct polarity for
>>> Tegra114 PMIC interrupt") states that tegra114 inverts the
>>
On 21/11/2018 19:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.83 release.
> There are 21 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 know.
>
> Responses
On 21/11/2018 19:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.83 release.
> There are 21 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 know.
>
> Responses
On 21/11/2018 19:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.139 release.
> There are 59 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 know.
>
> Responses
On 21/11/2018 19:06, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.139 release.
> There are 59 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 know.
>
> Responses
On 21/11/2018 14:47, Frank Lee wrote:
> On Wed, Nov 21, 2018 at 10:43 PM Thierry Reding
> wrote:
>>
>> On Wed, Nov 21, 2018 at 02:34:57PM +, Jon Hunter wrote:
>>>
>>> On 21/11/2018 14:12, Yangtao Li wrote:
>>>> of_find_node_by_
On 21/11/2018 14:47, Frank Lee wrote:
> On Wed, Nov 21, 2018 at 10:43 PM Thierry Reding
> wrote:
>>
>> On Wed, Nov 21, 2018 at 02:34:57PM +, Jon Hunter wrote:
>>>
>>> On 21/11/2018 14:12, Yangtao Li wrote:
>>>> of_find_node_by_
On 21/11/2018 13:31, Jon Hunter wrote:
>
> On 21/11/2018 12:49, Yangtao Li wrote:
>> 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.
The b
On 21/11/2018 13:31, Jon Hunter wrote:
>
> On 21/11/2018 12:49, Yangtao Li wrote:
>> 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.
The b
On 21/11/2018 14:12, Yangtao Li wrote:
> of_find_node_by_path() acquires a reference to the node returned by
> it and that reference needs to be dropped by its caller.soc_is_tegra()
> doesn't do that, so fix it.Call of_machine_is_compatible() to refactor
> soc_is_tegra() whcih automatically
On 21/11/2018 14:12, Yangtao Li wrote:
> of_find_node_by_path() acquires a reference to the node returned by
> it and that reference needs to be dropped by its caller.soc_is_tegra()
> doesn't do that, so fix it.Call of_machine_is_compatible() to refactor
> soc_is_tegra() whcih automatically
On 21/11/2018 12:49, Yangtao Li wrote:
> 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
> ---
> drivers/soc/tegra/common.c | 5 -
> 1
On 21/11/2018 12:49, Yangtao Li wrote:
> 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
> ---
> drivers/soc/tegra/common.c | 5 -
> 1
On 19/11/2018 17:14, Tony Lindgren wrote:
> Hi,
>
> * Tony Lindgren [181119 16:19]:
>> * Peter Ujfalusi [181119 10:16]:
>>> On 2018-11-13 20:06, Tony Lindgren wrote:
Looks like the IRQ_TYPE_NONE issue still is there for omap5 and
should be fixed with IRQ_TYPE_HIGH.
No idea
On 19/11/2018 17:14, Tony Lindgren wrote:
> Hi,
>
> * Tony Lindgren [181119 16:19]:
>> * Peter Ujfalusi [181119 10:16]:
>>> On 2018-11-13 20:06, Tony Lindgren wrote:
Looks like the IRQ_TYPE_NONE issue still is there for omap5 and
should be fixed with IRQ_TYPE_HIGH.
No idea
On 19/11/2018 16:27, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.82 release.
> There are 124 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 know.
>
> Responses
On 19/11/2018 16:27, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.82 release.
> There are 124 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 know.
>
> Responses
On 19/11/2018 16:28, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.138 release.
> There are 83 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 know.
>
> Responses
On 19/11/2018 16:28, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.9.138 release.
> There are 83 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 know.
>
> Responses
On 19/11/2018 16:27, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.164 release.
> There are 160 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 know.
>
> Responses
On 19/11/2018 16:27, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.164 release.
> There are 160 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 know.
>
> Responses
0
> streq r1, [r0, #EMC_NOP]
> streq r1, [r0, #EMC_NOP]
> - streq r1, [r0, #EMC_REFRESH]
>
> emc_device_mask r1, r0
Acked-by: Jon Hunter
Tested-by: Jon Hunter
Cheers
Jon
--
nvpublic
0
> streq r1, [r0, #EMC_NOP]
> streq r1, [r0, #EMC_NOP]
> - streq r1, [r0, #EMC_REFRESH]
>
> emc_device_mask r1, r0
Acked-by: Jon Hunter
Tested-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 19/11/2018 22:35, Dmitry Osipenko wrote:
> On 20.11.2018 1:00, Jon Hunter wrote:
>>
>> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>>> Two interrupts are raised on resume from LP1 on Tegra30+: first is the
>>> clock change completed interrupt w
On 19/11/2018 22:35, Dmitry Osipenko wrote:
> On 20.11.2018 1:00, Jon Hunter wrote:
>>
>> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>>> Two interrupts are raised on resume from LP1 on Tegra30+: first is the
>>> clock change completed interrupt w
On 19/11/2018 22:32, Dmitry Osipenko wrote:
> On 20.11.2018 1:09, Dmitry Osipenko wrote:
>> On 20.11.2018 0:34, Jon Hunter wrote:
>>>
>>> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>>>> The DRAM refresh-interval is getting erroneously set to "1"
On 19/11/2018 22:32, Dmitry Osipenko wrote:
> On 20.11.2018 1:09, Dmitry Osipenko wrote:
>> On 20.11.2018 0:34, Jon Hunter wrote:
>>>
>>> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>>>> The DRAM refresh-interval is getting erroneously set to "1"
On 19/11/2018 22:09, Dmitry Osipenko wrote:
> On 20.11.2018 0:34, Jon Hunter wrote:
>>
>> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>>> The DRAM refresh-interval is getting erroneously set to "1" on exiting
>>> from memory self-refreshing mode. The
On 19/11/2018 22:09, Dmitry Osipenko wrote:
> On 20.11.2018 0:34, Jon Hunter wrote:
>>
>> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>>> The DRAM refresh-interval is getting erroneously set to "1" on exiting
>>> from memory self-refreshing mode. The
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> Two interrupts are raised on resume from LP1 on Tegra30+: first is the
> clock change completed interrupt which is set after updating timing
> configuration, second is DLL alarm interrupt which is set when DLL
> starts re-calibration after being
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> Two interrupts are raised on resume from LP1 on Tegra30+: first is the
> clock change completed interrupt which is set after updating timing
> configuration, second is DLL alarm interrupt which is set when DLL
> starts re-calibration after being
On 19/11/2018 21:27, Jon Hunter wrote:
>
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> The memory interface configuration and re-calibration interval are left
>> unassigned on resume from LP1 because these registers are shadowed and
>> require latching after being ad
On 19/11/2018 21:27, Jon Hunter wrote:
>
> On 30/08/2018 19:54, Dmitry Osipenko wrote:
>> The memory interface configuration and re-calibration interval are left
>> unassigned on resume from LP1 because these registers are shadowed and
>> require latching after being ad
ess:
> @@ -573,6 +593,7 @@ tegra124_sdram_pad_address:
> .word TEGRA_PMC_BASE + PMC_IO_DPD_STATUS @0x14
> .word TEGRA_CLK_RESET_BASE + CLK_RESET_CLK_SOURCE_MSELECT @0x18
> .word TEGRA_CLK_RESET_BASE + CLK_RESET_SCLK_BURST @0x1c
> + .word TEGRA124_MC_BASE + MC_EMEM_ARB_CFG @0x20
> tegra124_sdram_pad_address_end:
>
> tegra30_sdram_pad_size:
>
Acked-by: Jon Hunter
Tested-by: Jon Hunter
--
nvpublic
ess:
> @@ -573,6 +593,7 @@ tegra124_sdram_pad_address:
> .word TEGRA_PMC_BASE + PMC_IO_DPD_STATUS @0x14
> .word TEGRA_CLK_RESET_BASE + CLK_RESET_CLK_SOURCE_MSELECT @0x18
> .word TEGRA_CLK_RESET_BASE + CLK_RESET_SCLK_BURST @0x1c
> + .word TEGRA124_MC_BASE + MC_EMEM_ARB_CFG @0x20
> tegra124_sdram_pad_address_end:
>
> tegra30_sdram_pad_size:
>
Acked-by: Jon Hunter
Tested-by: Jon Hunter
--
nvpublic
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The DRAM refresh-interval is getting erroneously set to "1" on exiting
> from memory self-refreshing mode. The clobbered interval causes the
> "refresh request overflow timeout" error raised by the External Memory
> Controller on exiting from LP1 on
On 30/08/2018 19:54, Dmitry Osipenko wrote:
> The DRAM refresh-interval is getting erroneously set to "1" on exiting
> from memory self-refreshing mode. The clobbered interval causes the
> "refresh request overflow timeout" error raised by the External Memory
> Controller on exiting from LP1 on
; cmp r10, #TEGRA114
> bne __no_dual_emc_chanl
>
This is stated in the TRM as what needs to be done. So ...
Reviewed-by: Jon Hunter
Cheers
Jon
--
nvpublic
; cmp r10, #TEGRA114
> bne __no_dual_emc_chanl
>
This is stated in the TRM as what needs to be done. So ...
Reviewed-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 19/11/2018 17:05, Dmitry Osipenko wrote:
> On 19.11.2018 18:42, Jon Hunter wrote:
>>
>> On 18/11/2018 22:06, Dmitry Osipenko wrote:
>>> On 30.08.2018 21:54, Dmitry Osipenko wrote:
>>>> Hello,
>>>>
>>>> This patch series fixes co
On 19/11/2018 17:05, Dmitry Osipenko wrote:
> On 19.11.2018 18:42, Jon Hunter wrote:
>>
>> On 18/11/2018 22:06, Dmitry Osipenko wrote:
>>> On 30.08.2018 21:54, Dmitry Osipenko wrote:
>>>> Hello,
>>>>
>>>> This patch series fixes co
On 18/11/2018 22:06, Dmitry Osipenko wrote:
> On 30.08.2018 21:54, Dmitry Osipenko wrote:
>> Hello,
>>
>> This patch series fixes couple bugs in the memory self-refresh code.
>> The EMC / MC state is properly restored after patches being applied,
>> please review.
>>
>> Dmitry Osipenko (4):
>>
On 18/11/2018 22:06, Dmitry Osipenko wrote:
> On 30.08.2018 21:54, Dmitry Osipenko wrote:
>> Hello,
>>
>> This patch series fixes couple bugs in the memory self-refresh code.
>> The EMC / MC state is properly restored after patches being applied,
>> please review.
>>
>> Dmitry Osipenko (4):
>>
void);
> int tegra_fuse_readl(unsigned long offset, u32 *value);
>
> extern struct tegra_sku_info tegra_sku_info;
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
void);
> int tegra_fuse_readl(unsigned long offset, u32 *value);
>
> extern struct tegra_sku_info tegra_sku_info;
Acked-by: Jon Hunter
Cheers
Jon
--
nvpublic
On 13/11/2018 13:21, Jon Hunter wrote:
...
>> IMHO the best fix here would be to modify efivar_entry_size(),
>> adding:
>>
>> if (!ops)
>> return -ENOENT;
>>
>> Which makes it return the same error as when we do have efivar
>>
On 13/11/2018 13:21, Jon Hunter wrote:
...
>> IMHO the best fix here would be to modify efivar_entry_size(),
>> adding:
>>
>> if (!ops)
>> return -ENOENT;
>>
>> Which makes it return the same error as when we do have efivar
>>
Hi Arend,
On 13/11/2018 10:24, Arend van Spriel wrote:
...
> I tried building drivers/firmware/efi/vars.c using tegra_defconfig. Had
> to enable CONFIG_EFI. So the null pointer access is a 0x0008 so I
> looked at the disassembly below:
>
> int efivar_entry_size(struct efivar_entry *entry,
Hi Arend,
On 13/11/2018 10:24, Arend van Spriel wrote:
...
> I tried building drivers/firmware/efi/vars.c using tegra_defconfig. Had
> to enable CONFIG_EFI. So the null pointer access is a 0x0008 so I
> looked at the disassembly below:
>
> int efivar_entry_size(struct efivar_entry *entry,
it on resuming from
suspend.
Cc: sta...@vger.kernel.org
Signed-off-by: Jon Hunter
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
---
drivers/mfd/tps6586x.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd
it on resuming from
suspend.
Cc: sta...@vger.kernel.org
Signed-off-by: Jon Hunter
Reviewed-by: Dmitry Osipenko
Tested-by: Dmitry Osipenko
Acked-by: Thierry Reding
---
drivers/mfd/tps6586x.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd
On 11/11/2018 22:21, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.81 release.
> There are 222 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 know.
>
> Responses
On 11/11/2018 22:21, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.81 release.
> There are 222 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 know.
>
> Responses
Hi Lee,
On 19/10/2018 14:22, Jon Hunter wrote:
> From: Jonathan Hunter
>
> The tps6586x driver creates an irqchip that is used by its various child
> devices for managing interrupts. The tps6586x-rtc device is one of its
> children that uses the tps6586x irqchip. When using t
Hi Lee,
On 19/10/2018 14:22, Jon Hunter wrote:
> From: Jonathan Hunter
>
> The tps6586x driver creates an irqchip that is used by its various child
> devices for managing interrupts. The tps6586x-rtc device is one of its
> children that uses the tps6586x irqchip. When using t
On 03/11/2018 15:04, Greg Kroah-Hartman wrote:
> On Sat, Nov 03, 2018 at 07:31:42AM -0700, Guenter Roeck wrote:
>> On 11/2/18 11:33 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.14.79 release.
>>> There are 143 patches in this series, all will be posted
On 03/11/2018 15:04, Greg Kroah-Hartman wrote:
> On Sat, Nov 03, 2018 at 07:31:42AM -0700, Guenter Roeck wrote:
>> On 11/2/18 11:33 AM, Greg Kroah-Hartman wrote:
>>> This is the start of the stable review cycle for the 4.14.79 release.
>>> There are 143 patches in this series, all will be posted
On 30/10/2018 04:32, Masahiro Yamada wrote:
> Instead of specifying target/source pairs, let's list patterns that we
> want to handle as single targets. This slightly changes the behavior;
> the top Makefile previously checked the presence of a source file,
> now Kbuild will descend into a
On 30/10/2018 04:32, Masahiro Yamada wrote:
> Instead of specifying target/source pairs, let's list patterns that we
> want to handle as single targets. This slightly changes the behavior;
> the top Makefile previously checked the presence of a source file,
> now Kbuild will descend into a
On 29/10/2018 09:25, Ashish Mhetre wrote:
> From: Alex Van Brunt
>
> Accessed bit is used to age a page and in generic implementation there is
> flush_tlb while clearing the accessed bit.
> Flushing a TLB is overhead on ARM64 as access flag faults don't get
> translation table entries cached
On 29/10/2018 09:25, Ashish Mhetre wrote:
> From: Alex Van Brunt
>
> Accessed bit is used to age a page and in generic implementation there is
> flush_tlb while clearing the accessed bit.
> Flushing a TLB is overhead on ARM64 as access flag faults don't get
> translation table entries cached
On 24/10/2018 13:44, Dmitry Osipenko wrote:
> On 10/24/18 1:49 PM, Jon Hunter wrote:
>>
>> On 22/10/2018 12:19, Dmitry Osipenko wrote:
>>> On 10/22/18 12:52 PM, Thierry Reding wrote:
>>>> On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunte
On 24/10/2018 13:44, Dmitry Osipenko wrote:
> On 10/24/18 1:49 PM, Jon Hunter wrote:
>>
>> On 22/10/2018 12:19, Dmitry Osipenko wrote:
>>> On 10/22/18 12:52 PM, Thierry Reding wrote:
>>>> On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunte
On 24/10/2018 11:44, Dmitry Osipenko wrote:
> On 10/24/18 1:20 PM, Jon Hunter wrote:
>>
>> On 21/10/2018 19:36, Dmitry Osipenko wrote:
>>> This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
>>> and machine (Tegra30) booted with SMP=n or all se
On 24/10/2018 11:44, Dmitry Osipenko wrote:
> On 10/24/18 1:20 PM, Jon Hunter wrote:
>>
>> On 21/10/2018 19:36, Dmitry Osipenko wrote:
>>> This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
>>> and machine (Tegra30) booted with SMP=n or all se
On 22/10/2018 12:19, Dmitry Osipenko wrote:
> On 10/22/18 12:52 PM, Thierry Reding wrote:
>> On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunter wrote:
>>> From: Jonathan Hunter
>>>
>>> The tps6586x driver creates an irqchip that is used by its various child
On 22/10/2018 12:19, Dmitry Osipenko wrote:
> On 10/22/18 12:52 PM, Thierry Reding wrote:
>> On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunter wrote:
>>> From: Jonathan Hunter
>>>
>>> The tps6586x driver creates an irqchip that is used by its various child
On 22/10/2018 10:52, Thierry Reding wrote:
> On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunter wrote:
>> From: Jonathan Hunter
>>
>> The tps6586x driver creates an irqchip that is used by its various child
>> devices for managing interrupts. The tps6586x-rtc devic
On 22/10/2018 10:52, Thierry Reding wrote:
> On Fri, Oct 19, 2018 at 02:22:53PM +0100, Jon Hunter wrote:
>> From: Jonathan Hunter
>>
>> The tps6586x driver creates an irqchip that is used by its various child
>> devices for managing interrupts. The tps6586x-rtc devic
On 21/10/2018 19:36, Dmitry Osipenko wrote:
> This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
> and machine (Tegra30) booted with SMP=n or all secondary CPU's are put
> offline. Locking isn't needed because it protects atomic operation.
>
> # echo 0 | tee
On 21/10/2018 19:36, Dmitry Osipenko wrote:
> This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
> and machine (Tegra30) booted with SMP=n or all secondary CPU's are put
> offline. Locking isn't needed because it protects atomic operation.
>
> # echo 0 | tee
On 18/10/2018 18:54, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.162 release.
> There are 48 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 know.
>
> Responses
On 18/10/2018 18:54, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.162 release.
> There are 48 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 know.
>
> Responses
On 18/10/2018 18:54, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.78 release.
> There are 41 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 know.
>
> Responses
On 18/10/2018 18:54, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.78 release.
> There are 41 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 know.
>
> Responses
it on resuming from
suspend.
Cc: sta...@vger.kernel.org
Signed-off-by: Jon Hunter
---
drivers/mfd/tps6586x.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index b89379782741..9c7925ca13cf 100644
--- a/drivers/mfd/tps6586x.c
it on resuming from
suspend.
Cc: sta...@vger.kernel.org
Signed-off-by: Jon Hunter
---
drivers/mfd/tps6586x.c | 24
1 file changed, 24 insertions(+)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index b89379782741..9c7925ca13cf 100644
--- a/drivers/mfd/tps6586x.c
On 15/10/2018 14:52, Dmitry Osipenko wrote:
> On 10/15/18 3:52 PM, Jon Hunter wrote:
>>
>> On 30/08/18 19:36, Dmitry Osipenko wrote:
>>> This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
>>> and machine (Tegra30) booted with SMP=n or all se
On 15/10/2018 14:52, Dmitry Osipenko wrote:
> On 10/15/18 3:52 PM, Jon Hunter wrote:
>>
>> On 30/08/18 19:36, Dmitry Osipenko wrote:
>>> This fixes splats like the one below if CONFIG_DEBUG_ATOMIC_SLEEP=y
>>> and machine (Tegra30) booted with SMP=n or all se
On 18/10/2018 12:18, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This fixes the following error as seen post commit daecf46ee0e5
> ("ASoC: soc-core: use snd_soc_dai_link_component for platform") on
> Apalis TK1 after initial probe deferral:
>
> tegra-snd-sgtl5000 sound: ASoC: Both
On 18/10/2018 12:18, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> This fixes the following error as seen post commit daecf46ee0e5
> ("ASoC: soc-core: use snd_soc_dai_link_component for platform") on
> Apalis TK1 after initial probe deferral:
>
> tegra-snd-sgtl5000 sound: ASoC: Both
On 16/10/2018 18:04, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.77 release.
> There are 109 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 know.
>
> Responses
On 16/10/2018 18:04, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.77 release.
> There are 109 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 know.
>
> Responses
On 17/10/2018 20:16, Mark Brown wrote:
> On Wed, Oct 17, 2018 at 02:28:22PM +, Marcel Ziswiler wrote:
>
>> Some questions:
>
>> - How exactly are devm allocations supposed to work concerning probe
>> deferrals?
>
> Probe deferrals are just normal probe errors, any devm_ allocated stuff
>
On 17/10/2018 20:16, Mark Brown wrote:
> On Wed, Oct 17, 2018 at 02:28:22PM +, Marcel Ziswiler wrote:
>
>> Some questions:
>
>> - How exactly are devm allocations supposed to work concerning probe
>> deferrals?
>
> Probe deferrals are just normal probe errors, any devm_ allocated stuff
>
On 17/10/2018 15:30, Dmitry Osipenko wrote:
> On 10/17/18 4:59 PM, Jon Hunter wrote:
>>
>> On 13/05/2018 22:13, Dmitry Osipenko wrote:
>>> Nothing prevents I2C clients to access I2C while Tegra's driver is being
>>> suspended, this results in -EBUSY error returne
On 17/10/2018 15:30, Dmitry Osipenko wrote:
> On 10/17/18 4:59 PM, Jon Hunter wrote:
>>
>> On 13/05/2018 22:13, Dmitry Osipenko wrote:
>>> Nothing prevents I2C clients to access I2C while Tegra's driver is being
>>> suspended, this results in -EBUSY error returne
On 17/10/2018 15:43, Dmitry Osipenko wrote:
> On 10/17/18 5:14 PM, Jon Hunter wrote:
>>
>> On 17/10/2018 14:46, Dmitry Osipenko wrote:
>>> On 10/17/18 4:34 PM, Jon Hunter wrote:
>>>>
>>>> On 17/10/2018 14:07, Dmitry Osipenko wrote:
>>>>
On 17/10/2018 15:43, Dmitry Osipenko wrote:
> On 10/17/18 5:14 PM, Jon Hunter wrote:
>>
>> On 17/10/2018 14:46, Dmitry Osipenko wrote:
>>> On 10/17/18 4:34 PM, Jon Hunter wrote:
>>>>
>>>> On 17/10/2018 14:07, Dmitry Osipenko wrote:
>>>>
801 - 900 of 3084 matches
Mail list logo
