On Tue, 27 Nov 2018, Thomas Gleixner wrote:
> On Tue, 27 Nov 2018, Lendacky, Thomas wrote:
> > On 11/25/2018 12:33 PM, Thomas Gleixner wrote:
> > > --- a/arch/x86/kernel/process.c
> > > +++ b/arch/x86/kernel/process.c
> > > @@ -406,6 +406,11 @@ static __always_inline void spec_ctrl_up
> > > if
On Tue, 27 Nov 2018, Thomas Gleixner wrote:
> On Tue, 27 Nov 2018, Lendacky, Thomas wrote:
> > On 11/25/2018 12:33 PM, Thomas Gleixner wrote:
> > > --- a/arch/x86/kernel/process.c
> > > +++ b/arch/x86/kernel/process.c
> > > @@ -406,6 +406,11 @@ static __always_inline void spec_ctrl_up
> > > if
On Tue, 27 Nov 2018, Lendacky, Thomas wrote:
> On 11/25/2018 12:33 PM, Thomas Gleixner wrote:
> > --- a/arch/x86/kernel/process.c
> > +++ b/arch/x86/kernel/process.c
> > @@ -406,6 +406,11 @@ static __always_inline void spec_ctrl_up
> > if (static_cpu_has(X86_FEATURE_SSBD))
> > msr
On Tue, 27 Nov 2018, Lendacky, Thomas wrote:
> On 11/25/2018 12:33 PM, Thomas Gleixner wrote:
> > --- a/arch/x86/kernel/process.c
> > +++ b/arch/x86/kernel/process.c
> > @@ -406,6 +406,11 @@ static __always_inline void spec_ctrl_up
> > if (static_cpu_has(X86_FEATURE_SSBD))
> > msr
On Wed, 21 Nov 2018, Robin Murphy wrote:
> If swiotlb_bounce_page() failed, calling arch_sync_dma_for_device() may
> lead to such delights as performing cache maintenance on whatever
> address phys_to_virt(SWIOTLB_MAP_ERROR) looks like, which is typically
> outside the kernel memory map and goes
On Wed, 21 Nov 2018, Robin Murphy wrote:
> If swiotlb_bounce_page() failed, calling arch_sync_dma_for_device() may
> lead to such delights as performing cache maintenance on whatever
> address phys_to_virt(SWIOTLB_MAP_ERROR) looks like, which is typically
> outside the kernel memory map and goes
Nicholas Mc Guire 於 2018年11月27日 週二 上午9:07寫道：
>
> The error cases of mediatek_gpio_bank_probe() would go unnoticed (except
> for the dev_err() messages). The probe function should return an error
> if one of the banks failed to initialize properly indicated by
> not returning non-0.
>
>
Nicholas Mc Guire 於 2018年11月27日 週二 上午9:07寫道：
>
> The error cases of mediatek_gpio_bank_probe() would go unnoticed (except
> for the dev_err() messages). The probe function should return an error
> if one of the banks failed to initialize properly indicated by
> not returning non-0.
>
>
This cuts out a tremendous amount of boilerplate. I've used the PRIME
support now to test V3D rendering on a STB development board with no
KMS driver.
v2: Use the DEFINE_DRM_GEM_SHMEM_FOPS for proper mmap setup.
Signed-off-by: Eric Anholt
Acked-by: Daniel Vetter (v1)
---
This cuts out a tremendous amount of boilerplate. I've used the PRIME
support now to test V3D rendering on a STB development board with no
KMS driver.
v2: Use the DEFINE_DRM_GEM_SHMEM_FOPS for proper mmap setup.
Signed-off-by: Eric Anholt
Acked-by: Daniel Vetter (v1)
---
On 11/13/2018 09:57 PM, Jacek Anaszewski wrote:
> On 11/12/2018 07:27 PM, Rob Herring wrote:
>> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
>>> Introduce dedicated properties for conveying information about
>>> LED function and color. Mark old "label" property as deprecated.
On 11/13/2018 09:57 PM, Jacek Anaszewski wrote:
> On 11/12/2018 07:27 PM, Rob Herring wrote:
>> On Tue, Nov 06, 2018 at 11:07:12PM +0100, Jacek Anaszewski wrote:
>>> Introduce dedicated properties for conveying information about
>>> LED function and color. Mark old "label" property as deprecated.
Weiyi Lu 於 2018年11月26日 週一 下午7:45寫道：
>
> From: Owen Chen
>
> PLLs with tuner_en bit, such as APLL1, need to disable
> tuner_en before apply new frequency settings, or the new frequency
> settings (pcw) will not be applied.
> The tuner_en bit will be disabled during changing PLL rate
> and be
On Tue, 27 Nov 2018, PanBian wrote:
> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
> > On 11/21/18 9:07 PM, Pan Bian wrote:
> > > kfree() is incorrectly used to release the pages allocated by
> > > __get_free_page() and __get_free_pages(). Use the matching deallocators
> > >
Weiyi Lu 於 2018年11月26日 週一 下午7:45寫道：
>
> From: Owen Chen
>
> PLLs with tuner_en bit, such as APLL1, need to disable
> tuner_en before apply new frequency settings, or the new frequency
> settings (pcw) will not be applied.
> The tuner_en bit will be disabled during changing PLL rate
> and be
On Tue, 27 Nov 2018, PanBian wrote:
> On Mon, Nov 26, 2018 at 03:31:39PM -0500, Boris Ostrovsky wrote:
> > On 11/21/18 9:07 PM, Pan Bian wrote:
> > > kfree() is incorrectly used to release the pages allocated by
> > > __get_free_page() and __get_free_pages(). Use the matching deallocators
> > >
Hi Shuah,
Commit
623ea0df7083 ("selftests: firmware: remove use of non-standard diff -Z
option")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgp7ZaLoM8wMr.pgp
Description: OpenPGP digital signature
Hi Shuah,
Commit
623ea0df7083 ("selftests: firmware: remove use of non-standard diff -Z
option")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgp7ZaLoM8wMr.pgp
Description: OpenPGP digital signature
On 11/20/18 10:18 PM, Rafael David Tinoco wrote:
>
> Russell,
>
> I have tried to place MAX_POSSIBLE_PHYSMEM_BITS in the best available
> header for each architecture, considering different paging levels, PAE
> existence, and existing similar definitions. Also, I have only
> considered those
On 11/20/18 10:18 PM, Rafael David Tinoco wrote:
>
> Russell,
>
> I have tried to place MAX_POSSIBLE_PHYSMEM_BITS in the best available
> header for each architecture, considering different paging levels, PAE
> existence, and existing similar definitions. Also, I have only
> considered those
On Tue, 27 Nov 2018, Lendacky, Thomas wrote:
> On 11/25/2018 12:33 PM, Thomas Gleixner wrote:
> > +/* Update x86_spec_ctrl_base in case SMT state changed. */
> > +static void update_stibp_strict(void)
> > {
> > - wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
> > + u64 mask =
On Tue, 27 Nov 2018, Lendacky, Thomas wrote:
> On 11/25/2018 12:33 PM, Thomas Gleixner wrote:
> > +/* Update x86_spec_ctrl_base in case SMT state changed. */
> > +static void update_stibp_strict(void)
> > {
> > - wrmsrl(MSR_IA32_SPEC_CTRL, x86_spec_ctrl_base);
> > + u64 mask =
On 11/20/2018 03:19 PM, Joe Lawrence wrote:
> Hi Steve,
>
> I noticed that ftrace does not currently support functions built with
> the -ffunction-sections option as they end up in .text.
> ELF sections, never making into the __mcount_loc section.
>
> I modified the recordmcount scripts to
On 11/20/2018 03:19 PM, Joe Lawrence wrote:
> Hi Steve,
>
> I noticed that ftrace does not currently support functions built with
> the -ffunction-sections option as they end up in .text.
> ELF sections, never making into the __mcount_loc section.
>
> I modified the recordmcount scripts to
On Mon, Nov 26, 2018 at 11:37:20PM +0100, Rafael J. Wysocki wrote:
> On Monday, November 26, 2018 7:03:58 PM CET Rafael J. Wysocki wrote:
> > Hi Bjorn,
> >
> > The SD card reader in my Acer Aspire S5 doesn't work with 4.20-rc.
> >
> > Here's what lspci -v says about it (in a bad kernel):
> >
>
On Mon, Nov 26, 2018 at 11:37:20PM +0100, Rafael J. Wysocki wrote:
> On Monday, November 26, 2018 7:03:58 PM CET Rafael J. Wysocki wrote:
> > Hi Bjorn,
> >
> > The SD card reader in my Acer Aspire S5 doesn't work with 4.20-rc.
> >
> > Here's what lspci -v says about it (in a bad kernel):
> >
>
On Tue, Nov 27, 2018 at 12:12:28AM +, Elliott, Robert (Persistent Memory)
wrote:
> I ran a short test with:
> * HPE ProLiant DL360 Gen9 system
> * Intel Xeon E5-2699 CPU with 18 physical cores (0-17) and
> 18 hyperthreaded cores (36-53)
> * DDR4 NVDIMM-Ns (which run at regular DRAM DIMM
On Tue, Nov 27, 2018 at 12:12:28AM +, Elliott, Robert (Persistent Memory)
wrote:
> I ran a short test with:
> * HPE ProLiant DL360 Gen9 system
> * Intel Xeon E5-2699 CPU with 18 physical cores (0-17) and
> 18 hyperthreaded cores (36-53)
> * DDR4 NVDIMM-Ns (which run at regular DRAM DIMM
On 10/17/2018 4:25 PM, Zoran Markovic wrote:
> Function smack_key_permission() only issues smack requests for the
> following operations:
> - KEY_NEED_READ (issues MAY_READ)
> - KEY_NEED_WRITE (issues MAY_WRITE)
> - KEY_NEED_LINK (issues MAY_WRITE)
> - KEY_NEED_SETATTR (issues MAY_WRITE)
> A
On 10/17/2018 4:25 PM, Zoran Markovic wrote:
> Function smack_key_permission() only issues smack requests for the
> following operations:
> - KEY_NEED_READ (issues MAY_READ)
> - KEY_NEED_WRITE (issues MAY_WRITE)
> - KEY_NEED_LINK (issues MAY_WRITE)
> - KEY_NEED_SETATTR (issues MAY_WRITE)
> A
On 11/25/2018 12:33 PM, Thomas Gleixner wrote:
> The upcoming fine grained per task STIBP control needs to be updated on CPU
> hotplug as well.
>
> Split out the code which controls the strict mode so the prctl control code
> can be added later. Mark the SMP function call argument __unused while
On 11/25/2018 12:33 PM, Thomas Gleixner wrote:
> The upcoming fine grained per task STIBP control needs to be updated on CPU
> hotplug as well.
>
> Split out the code which controls the strict mode so the prctl control code
> can be added later. Mark the SMP function call argument __unused while
On Tue, Nov 27, 2018 at 01:44:12PM -0500, Steven Rostedt wrote:
>
> Doing the sweep of my INBOX, I came across this patch (it was sent
> while I was in the Alps :-)
>
>
> On Wed, 20 Jun 2018 14:08:00 +0300
> Dan Carpenter wrote:
>
> > The > should be >= to prevent an off by one bug.
>
>
On Tue, Nov 27, 2018 at 01:44:12PM -0500, Steven Rostedt wrote:
>
> Doing the sweep of my INBOX, I came across this patch (it was sent
> while I was in the Alps :-)
>
>
> On Wed, 20 Jun 2018 14:08:00 +0300
> Dan Carpenter wrote:
>
> > The > should be >= to prevent an off by one bug.
>
>
[resending with fixed email address for Paul Moore]
Moving discussion from github[1] to here.
To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
underlying layers") was added in 4.20-rc1 to make overlayfs access
checks on underlying "real" filesystems more consistent. The
[resending with fixed email address for Paul Moore]
Moving discussion from github[1] to here.
To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
underlying layers") was added in 4.20-rc1 to make overlayfs access
checks on underlying "real" filesystems more consistent. The
On 27/11/18 11:11 PM, Greg KH wrote:
> On Tue, Nov 27, 2018 at 09:57:23AM +1300, Mark Tomlinson wrote:
>> sysrq_do_reset() is called in softirq context, so it cannot call
>> sync() directly. Instead, call orderly_reboot(), which creates a work
>> item to run /sbin/reboot, or do emergency_sync
On 27/11/18 11:11 PM, Greg KH wrote:
> On Tue, Nov 27, 2018 at 09:57:23AM +1300, Mark Tomlinson wrote:
>> sysrq_do_reset() is called in softirq context, so it cannot call
>> sync() directly. Instead, call orderly_reboot(), which creates a work
>> item to run /sbin/reboot, or do emergency_sync
Moving discussion from github[1] to here.
To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
underlying layers") was added in 4.20-rc1 to make overlayfs access
checks on underlying "real" filesystems more consistent. The
discussion leading up to this commit can be found at
Moving discussion from github[1] to here.
To summarize: commit 007ea44892e6 ("ovl: relax permission checking on
underlying layers") was added in 4.20-rc1 to make overlayfs access
checks on underlying "real" filesystems more consistent. The
discussion leading up to this commit can be found at
On Wed, Nov 21, 2018 at 03:53:05PM +, David Laight wrote:
>
>
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 21 November 2018 14:42
> > To: David Laight
> > Cc: mi...@elte.hu; t...@linutronix.de; Boris Ostrovsky; Juergen Gross;
> >
On Wed, Nov 21, 2018 at 03:53:05PM +, David Laight wrote:
>
>
> > -Original Message-
> > From: Jan Beulich [mailto:jbeul...@suse.com]
> > Sent: 21 November 2018 14:42
> > To: David Laight
> > Cc: mi...@elte.hu; t...@linutronix.de; Boris Ostrovsky; Juergen Gross;
> >
On 11/27/2018 09:25 AM, Lendacky, Thomas wrote:
>> --- a/arch/x86/kernel/cpu/bugs.c
>> +++ b/arch/x86/kernel/cpu/bugs.c
>> @@ -148,6 +148,10 @@ x86_virt_spec_ctrl(u64 guest_spec_ctrl,
>> static_cpu_has(X86_FEATURE_AMD_SSBD))
>> hostval |=
On 11/27/2018 09:25 AM, Lendacky, Thomas wrote:
>> --- a/arch/x86/kernel/cpu/bugs.c
>> +++ b/arch/x86/kernel/cpu/bugs.c
>> @@ -148,6 +148,10 @@ x86_virt_spec_ctrl(u64 guest_spec_ctrl,
>> static_cpu_has(X86_FEATURE_AMD_SSBD))
>> hostval |=
On Tue, 27 Nov 2018 19:31:50 +
Will Deacon wrote:
> Hi Steve,
>
> On Wed, Nov 21, 2018 at 08:27:11PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)"
> >
> > The curr_ret_stack is no longer set to -1 when not tracing a function. It is
> > now done differently, and the
On Tue, 27 Nov 2018 19:31:50 +
Will Deacon wrote:
> Hi Steve,
>
> On Wed, Nov 21, 2018 at 08:27:11PM -0500, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)"
> >
> > The curr_ret_stack is no longer set to -1 when not tracing a function. It is
> > now done differently, and the
Hi!
> Motivates and explains the ktask API for kernel clients.
>
> Signed-off-by: Daniel Jordan
> ---
> Documentation/core-api/index.rst | 1 +
> Documentation/core-api/ktask.rst | 213 +++
> 2 files changed, 214 insertions(+)
> create mode 100644
Hi!
> Motivates and explains the ktask API for kernel clients.
>
> Signed-off-by: Daniel Jordan
> ---
> Documentation/core-api/index.rst | 1 +
> Documentation/core-api/ktask.rst | 213 +++
> 2 files changed, 214 insertions(+)
> create mode 100644
Commit-ID: 456824896de2b68df40b3ea5777ef49dc6cc8fda
Gitweb: https://git.kernel.org/tip/456824896de2b68df40b3ea5777ef49dc6cc8fda
Author: Reinette Chatre
AuthorDate: Tue, 27 Nov 2018 11:19:36 -0800
Committer: Borislav Petkov
CommitDate: Tue, 27 Nov 2018 20:39:02 +0100
x86/resctrl: Use
Commit-ID: 456824896de2b68df40b3ea5777ef49dc6cc8fda
Gitweb: https://git.kernel.org/tip/456824896de2b68df40b3ea5777ef49dc6cc8fda
Author: Reinette Chatre
AuthorDate: Tue, 27 Nov 2018 11:19:36 -0800
Committer: Borislav Petkov
CommitDate: Tue, 27 Nov 2018 20:39:02 +0100
x86/resctrl: Use
Hi all,
This pair of patches improves our preempt_enable() implementation slightly
on arm64 by making the resulting call to preempt_schedule() conditional
on need_resched(), which is tracked in bit 32 of the preempt count. The
logic is inverted so that we can detect the preempt count going to
Hi all,
This pair of patches improves our preempt_enable() implementation slightly
on arm64 by making the resulting call to preempt_schedule() conditional
on need_resched(), which is tracked in bit 32 of the preempt count. The
logic is inverted so that we can detect the preempt count going to
The asm-generic/preempt.h implementation doesn't make use of the
PREEMPT_NEED_RESCHED flag, since this can interact badly with load/store
architectures which rely on the preempt_count word being unchanged across
an interrupt.
However, since we're a 64-bit architecture and the preempt count is
The asm-generic/preempt.h implementation doesn't make use of the
PREEMPT_NEED_RESCHED flag, since this can interact badly with load/store
architectures which rely on the preempt_count word being unchanged across
an interrupt.
However, since we're a 64-bit architecture and the preempt count is
PREEMPT_NEED_RESCHED is never used directly, so move it into the arch
code where it can potentially be implemented using either a different
bit in the preempt count or as an entirely separate entity.
Cc: Robert Love
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Martin Schwidefsky
Signed-off-by:
PREEMPT_NEED_RESCHED is never used directly, so move it into the arch
code where it can potentially be implemented using either a different
bit in the preempt count or as an entirely separate entity.
Cc: Robert Love
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Martin Schwidefsky
Signed-off-by:
On 17.10.2018 1:47, Stephen Boyd wrote:
> Quoting Robert Yang (2018-09-25 14:49:40)
>> The current behavior is that clk_round_rate would return the same clock
>> rate passed to it for valid PLL configurations. This change will return
>> the exact rate the PLL will provide in accordance with clk
On 17.10.2018 1:47, Stephen Boyd wrote:
> Quoting Robert Yang (2018-09-25 14:49:40)
>> The current behavior is that clk_round_rate would return the same clock
>> rate passed to it for valid PLL configurations. This change will return
>> the exact rate the PLL will provide in accordance with clk
On 11/27/18 8:05 PM, Vlastimil Babka wrote:
> On 11/27/18 6:08 PM, Linus Torvalds wrote:
>> On Mon, Nov 26, 2018 at 10:24 PM kernel test robot
>> wrote:
>>>
>>> FYI, we noticed a -61.3% regression of vm-scalability.throughput due
>>> to commit ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
>>>
On 11/27/18 8:05 PM, Vlastimil Babka wrote:
> On 11/27/18 6:08 PM, Linus Torvalds wrote:
>> On Mon, Nov 26, 2018 at 10:24 PM kernel test robot
>> wrote:
>>>
>>> FYI, we noticed a -61.3% regression of vm-scalability.throughput due
>>> to commit ac5b2c18911f ("mm: thp: relax __GFP_THISNODE for
>>>
Hi Steve,
On Wed, Nov 21, 2018 at 08:27:11PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> The curr_ret_stack is no longer set to -1 when not tracing a function. It is
> now done differently, and the FTRACE_NOTRACE_DEPTH value is no longer used.
> Remove the reference to
On Mon, Nov 26, 2018 at 03:09:56PM +, Suzuki K Poulose wrote:
> On Mon, Nov 26, 2018 at 02:06:04PM +, Will Deacon wrote:
> > On Mon, Nov 05, 2018 at 11:55:11AM +, Suzuki K Poulose wrote:
> > > We have two entries for ARM64_WORKAROUND_CLEAN_CACHE capability :
> > >
> > > 1) ARM Errata
Hi Steve,
On Wed, Nov 21, 2018 at 08:27:11PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)"
>
> The curr_ret_stack is no longer set to -1 when not tracing a function. It is
> now done differently, and the FTRACE_NOTRACE_DEPTH value is no longer used.
> Remove the reference to
On Mon, Nov 26, 2018 at 03:09:56PM +, Suzuki K Poulose wrote:
> On Mon, Nov 26, 2018 at 02:06:04PM +, Will Deacon wrote:
> > On Mon, Nov 05, 2018 at 11:55:11AM +, Suzuki K Poulose wrote:
> > > We have two entries for ARM64_WORKAROUND_CLEAN_CACHE capability :
> > >
> > > 1) ARM Errata
On Mon, Nov 26, 2018 at 04:31:23PM -0800, Florian Fainelli wrote:
> breakpoint tests on the ARM 32-bit kernel are broken in several ways.
>
> The breakpoint length requested does not necessarily match whether the
> function address has the Thumb bit (bit 0) set or not, and this does
> matter to
On Mon, Nov 26, 2018 at 04:31:23PM -0800, Florian Fainelli wrote:
> breakpoint tests on the ARM 32-bit kernel are broken in several ways.
>
> The breakpoint length requested does not necessarily match whether the
> function address has the Thumb bit (bit 0) set or not, and this does
> matter to
Hi,
On 27-11-18 20:27, Andy Shevchenko wrote:
On Tue, Nov 27, 2018 at 05:14:06PM +0100, Hans de Goede wrote:
On 27-11-18 16:37, Andy Shevchenko wrote:
The caller would like to know the reason why the i2c_acpi_new_device() fails.
For example, if adapter is not available, it might be in the
Hi,
On 27-11-18 20:27, Andy Shevchenko wrote:
On Tue, Nov 27, 2018 at 05:14:06PM +0100, Hans de Goede wrote:
On 27-11-18 16:37, Andy Shevchenko wrote:
The caller would like to know the reason why the i2c_acpi_new_device() fails.
For example, if adapter is not available, it might be in the
On 11/15/2018 03:20 AM, Hans Verkuil wrote:
On 11/12/2018 10:00 PM, Eddie James wrote:
From: Eddie James
The Video Engine (VE) embedded in the Aspeed AST2400 and AST2500 SOCs
can capture and compress video data from digital or analog sources. With
the Aspeed chip acting as a service
On 11/15/2018 03:20 AM, Hans Verkuil wrote:
On 11/12/2018 10:00 PM, Eddie James wrote:
From: Eddie James
The Video Engine (VE) embedded in the Aspeed AST2400 and AST2500 SOCs
can capture and compress video data from digital or analog sources. With
the Aspeed chip acting as a service
On Tue, Nov 27, 2018 at 05:14:06PM +0100, Hans de Goede wrote:
> On 27-11-18 16:37, Andy Shevchenko wrote:
> > The caller would like to know the reason why the i2c_acpi_new_device()
> > fails.
> > For example, if adapter is not available, it might be in the future and we
> > would like to
On Tue, Nov 27, 2018 at 05:14:06PM +0100, Hans de Goede wrote:
> On 27-11-18 16:37, Andy Shevchenko wrote:
> > The caller would like to know the reason why the i2c_acpi_new_device()
> > fails.
> > For example, if adapter is not available, it might be in the future and we
> > would like to
Hi,
On Mon, Nov 26, 2018 at 10:57 PM Stephen Boyd wrote:
>
> > > + videocc: clock-controller@ab0 {
> > > + compatible = "qcom,sdm845-videocc";
> > > + reg = <0xab0 0x1>;
> > > + #clock-cells = <1>;
> > >
Hi,
On Mon, Nov 26, 2018 at 10:57 PM Stephen Boyd wrote:
>
> > > + videocc: clock-controller@ab0 {
> > > + compatible = "qcom,sdm845-videocc";
> > > + reg = <0xab0 0x1>;
> > > + #clock-cells = <1>;
> > >
The #reset-cells was listed as optional in the bindings for
qcom,sdm845-videocc. There's no reason for it to be optional. As per
Stephen [1]:
> We should update the binding to make it a required property. It
> doesn't make any sense why that property would be optional given
> that the hardware
The #reset-cells was listed as optional in the bindings for
qcom,sdm845-videocc. There's no reason for it to be optional. As per
Stephen [1]:
> We should update the binding to make it a required property. It
> doesn't make any sense why that property would be optional given
> that the hardware
I'm announcing the release of the 4.4.165 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 3.18.127 kernel.
All users of the 3.18 kernel series must upgrade.
The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.18.y
and can be browsed at the normal kernel.org git web
On Tue, Nov 27, 2018 at 10:40:21AM -0800, Paul E. McKenney wrote:
> On Mon, Nov 26, 2018 at 08:33:49PM +0100, Andrea Parri wrote:
> > On Mon, Nov 26, 2018 at 04:52:14PM +, Will Deacon wrote:
> > > David Laight explains:
> > >
> > > | A long time ago there was a document from Intel that said
I'm announcing the release of the 4.4.165 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 3.18.127 kernel.
All users of the 3.18 kernel series must upgrade.
The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-3.18.y
and can be browsed at the normal kernel.org git web
On Tue, Nov 27, 2018 at 10:40:21AM -0800, Paul E. McKenney wrote:
> On Mon, Nov 26, 2018 at 08:33:49PM +0100, Andrea Parri wrote:
> > On Mon, Nov 26, 2018 at 04:52:14PM +, Will Deacon wrote:
> > > David Laight explains:
> > >
> > > | A long time ago there was a document from Intel that said
diff --git a/.gitignore b/.gitignore
index fd3a35592543..34fe1346aa87 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,6 +33,7 @@
*.lzo
*.patch
*.gcno
+*.ll
modules.builtin
Module.symvers
*.dwo
diff --git a/Kbuild b/Kbuild
index f55cefd9bf29..f56ed561a284 100644
--- a/Kbuild
+++ b/Kbuild
@@
diff --git a/.gitignore b/.gitignore
index fd3a35592543..34fe1346aa87 100644
--- a/.gitignore
+++ b/.gitignore
@@ -33,6 +33,7 @@
*.lzo
*.patch
*.gcno
+*.ll
modules.builtin
Module.symvers
*.dwo
diff --git a/Kbuild b/Kbuild
index f55cefd9bf29..f56ed561a284 100644
--- a/Kbuild
+++ b/Kbuild
@@
diff --git a/Makefile b/Makefile
index 14472990c4bd..7c78eb797de8 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 18
-SUBLEVEL = 126
+SUBLEVEL = 127
EXTRAVERSION =
NAME = Diseased Newt
diff --git a/arch/s390/kernel/vdso32/Makefile
diff --git a/Makefile b/Makefile
index 14472990c4bd..7c78eb797de8 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 18
-SUBLEVEL = 126
+SUBLEVEL = 127
EXTRAVERSION =
NAME = Diseased Newt
diff --git a/arch/s390/kernel/vdso32/Makefile
diff --git a/Makefile b/Makefile
index a9aed2326233..8eba73521a7f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 140
+SUBLEVEL = 141
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm64/include/asm/percpu.h
diff --git a/Makefile b/Makefile
index a9aed2326233..8eba73521a7f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 140
+SUBLEVEL = 141
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/arm64/include/asm/percpu.h
I'm announcing the release of the 4.9.141 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.9.141 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
The last_cmd_status seq_buf contains user visible messages (accessed
via /sys/fs/resctrl/info/last_cmd_status) that details any errors
encountered while interacting with the resctrl filesystem.
rdt_last_cmd_puts() and rdt_last_cmd_printf() are the two calls
available to respectively print an
The last_cmd_status seq_buf contains user visible messages (accessed
via /sys/fs/resctrl/info/last_cmd_status) that details any errors
encountered while interacting with the resctrl filesystem.
rdt_last_cmd_puts() and rdt_last_cmd_printf() are the two calls
available to respectively print an
I'm announcing the release of the 4.19.5 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.19.5 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 92eb1f42240d..fa4eec22816d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1063,7 +1063,7 @@
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 92eb1f42240d..fa4eec22816d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1063,7 +1063,7 @@
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 9841bad6f271..99a08722124d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1011,7 +1011,7 @@
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 9841bad6f271..99a08722124d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1011,7 +1011,7 @@
I'm announcing the release of the 4.14.84 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web
I'm announcing the release of the 4.14.84 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web
401 - 500 of 1444 matches
Mail list logo
