On Thu, Sep 14, 2017 at 12:26:27PM -0500, Josh Poimboeuf wrote:
> On Thu, Sep 14, 2017 at 10:16:08AM -0700, Linus Torvalds wrote:
> > On Thu, Sep 14, 2017 at 7:48 AM, Josh Poimboeuf wrote:
> > >
> > > As it turns out, the real problem with this option is that it imposes a
> >
On Thu, Sep 14, 2017 at 12:26:27PM -0500, Josh Poimboeuf wrote:
> On Thu, Sep 14, 2017 at 10:16:08AM -0700, Linus Torvalds wrote:
> > On Thu, Sep 14, 2017 at 7:48 AM, Josh Poimboeuf wrote:
> > >
> > > As it turns out, the real problem with this option is that it imposes a
> > > penalty for
Richard Guy Briggs writes:
> The trigger is a pseudo filesystem (proc, since PID tree already exists)
> write of a u64 representing the container ID to a file representing a
> process that will become the first process in a new container.
> This might place restrictions on mount
Richard Guy Briggs writes:
> The trigger is a pseudo filesystem (proc, since PID tree already exists)
> write of a u64 representing the container ID to a file representing a
> process that will become the first process in a new container.
> This might place restrictions on mount namespaces
I am not sure that this is generally useful at OOM times unless this is
not a rare occurrence.
Certainly information like that would create more support for making
objects movable.
I am not sure that this is generally useful at OOM times unless this is
not a rare occurrence.
Certainly information like that would create more support for making
objects movable.
On Wed, Sep 13, 2017 at 2:34 PM, Pavel Machek wrote:
>
> On Wed 2017-09-13 14:20:58, David Lin wrote:
> > On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek wrote:
> > >
> > > Hi!
> > >
> > > > These patch series add the LED_BRIGHTNESS_FAST flag support for
> > > >
On Wed, Sep 13, 2017 at 2:34 PM, Pavel Machek wrote:
>
> On Wed 2017-09-13 14:20:58, David Lin wrote:
> > On Wed, Sep 13, 2017 at 1:20 PM, Pavel Machek wrote:
> > >
> > > Hi!
> > >
> > > > These patch series add the LED_BRIGHTNESS_FAST flag support for
> > > > ledtrig-transient to use hrtimer so
Well /proc/slabinfo is a legacy interface. The infomation if a slab is
reclaimable is available via the slabinfo tool. We would break a format
that is relied upon by numerous tools.
Well /proc/slabinfo is a legacy interface. The infomation if a slab is
reclaimable is available via the slabinfo tool. We would break a format
that is relied upon by numerous tools.
The patch
ASoC: rockchip: i2s: fix unbalanced clk_disable
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
The patch
ASoC: rockchip: i2s: fix unbalanced clk_disable
has been applied to the asoc tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent
Acked-by: Christoph Lameter
Acked-by: Christoph Lameter
On Thu, Sep 14, 2017 at 10:16:08AM -0700, Linus Torvalds wrote:
> On Thu, Sep 14, 2017 at 7:48 AM, Josh Poimboeuf wrote:
> >
> > As it turns out, the real problem with this option is that it imposes a
> > penalty for CONFIG_FRAME_POINTER=n: even with frame pointers disabled,
On Thu, Sep 14, 2017 at 10:16:08AM -0700, Linus Torvalds wrote:
> On Thu, Sep 14, 2017 at 7:48 AM, Josh Poimboeuf wrote:
> >
> > As it turns out, the real problem with this option is that it imposes a
> > penalty for CONFIG_FRAME_POINTER=n: even with frame pointers disabled,
> > it forces the
On 09/11/2017 07:46 PM, kernel test robot wrote:
> FYI, we noticed the following commit:
>
> commit: 05aa90edc7910ec3d1ed791fa77371b3acb9bf08 ("x86/topology: Avoid
> wasting 128k for package id array")
> url:
>
On 09/11/2017 07:46 PM, kernel test robot wrote:
> FYI, we noticed the following commit:
>
> commit: 05aa90edc7910ec3d1ed791fa77371b3acb9bf08 ("x86/topology: Avoid
> wasting 128k for package id array")
> url:
>
On 14/09/2017 at 19:00:13 +0200, Nicolas Ferre wrote:
> On 14/09/2017 at 16:28, Claudiu Beznea wrote:
> > Hi,
> >
> > This series contains fixes for SAMA5D27 SoM1 EK board. It would be
> > good if we will have this in 4.14 version.
> >
> > Thank you,
> > Claudiu
> >
> > Ludovic Desroches (2):
>
On 14/09/2017 at 19:00:13 +0200, Nicolas Ferre wrote:
> On 14/09/2017 at 16:28, Claudiu Beznea wrote:
> > Hi,
> >
> > This series contains fixes for SAMA5D27 SoM1 EK board. It would be
> > good if we will have this in 4.14 version.
> >
> > Thank you,
> > Claudiu
> >
> > Ludovic Desroches (2):
>
On Thu, Sep 14, 2017 at 7:48 AM, Josh Poimboeuf wrote:
>
> As it turns out, the real problem with this option is that it imposes a
> penalty for CONFIG_FRAME_POINTER=n: even with frame pointers disabled,
> it forces the frame pointer to be saved for each function which uses
On Thu, Sep 14, 2017 at 7:48 AM, Josh Poimboeuf wrote:
>
> As it turns out, the real problem with this option is that it imposes a
> penalty for CONFIG_FRAME_POINTER=n: even with frame pointers disabled,
> it forces the frame pointer to be saved for each function which uses the
> inline asm
Recently we ran into a oom issue, kernel panic due to no killable process.
The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump
doesn't capture vmcore due to some reason.
So, it may sound better to capture unreclaimable slab info in oom message when
kernel panic to aid
Recently we ran into a oom issue, kernel panic due to no killable process.
The dmesg shows huge unreclaimable slabs used almost 100% memory, but kdump
doesn't capture vmcore due to some reason.
So, it may sound better to capture unreclaimable slab info in oom message when
kernel panic to aid
Although slabinfo in tools can print out the flag of slabs to show which
one is reclaimable, it sounds nice to have reclaimable flag shows in
/proc/slabinfo too since /proc should be still the first place to check
those slab info.
Add a new column called "reclaim" in /proc/slabinfo, "1" means
Although slabinfo in tools can print out the flag of slabs to show which
one is reclaimable, it sounds nice to have reclaimable flag shows in
/proc/slabinfo too since /proc should be still the first place to check
those slab info.
Add a new column called "reclaim" in /proc/slabinfo, "1" means
Kernel may panic when oom happens without killable process sometimes it
is
caused by huge unreclaimable slabs used by kernel.
Altough kdump could help debug such problem, however, kdump is not
available on all architectures and it might be malfunction sometime.
And, since kernel already panic it
Kernel may panic when oom happens without killable process sometimes it
is
caused by huge unreclaimable slabs used by kernel.
Altough kdump could help debug such problem, however, kdump is not
available on all architectures and it might be malfunction sometime.
And, since kernel already panic it
Add "-U" option to show unreclaimable slabs only.
"-U" and "-S" together can tell us what unreclaimable slabs use the most
memory to help debug huge unreclaimable slabs issue.
Signed-off-by: Yang Shi
---
tools/vm/slabinfo.c | 11 ++-
1 file changed, 10
Add "-U" option to show unreclaimable slabs only.
"-U" and "-S" together can tell us what unreclaimable slabs use the most
memory to help debug huge unreclaimable slabs issue.
Signed-off-by: Yang Shi
---
tools/vm/slabinfo.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
Great change, just some suggestions ...
On Thu, Sep 14, 2017 at 10:00 AM, Rik van Riel wrote:
> Add MADV_WIPEONFORK and MADV_KEEPONFORK documentation to
> madvise.2. The new functionality was recently merged by
> Linus, and should be in the 4.14 kernel.
>
> While documenting
Great change, just some suggestions ...
On Thu, Sep 14, 2017 at 10:00 AM, Rik van Riel wrote:
> Add MADV_WIPEONFORK and MADV_KEEPONFORK documentation to
> madvise.2. The new functionality was recently merged by
> Linus, and should be in the 4.14 kernel.
>
> While documenting what EINVAL means
On Thu, Sep 14 2017 at 10:57:28 am BST, Eric Auger
wrote:
> At the moment, the in-kernel emulated ITS is not properly reset.
> On guest restart/reset some registers keep their old values and
> internal structures like device, ITE, collection lists are not emptied.
>
> This
On Thu, Sep 14 2017 at 10:57:28 am BST, Eric Auger
wrote:
> At the moment, the in-kernel emulated ITS is not properly reset.
> On guest restart/reset some registers keep their old values and
> internal structures like device, ITE, collection lists are not emptied.
>
> This may lead to various
On Thu, Sep 14, 2017 at 9:50 AM, Tim Chen wrote:
>
> Kan tested this before so it should be still good.
> I checked that it applied cleanly on latest master.
Thanks, applied.
I really hope we end up fixing the migration thing too, but at least
4.14 will have the
On Thu, Sep 14, 2017 at 9:50 AM, Tim Chen wrote:
>
> Kan tested this before so it should be still good.
> I checked that it applied cleanly on latest master.
Thanks, applied.
I really hope we end up fixing the migration thing too, but at least
4.14 will have the mitigation for the long wait
From: Colin King
Date: Thu, 14 Sep 2017 17:01:25 +0100
> From: Colin Ian King
>
> tnapi is being initialized and then immediately updated and
> hence the initialiation is redundant. Clean up the warning
> by moving the declaration and
From: Colin King
Date: Thu, 14 Sep 2017 17:01:25 +0100
> From: Colin Ian King
>
> tnapi is being initialized and then immediately updated and
> hence the initialiation is redundant. Clean up the warning
> by moving the declaration and initialization to the inside
> of the for-loop.
>
>
Add MADV_WIPEONFORK and MADV_KEEPONFORK documentation to
madvise.2. The new functionality was recently merged by
Linus, and should be in the 4.14 kernel.
While documenting what EINVAL means for MADV_WIPEONFORK,
I realized that MADV_FREE has the same thing going on,
so I documented EINVAL for
Add MADV_WIPEONFORK and MADV_KEEPONFORK documentation to
madvise.2. The new functionality was recently merged by
Linus, and should be in the 4.14 kernel.
While documenting what EINVAL means for MADV_WIPEONFORK,
I realized that MADV_FREE has the same thing going on,
so I documented EINVAL for
On 14/09/2017 at 16:28, Claudiu Beznea wrote:
> Hi,
>
> This series contains fixes for SAMA5D27 SoM1 EK board. It would be
> good if we will have this in 4.14 version.
>
> Thank you,
> Claudiu
>
> Ludovic Desroches (2):
> ARM: dts: at91: sama5d27_som1_ek: update pinmux/pinconf for LEDs and
>
On 14/09/2017 at 16:28, Claudiu Beznea wrote:
> Hi,
>
> This series contains fixes for SAMA5D27 SoM1 EK board. It would be
> good if we will have this in 4.14 version.
>
> Thank you,
> Claudiu
>
> Ludovic Desroches (2):
> ARM: dts: at91: sama5d27_som1_ek: update pinmux/pinconf for LEDs and
>
On 09/13/2017 07:37 PM, Masahiro Yamada wrote:
This driver implements .alloc() hook, so .map() is not used.
Have you tested this?
I will have to test this on a real system next week before I can really
comment on it.
David.
Signed-off-by: Masahiro Yamada
On 09/13/2017 07:37 PM, Masahiro Yamada wrote:
This driver implements .alloc() hook, so .map() is not used.
Have you tested this?
I will have to test this on a real system next week before I can really
comment on it.
David.
Signed-off-by: Masahiro Yamada
---
On Wed 13 Sep 09:04 PDT 2017, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla
>
> All Qualcomm PIL drivers require SMP2P module to get a functional PIL,
> Currently user has to explicitly select SMP2P module, after looking
> at failure logs.
>
On Wed 13 Sep 09:04 PDT 2017, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla
>
> All Qualcomm PIL drivers require SMP2P module to get a functional PIL,
> Currently user has to explicitly select SMP2P module, after looking
> at failure logs.
>
> Fix this by selecting SMP2P as
On 09/14/2017 05:24 PM, Geert Uytterhoeven wrote:
Hi Ludovic,
On Thu, Sep 14, 2017 at 5:13 PM, Ludovic BARRE wrote:
On 09/14/2017 03:38 PM, Geert Uytterhoeven wrote:
On Thu, Sep 14, 2017 at 1:06 PM, Arnd Bergmann wrote:
If we send zero-length data to
On 09/14/2017 05:24 PM, Geert Uytterhoeven wrote:
Hi Ludovic,
On Thu, Sep 14, 2017 at 5:13 PM, Ludovic BARRE wrote:
On 09/14/2017 03:38 PM, Geert Uytterhoeven wrote:
On Thu, Sep 14, 2017 at 1:06 PM, Arnd Bergmann wrote:
If we send zero-length data to stm32_qspi_tx_poll() on older
On 09/14/17 06:26, Michael Kerrisk (man-pages) wrote:
> Hello Joe,
>
> On 5 September 2017 at 16:44, Joe Lawrence wrote:
>> While backporting Michael's "pipe: fix limit handling" [1] patchset to a
>> distro-kernel, Mikulas noticed that current upstream pipe limit
On 09/14/17 06:26, Michael Kerrisk (man-pages) wrote:
> Hello Joe,
>
> On 5 September 2017 at 16:44, Joe Lawrence wrote:
>> While backporting Michael's "pipe: fix limit handling" [1] patchset to a
>> distro-kernel, Mikulas noticed that current upstream pipe limit handling
>> contains a few
2017-09-14 03:54-0700, Wanpeng Li:
> From: Wanpeng Li
>
> qemu-system-x86-8600 [004] d..1 7205.687530: kvm_entry: vcpu 2
> qemu-system-x86-8600 [004] 7205.687532: kvm_exit: reason EXCEPTION_NMI
> rip 0xa921297d info eb2c0e44e018 8b0e
>
2017-09-14 03:54-0700, Wanpeng Li:
> From: Wanpeng Li
>
> qemu-system-x86-8600 [004] d..1 7205.687530: kvm_entry: vcpu 2
> qemu-system-x86-8600 [004] 7205.687532: kvm_exit: reason EXCEPTION_NMI
> rip 0xa921297d info eb2c0e44e018 8b0e
> qemu-system-x86-8600 [004]
On 09/13/2017 07:27 PM, Linus Torvalds wrote:
> On Wed, Sep 13, 2017 at 7:12 PM, Tim Chen wrote:
>>
>> BTW, will you be merging these 2 patches in 4.14?
>
> Yes, and thanks for reminding me.
>
> In fact, would you mind sending me the latest versions, rather than me
>
On 09/13/2017 07:27 PM, Linus Torvalds wrote:
> On Wed, Sep 13, 2017 at 7:12 PM, Tim Chen wrote:
>>
>> BTW, will you be merging these 2 patches in 4.14?
>
> Yes, and thanks for reminding me.
>
> In fact, would you mind sending me the latest versions, rather than me
> digging them out of the
On Thu, 14 Sep 2017, Andy Lutomirski wrote:
On Wed, Sep 13, 2017 at 5:59 AM, Thomas Voegtle wrote:
On Sun, 10 Sep 2017, Andy Lutomirski wrote:
On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel
wrote:
Dear Linux folks,
With Linux built from commit
On Thu, 14 Sep 2017, Andy Lutomirski wrote:
On Wed, Sep 13, 2017 at 5:59 AM, Thomas Voegtle wrote:
On Sun, 10 Sep 2017, Andy Lutomirski wrote:
On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel
wrote:
Dear Linux folks,
With Linux built from commit 4dfc2788033d (Merge tag
On Tue, Sep 12, 2017 at 6:18 AM, Sergey Senozhatsky
wrote:
> Hi Andy,
>
> got the following warn for each CPU
>
>
> [0.00] [ cut here ]
> [0.00] WARNING: CPU: 0 PID: 0 at arch/x86/mm/tlb.c:245
>
On Tue, Sep 12, 2017 at 6:18 AM, Sergey Senozhatsky
wrote:
> Hi Andy,
>
> got the following warn for each CPU
>
>
> [0.00] [ cut here ]
> [0.00] WARNING: CPU: 0 PID: 0 at arch/x86/mm/tlb.c:245
> initialize_tlbstate_and_flush+0x60/0xd4
> [0.00]
On Wed, Sep 13, 2017 at 5:59 AM, Thomas Voegtle wrote:
> On Sun, 10 Sep 2017, Andy Lutomirski wrote:
>
>> On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel
>> wrote:
>>>
>>> Dear Linux folks,
>>>
>>>
>>> With Linux built from commit 4dfc2788033d (Merge tag
>>>
On Wed, Sep 13, 2017 at 5:59 AM, Thomas Voegtle wrote:
> On Sun, 10 Sep 2017, Andy Lutomirski wrote:
>
>> On Sat, Sep 9, 2017 at 11:48 PM, Paul Menzel
>> wrote:
>>>
>>> Dear Linux folks,
>>>
>>>
>>> With Linux built from commit 4dfc2788033d (Merge tag
>>> 'iommu-updates-v4.14'
>>> of
On Thu, Sep 14, 2017 at 10:57:28AM +0200, Eric Auger wrote:
> At the moment, the in-kernel emulated ITS is not properly reset.
> On guest restart/reset some registers keep their old values and
> internal structures like device, ITE, collection lists are not emptied.
>
> This may lead to various
On Thu, Sep 14, 2017 at 10:57:28AM +0200, Eric Auger wrote:
> At the moment, the in-kernel emulated ITS is not properly reset.
> On guest restart/reset some registers keep their old values and
> internal structures like device, ITE, collection lists are not emptied.
>
> This may lead to various
On Thu, Sep 14, 2017 at 9:00 AM, Thomas Gleixner wrote:
> On Thu, 14 Sep 2017, Andy Lutomirski wrote:
>> On Thu, Sep 14, 2017 at 12:38 AM, Thomas Gleixner wrote:
>> > Hi!
>> >
>> > I've seen the following crash sporadically with commit 46c1e79fee:
>> >
>>
On Thu, Sep 14, 2017 at 9:00 AM, Thomas Gleixner wrote:
> On Thu, 14 Sep 2017, Andy Lutomirski wrote:
>> On Thu, Sep 14, 2017 at 12:38 AM, Thomas Gleixner wrote:
>> > Hi!
>> >
>> > I've seen the following crash sporadically with commit 46c1e79fee:
>> >
>> > Have not seen that with 3882a734c19b,
Le 12/09/2017 à 15:12, Boris Brezillon a écrit :
> Hi Geert,
>
> On Mon, 11 Sep 2017 10:58:36 +0200
> Geert Uytterhoeven wrote:
>
>> Hi Cyrille,
>>
>> On Thu, Sep 7, 2017 at 9:28 PM, Cyrille Pitchen
>> wrote:
Can you apply this patch on
Le 12/09/2017 à 15:12, Boris Brezillon a écrit :
> Hi Geert,
>
> On Mon, 11 Sep 2017 10:58:36 +0200
> Geert Uytterhoeven wrote:
>
>> Hi Cyrille,
>>
>> On Thu, Sep 7, 2017 at 9:28 PM, Cyrille Pitchen
>> wrote:
Can you apply this patch on your tree then report me what was printed,
On Sep 14, 2017, at 9:04 AM, ChunYu Wang wrote:
>
> Hi GeneBlue,
>
> Thanks for this reporting, do you have any logs related to the bug and
> could find the syscalls enabled for fuzzing during triggering this
> bug? I do not think it is not reproducible, but first, it needs
On Sep 14, 2017, at 9:04 AM, ChunYu Wang wrote:
>
> Hi GeneBlue,
>
> Thanks for this reporting, do you have any logs related to the bug and
> could find the syscalls enabled for fuzzing during triggering this
> bug? I do not think it is not reproducible, but first, it needs some
> inspections
On Wed, 13 Sep 2017, Tim Chen wrote:
> Here's what the customer think happened and is willing to tell us.
> They have a parent process that spawns off 10 children per core and
> kicked them to run. The child processes all access a common library.
> We have 384 cores so 3840 child processes
On Wed, 13 Sep 2017, Tim Chen wrote:
> Here's what the customer think happened and is willing to tell us.
> They have a parent process that spawns off 10 children per core and
> kicked them to run. The child processes all access a common library.
> We have 384 cores so 3840 child processes
Hi Juergen,
On Thu, Sep 14, 2017 at 02:38:58PM +0200, Juergen Gross wrote:
> xenbus_client.c contains some functions specific for pv guests.
> Enclose them with #ifdef CONFIG_XEN_PV to avoid compiling them when
> they are not needed (e.g. on ARM).
>
> Signed-off-by: Juergen Gross
Hi Juergen,
On Thu, Sep 14, 2017 at 02:38:58PM +0200, Juergen Gross wrote:
> xenbus_client.c contains some functions specific for pv guests.
> Enclose them with #ifdef CONFIG_XEN_PV to avoid compiling them when
> they are not needed (e.g. on ARM).
>
> Signed-off-by: Juergen Gross
Thanks for
On 09/13/2017 09:33 AM, Thomas Gleixner wrote:
> On Wed, 13 Sep 2017, Kashyap Desai wrote:
>>> On 09/12/2017 08:15 PM, YASUAKI ISHIMATSU wrote:
+ linux-scsi and maintainers of megasas
>
> In my server, IRQ#66-89 are sent to CPU#24-29. And if I offline
> CPU#24-29, I/O does not
On 09/13/2017 09:33 AM, Thomas Gleixner wrote:
> On Wed, 13 Sep 2017, Kashyap Desai wrote:
>>> On 09/12/2017 08:15 PM, YASUAKI ISHIMATSU wrote:
+ linux-scsi and maintainers of megasas
>
> In my server, IRQ#66-89 are sent to CPU#24-29. And if I offline
> CPU#24-29, I/O does not
From: "Kristian H. Kristensen"
[ Upstream commit af913418261d6d3e7a29f06cf35f04610ead667c ]
We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code()
macro to work correctly.
Signed-off-by: Kristian H. Kristensen
Signed-off-by: Daniel
From: "Kristian H. Kristensen"
[ Upstream commit af913418261d6d3e7a29f06cf35f04610ead667c ]
We need to define DRM_FORMAT_MOD_VENDOR_NONE for the fourcc_mod_code()
macro to work correctly.
Signed-off-by: Kristian H. Kristensen
Signed-off-by: Daniel Vetter
Link:
From: Guilherme G Piccoli
[ Upstream commit 69b97cf6dbce7403845a28bbc75d57f5be7b12ac ]
Whenever the igb driver detects the result of a read operation returns
a value composed only by F's (like 0x), it will detach the
net_device, clear the hw_addr pointer and
From: Guilherme G Piccoli
[ Upstream commit 69b97cf6dbce7403845a28bbc75d57f5be7b12ac ]
Whenever the igb driver detects the result of a read operation returns
a value composed only by F's (like 0x), it will detach the
net_device, clear the hw_addr pointer and warn to the user that
From: Simon Horman
[ Upstream commit 654450baf2afba86cf328e1849ccac61ec4630af ]
Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for
From: Simon Horman
[ Upstream commit 654450baf2afba86cf328e1849ccac61ec4630af ]
Use recently added R-Car Gen 2 fallback binding for msiof nodes in
DT for r8a7790 SoC.
This has no run-time effect for the current driver as the initialisation
sequence is the same for the SoC-specific binding for
From: Bartosz Golaszewski
[ Upstream commit 2e644be30fcc08c736f66b60f4898d274d4873ab ]
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
From: Bartosz Golaszewski
[ Upstream commit 2e644be30fcc08c736f66b60f4898d274d4873ab ]
THS8135 is a configurable video DAC. Add DT bindings for this chip.
Signed-off-by: Bartosz Golaszewski
Reviewed-by: Laurent Pinchart
Acked-by: Rob Herring
Signed-off-by: Archit Taneja
Link:
From: John Crispin
[ Upstream commit 808cf33d4817c730008de9b2736b357708a3d7f6 ]
The MIPS based MT7621 shares the same XHCI core as the newer generation of
ARM based SoCs. The driver works out of the box and we only need to make it
buildable in Kconfig.
Signed-off-by: John
From: John Crispin
[ Upstream commit 808cf33d4817c730008de9b2736b357708a3d7f6 ]
The MIPS based MT7621 shares the same XHCI core as the newer generation of
ARM based SoCs. The driver works out of the box and we only need to make it
buildable in Kconfig.
Signed-off-by: John Crispin
From: Guenter Roeck
[ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ]
Writes into limit attributes can overflow due to multplications and
additions with unbound input values. Writing into fan limit attributes
can result in a crash with a division by zero if very
From: Guenter Roeck
[ Upstream commit 87cdfa9d60f4f40e6d71b04b10b36d9df3c89282 ]
Writes into limit attributes can overflow due to multplications and
additions with unbound input values. Writing into fan limit attributes
can result in a crash with a division by zero if very large values are
From: Niklas Söderlund
[ Upstream commit 6dcf45e514974a1ff10755015b5e06746a033e5f ]
This bit was wrongly named due to a typo, Sergei checked the SH7734/63
manuals and this bit should be named MPDE.
Suggested-by: Sergei Shtylyov
From: Niklas Söderlund
[ Upstream commit 6dcf45e514974a1ff10755015b5e06746a033e5f ]
This bit was wrongly named due to a typo, Sergei checked the SH7734/63
manuals and this bit should be named MPDE.
Suggested-by: Sergei Shtylyov
Signed-off-by: Niklas Söderlund
Signed-off-by: David S. Miller
From: Nicholas Mc Guire
[ Upstream commit ed784c532a3d0959db488f40a96c5127f63d42dc ]
The delay here is not in atomic context and does not seem critical with
respect to precision, but usleep_range(min,max) with min==max results in
giving the timer subsystem no room to optimize
From: Nicholas Mc Guire
[ Upstream commit ed784c532a3d0959db488f40a96c5127f63d42dc ]
The delay here is not in atomic context and does not seem critical with
respect to precision, but usleep_range(min,max) with min==max results in
giving the timer subsystem no room to optimize uncritical delays.
From: Marcin Nowakowski
[ Upstream commit a8f108d70c74d83574c157648383eb2e4285a190 ]
Do not reserve memory for the crashkernel if the commandline argument
points to a wrong location. This can happen if the location is specified
wrong or if the same commandline is
From: Marcin Nowakowski
[ Upstream commit a8f108d70c74d83574c157648383eb2e4285a190 ]
Do not reserve memory for the crashkernel if the commandline argument
points to a wrong location. This can happen if the location is specified
wrong or if the same commandline is reused when starting the
From: Andreas Klinger
[ Upstream commit ff1293f67734da68e23fecb6ecdae7112b8c43f9 ]
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger
Acked-by: Rob Herring
Signed-off-by: Jonathan Cameron
From: Andreas Klinger
[ Upstream commit ff1293f67734da68e23fecb6ecdae7112b8c43f9 ]
Add DT bindings for avia,hx711
Add vendor avia to vendor list
Signed-off-by: Andreas Klinger
Acked-by: Rob Herring
Signed-off-by: Jonathan Cameron
Signed-off-by: Sasha Levin
---
From: Ondrej Jirman
[ Upstream commit a43c96427e713bea94e9ef50e8be1f493afc0691 ]
When adjusting PLL_CPUX on H3, the PLL is temporarily driven
too high, and the system becomes unstable (oopses or hangs).
Add a notifier to avoid this situation by temporarily switching
to a
From: Ondrej Jirman
[ Upstream commit a43c96427e713bea94e9ef50e8be1f493afc0691 ]
When adjusting PLL_CPUX on H3, the PLL is temporarily driven
too high, and the system becomes unstable (oopses or hangs).
Add a notifier to avoid this situation by temporarily switching
to a known stable 24 MHz
From: Ville Syrjälä
[ Upstream commit 58d09ebdb4edf5d3ab3a2aee851ab0168bc83ec6 ]
Do the overlay frontbuffer tracking properly so that it matches
the state of the overlay on/off/continue requests.
One slight problem is that intel_frontbuffer_flip_complete()
may
From: Ville Syrjälä
[ Upstream commit 58d09ebdb4edf5d3ab3a2aee851ab0168bc83ec6 ]
Do the overlay frontbuffer tracking properly so that it matches
the state of the overlay on/off/continue requests.
One slight problem is that intel_frontbuffer_flip_complete()
may get delayed by an arbitrarily
From: Bartlomiej Zolnierkiewicz
[ Upstream commit 80b7a2e2498bcffb1a79980dfbeb7a1275577b28 ]
Add CPU operating points for Exynos4412 Prime (it supports
additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
a regular non-turbo OPP on this SoC). Also update relevant
From: Bartlomiej Zolnierkiewicz
[ Upstream commit 80b7a2e2498bcffb1a79980dfbeb7a1275577b28 ]
Add CPU operating points for Exynos4412 Prime (it supports
additional 1704MHz & 1600MHz OPPs and 1500MHz OPP is just
a regular non-turbo OPP on this SoC). Also update relevant
cooling maps to account
501 - 600 of 1388 matches
Mail list logo