This patch adds the new IP of Nand Flash Controller(NFC) support
on Intel's Lightning Mountain(LGM) SoC.
DMA is used for burst data transfer operation, also DMA HW supports
aligned 32bit memory address and aligned data access by default.
DMA burst of 8 supported. Data register used to support the
From: Ramuthevar Vadivel Murugan
Add YAML file for dt-bindings to support NAND Flash Controller
on Intel's Lightning Mountain SoC.
Signed-off-by: Ramuthevar Vadivel Murugan
---
.../devicetree/bindings/mtd/intel,lgm-nand.yaml| 85 ++
1 file changed, 85 insertions(+)
On 5/6/20 5:19 PM, Will Deacon wrote:
On Wed, May 06, 2020 at 12:36:43PM +0530, Anshuman Khandual wrote:
On 05/06/2020 12:16 PM, Gavin Shan wrote:
The function add_huge_page_size(), wrapper of hugetlb_add_hstate(),
avoids to register duplicated huge page states for same size. However,
the
On 5/6/20 3:50 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 14 Apr 2020 17:19:14 -0500 Josh Poimboeuf wrote:
>>
>> On Tue, Apr 14, 2020 at 06:50:15AM -0700, Randy Dunlap wrote:
>>> On 4/13/20 7:39 PM, Stephen Rothwell wrote:
Hi all,
Changes since 20200413:
>>>
>>>
On Wed, May 06, 2020 at 11:24:48PM +, Luis Chamberlain wrote:
> On Wed, May 06, 2020 at 06:28:15PM -0400, Rafael Aquini wrote:
> > Analogously to the introduction of panic_on_warn, this patch
> > introduces a kernel option named panic_on_taint in order to
> > provide a simple and generic way
Hi,
On Thu, Apr 23, 2020 at 7:35 AM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Apr 23, 2020 at 2:55 AM Sai Prakash Ranjan
> wrote:
> >
> > Currently on reboot/shutdown, the following messages are
> > displayed on the console as error messages before the
> > system reboots/shutdown as part of
On Wed, May 06, 2020 at 04:19:45PM -0500, Josh Poimboeuf wrote:
> On Wed, May 06, 2020 at 09:45:01AM -0700, Alexei Starovoitov wrote:
> > On Wed, May 6, 2020 at 8:53 AM Josh Poimboeuf wrote:
> > >
> > > On Tue, May 05, 2020 at 04:59:39PM -0700, Alexei Starovoitov wrote:
> > > > As far as
From: Heiner Kallweit
Date: Fri, 1 May 2020 23:26:21 +0200
> Sleeping for a certain amount of time requires use of different
> functions, depending on the time period.
> Documentation/timers/timers-howto.rst explains when to use which
> function, and also checkpatch checks for some potentially
>
Refactor the IPBP handling to effectively move the WARN and comment in
vmx_switch_vmcs() to vmx_vcpu_load_vmcs(). A future patch will give
copy_vmcs02_to_vmcs12_rare() the same treatment.
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/vmx/nested.c | 9 +
arch/x86/kvm/vmx/vmx.c
Or as Jim would say, "Really skip IPBP on nested VMCS switch" :-D
Patch 1 is the delta between kvm/queue and v3 of the original patch[*],
i.e. I just cherry-picked v3 and fixed the conflicts.
Patch 2 applies the "no IPBP" logic to copy_vmcs02_to_vmcs12_rare().
Feel free to sqaush both of these
Skip the Indirect Branch Prediction Barrier that is triggered on a VMCS
switch when temporarily loading vmcs02 to synchronize it to vmcs12, i.e.
give copy_vmcs02_to_vmcs12_rare() the same treatment as
vmx_switch_vmcs().
Make vmx_vcpu_load() static now that it's only referenced within vmx.c.
Recently a performance problem was reported for a process invoking a
non-trival ASL program. The method call in this case ends up
repetitively triggering a call path like:
acpi_ex_store
acpi_ex_store_object_to_node
acpi_ex_write_data_to_field
acpi_ex_insert_into_field
On Wed, 6 May 2020 16:32:59 -0700 Maciej Żenczykowski wrote:
> From: Maciej Żenczykowski
>
> __bpf_skb_max_len(skb) is used from:
> bpf_skb_adjust_room
> __bpf_skb_change_tail
> __bpf_skb_change_head
>
> but in the case of forwarding we're likely calling these functions
> during receive
On 5/6/2020 4:53 PM, Jacob Keller wrote:
> The GENL_SET_ERR_MSG, NL_SET_ERR_MSG, and NL_SET_ERR_MSG_MOD macros are
> used to report a string describing a specific error to userspace.
>
> Often, these strings can exceed the normal 80 column limit. However,
> just like with strings printed to
The GENL_SET_ERR_MSG, NL_SET_ERR_MSG, and NL_SET_ERR_MSG_MOD macros are
used to report a string describing a specific error to userspace.
Often, these strings can exceed the normal 80 column limit. However,
just like with strings printed to the kernel log, it is preferred to
keep these on a
Hi Dmitry,
On 4/17/20 11:04 PM, Dmitry Osipenko wrote:
> 27.02.2020 20:08, Dmitry Osipenko пишет:
>> GCC produces this warning when kernel compiled using `make W=1`:
>>
>> warning: ‘strncpy’ specified bound 16 equals destination size
>> [-Wstringop-truncation]
>> 772 |
From: Fenghua Yu
Current Memory Bandwidth Allocation (MBA) hardware has a limitation:
all threads on the same core must have the same delay value. If there
are different delay values across threads on one core, the original
MBA implementation allocates the max delay value to the core and an
V2 upstream submission available from:
https://lore.kernel.org/lkml/cover.1586801373.git.reinette.cha...@intel.com
Changes since V2:
- Rebase on top of recently merged series "x86/resctrl: Support wider
MBM counters". Small change needed to take into account
asm/resctrl_sched.h ->
Intel Memory Bandwidth Allocation (MBA) control is provided per
processor core. At the same time different CLOS, configured with different
bandwidth percentages, can be assigned to the hardware threads
sharing a core. In the original implementation of MBA the maximum throttling
of the per-thread
The user input to files in the resctrl filesystem are expected to be
terminated with a newline. Testing the user input includes a test for
the presence of a newline and then replacing the newline with NUL
byte followed by comparison using strcmp().
sysfs_streq() exists to test if strings are
From: Fenghua Yu
Some systems support per-thread Memory Bandwidth Allocation (MBA) which
applies a throttling delay value to each hardware thread instead of to
a core. Per-thread MBA is enumerated by CPUID.
No feature flag is shown in /proc/cpuinfo. User applications need to
check a resctrl
The pull request you sent on Wed, 6 May 2020 15:47:37 -0700:
> git://git.kernel.org/pub/scm/linux/kernel/git/chrome-platform/linux.git
> tags/tag-chrome-platform-fixes-for-v5.7-rc5
has been merged into torvalds/linux.git:
On Wed, May 06, 2020 at 07:33:06PM -0400, Peter Xu wrote:
> On Wed, May 06, 2020 at 02:20:47PM -0700, Sean Christopherson wrote:
> > On Wed, May 06, 2020 at 05:13:56PM -0400, Peter Xu wrote:
> > > Oh... so is dr6 going to have some leftover bit set in the GD test if
> > > without
> > > this patch
Em Wed, May 06, 2020 at 03:45:59PM -0700, Ian Rogers escreveu:
> On Thu, Apr 30, 2020 at 8:33 AM Jiri Olsa wrote:
> >
> > On Thu, Apr 30, 2020 at 09:45:14PM +0800, Jin, Yao wrote:
> > > Hi Jiri,
> > >
> > > On 4/30/2020 4:45 PM, Jiri Olsa wrote:
> > > > On Thu, Apr 30, 2020 at 08:36:18AM +0800,
On Wed, May 06, 2020 at 11:13:53PM +, Luis Chamberlain wrote:
> + * execute a critial path. We should be mindful and selective of its use.
"critical"
Hi
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag
fixing commit: 42dbaa5a0577 ("KVM: x86: Virtualize debug registers").
The bot has tested the following trees: v5.6.10, v5.4.38, v4.19.120, v4.14.178,
v4.9.221, v4.4.221.
v5.6.10: Build OK!
Hi
[This is an automated email]
This commit has been processed because it contains a -stable tag.
The stable tag indicates that it's relevant for the following trees: all
The bot has tested the following trees: v5.6.10, v5.4.38, v4.19.120, v4.14.178,
v4.9.221, v4.4.221.
v5.6.10: Build OK!
Hi Li,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on kvm/linux-next]
[also build test ERROR on next-20200505]
[cannot apply to tip/auto-latest linus/master linux/master v5.7-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve
We would be trying to print the kernel virtual address of the base
register address which is not very useful and is not displayed by
default because of pointer restriction. Print the Device Tree node name
instead which is what was originally intended.
Signed-off-by: Florian Fainelli
---
Russell,
On Wed, May 06, 2020 at 11:13:53PM +, Luis Chamberlain wrote:
> __read_mostly can easily be misused by folks, its not meant for
> just read-only data. There are performance reasons for using it, but
> we also don't provide any guidance about its use. Provide a bit more
> guidance over it use.
On Wed, May 06, 2020 at 02:20:47PM -0700, Sean Christopherson wrote:
> On Wed, May 06, 2020 at 05:13:56PM -0400, Peter Xu wrote:
> > Oh... so is dr6 going to have some leftover bit set in the GD test if
> > without
> > this patch for AMD? Btw, I noticed a small difference on Intel/AMD spec for
>
On Thu, 7 May 2020 at 01:45, Florian Fainelli wrote:
>
>
>
> On 5/6/2020 2:40 PM, Vladimir Oltean wrote:
> > Hi Florian,
> >
> > On Thu, 7 May 2020 at 00:24, Florian Fainelli wrote:
> >>
> >>
> >>
> >> On 5/5/2020 2:23 PM, Vivien Didelot wrote:
> >>> On Tue, 5 May 2020 14:02:53 -0700, Florian
From: Maciej Żenczykowski
__bpf_skb_max_len(skb) is used from:
bpf_skb_adjust_room
__bpf_skb_change_tail
__bpf_skb_change_head
but in the case of forwarding we're likely calling these functions
during receive processing on ingress and bpf_redirect()'ing at
a later point in time to egress
It might be dangerous if an UART port reference clock rate is suddenly
changed. In particular the 8250 port drivers (and AFAICS most of the tty
drivers using common clock framework clocks) rely either on the
exclusive reference clock utilization or on the ref clock rate being
always constant.
Some platforms can be designed in a way so the UART port reference clock
might be asynchronously changed at some point. In Baikal-T1 SoC this may
happen due to the reference clock being shared between two UART ports, on
the Allwinner SoC the reference clock is derived from the CPU clock, so
any
Really instead of twice checking the clk_round_rate() return value
we could do it once, and if it isn't error the clock rate can be changed.
By doing so we decrease a number of ret-value tests and remove a weird
goto-based construction implemented in the dw8250_set_termios() method.
Standard 8250 UART ports are designed in a way so they can communicate
with baud rates up to 1/16 of a reference frequency. It's expected from
most of the currently supported UART controllers. That's why the former
version of serial8250_get_baud_rate() method called uart_get_baud_rate()
with min
The race condition may happen if the UART reference clock is shared with
some other device (on Baikal-T1 SoC it's another DW UART port). In this
case if that device changes the clock rate while serial console is using
it the DW 8250 UART port might not only end up with an invalid uartclk
value
On Wed, May 6, 2020 at 8:29 AM Baolin Wang wrote:
>
> Hi Jassi,
>
> On Tue, Apr 28, 2020 at 11:10 AM Baolin Wang wrote:
> >
> > From: Baolin Wang
> >
> > The Spreadtrum mailbox controller supports 8 channels to communicate
> > with MCUs, and it contains 2 different parts: inbox and outbox,
On Wed, May 06, 2020 at 06:28:15PM -0400, Rafael Aquini wrote:
> Analogously to the introduction of panic_on_warn, this patch
> introduces a kernel option named panic_on_taint in order to
> provide a simple and generic way to stop execution and catch
> a coredump when the kernel gets tainted by
On Wed, 2020-05-06 at 15:47 -0700, Darrick J. Wong wrote:
> On Wed, May 06, 2020 at 12:07:12AM +0100, Edwin Török wrote:
> >
> > On 5 May 2020 01:58:11 BST, "Darrick J. Wong" <
> > darrick.w...@oracle.com> wrote:
> > > On Mon, May 04, 2020 at 11:54:05PM +0100, Edwin Török wrote:
> > > > On Mon,
Hi Rob,
On Wed, 6 May 2020 at 23:10, Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the aspeed tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
Thanks Stephen.
> arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:126.11-130.4: Warning
> (i2c_bus_reg):
__read_mostly can easily be misused by folks, its not meant for
just read-only data. There are performance reasons for using it, but
we also don't provide any guidance about its use. Provide a bit more
guidance over it use.
Acked-by: Christoph Lameter
Signed-off-by: Luis Chamberlain
---
I sent
Hi all,
After merging the aspeed tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:
arch/arm/boot/dts/aspeed-bmc-facebook-yosemitev2.dts:126.11-130.4: Warning
(i2c_bus_reg): /ahb/apb/bus@1e78a000/i2c-bus@80/ipmb1@10: I2C bus unit address
format error, expected
On 5/6/20 8:03 PM, Bartlomiej Zolnierkiewicz wrote:
> On 5/6/20 10:02 AM, Hyunki Koo wrote:
> > Support 32-bit access for the TX/RX hold registers UTXH and URXH.
> >
> > This is required for some newer SoCs.
>
> Krzysztof has asked this previously but I couldn't find the answer in
> previous
On Wed 2020-05-06 07:43:38, Tony Lindgren wrote:
> * Pavel Machek [200506 10:12]:
> > Hi!
> >
> > So... I found out that USB networking works way better when I don't
> > attempt to charge the phone at the same. Yes, green light was
> > blinking.
>
> OK yes we don't have much of a charger
Add support for color sensors behind EC like TCS3400.
The color data can be presented in Red Green Blue color space (RGB) or
the CIE 1931 XYZ color space (XYZ).
In XYZ mode, the sensor is configured for auto calibrating its channels
and is the "normal" mode.
The driver tells the EC to switch
Add support for color light sensor presented by the Chromebook Embedded
Controller (EC).
Instead of just presenting lux measurement (clear channel), a color light
sensor is able to report color temperature measurement.
The EC, using factory settings, can transform the raw measurement into
the CIE
Define 2 spaces for defining color coming from color sensors:
RGB and XYZ: Both are in lux.
RGB is the raw output from sensors (Red, Green and Blue channels), in
addition to the existing clear channel (C).
The RGBC vector goes through a matrix transformation to produce the XYZ
vector. Y is
On Tue, May 8, 2018 at 12:19 PM Luis R. Rodriguez wrote:
>
> __read_mostly can easily be misused by folks, its not meant for
> just read-only data. There are performance reasons for using it, but
> we also don't provide any guidance about its use. Provide a bit more
> guidance over it use.
>
>
calibration was a one-shot event sent to the sensor to calibrate itself.
It is used on Bosch sensors (BMI160, BMA254).
For TCS3400 light sensor, we need to stay in calibration mode to run
tests.
Accept boolean true and false (not just true) to enter/exit calibration.
Signed-off-by: Gwendal
On 5/6/20 1:08 PM, Mike Stunes wrote:
On Apr 28, 2020, at 8:17 AM, Joerg Roedel wrote:
From: Mike Stunes
To avoid a future VMEXIT for a subsequent CPUID function, cache the
results returned by CPUID into an xarray.
[tl: coding standard changes, register zero extension]
Signed-off-by:
On Wed, May 06, 2020 at 06:43:35PM -0400, Daniel Jordan wrote:
> On Wed, May 06, 2020 at 03:36:54PM -0700, Alexander Duyck wrote:
> > On Wed, May 6, 2020 at 3:21 PM Daniel Jordan
> > wrote:
> > >
> > > On Tue, May 05, 2020 at 07:55:43AM -0700, Alexander Duyck wrote:
> > > > One question about
On Thu, Apr 23, 2020 at 7:23 AM Ian Rogers wrote:
>
> On Thu, Apr 23, 2020 at 4:29 AM Jiri Olsa wrote:
> >
> > On Wed, Apr 22, 2020 at 03:04:24PM -0700, Ian Rogers wrote:
> > > Large metrics such as Branch_Misprediction_Cost_SMT on x86 broadwell
> > > need more space.
> > >
> > > Signed-off-by:
On Wed, May 06, 2020 at 07:49:20PM +0100, Al Viro wrote:
> On Wed, May 06, 2020 at 08:34:29AM -0700, Kees Cook wrote:
>
> > Just posted the whole series:
> > https://lore.kernel.org/lkml/20200506152114.50375-1-keesc...@chromium.org/
> >
> > But the specific question was driven by this patch:
> >
Hi all,
On Tue, 14 Apr 2020 17:19:14 -0500 Josh Poimboeuf wrote:
>
> On Tue, Apr 14, 2020 at 06:50:15AM -0700, Randy Dunlap wrote:
> > On 4/13/20 7:39 PM, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20200413:
> > >
> >
> >
> > I killed objtool after 49 minutes of CPU
Hi Linus,
The following changes since commit 538b8471fee89eaf18f6bfbbc0576473f952b83e:
platform/chrome: cros_ec_sensorhub: Add missing '\n' in log messages
(2020-04-13 16:31:33 +0200)
are available in the Git repository at:
On Thu, Apr 30, 2020 at 8:33 AM Jiri Olsa wrote:
>
> On Thu, Apr 30, 2020 at 09:45:14PM +0800, Jin, Yao wrote:
> > Hi Jiri,
> >
> > On 4/30/2020 4:45 PM, Jiri Olsa wrote:
> > > On Thu, Apr 30, 2020 at 08:36:18AM +0800, Jin Yao wrote:
> > > > A big uncore event group is split into multiple small
The following commit has been merged into the locking/urgent branch of tip:
Commit-ID: 8101b5a1531f3390b3a69fa7934c70a8fd6566ad
Gitweb:
https://git.kernel.org/tip/8101b5a1531f3390b3a69fa7934c70a8fd6566ad
Author:Thomas Gleixner
AuthorDate:Tue, 14 Apr 2020 11:07:22 +02:00
On 5/6/2020 2:40 PM, Vladimir Oltean wrote:
> Hi Florian,
>
> On Thu, 7 May 2020 at 00:24, Florian Fainelli wrote:
>>
>>
>>
>> On 5/5/2020 2:23 PM, Vivien Didelot wrote:
>>> On Tue, 5 May 2020 14:02:53 -0700, Florian Fainelli
>>> wrote:
If we are probed through platform_data we would
On 2020-05-06 17:26, Steve Grubb wrote:
> On Wednesday, April 29, 2020 5:32:47 PM EDT Richard Guy Briggs wrote:
> > On 2020-04-29 14:47, Steve Grubb wrote:
> > > On Wednesday, April 29, 2020 10:31:46 AM EDT Richard Guy Briggs wrote:
> > > > On 2020-04-28 18:25, Paul Moore wrote:
> > > > > On Wed,
On Wed, May 06, 2020 at 03:36:54PM -0700, Alexander Duyck wrote:
> On Wed, May 6, 2020 at 3:21 PM Daniel Jordan
> wrote:
> >
> > On Tue, May 05, 2020 at 07:55:43AM -0700, Alexander Duyck wrote:
> > > One question about this data. What is the power management
> > > configuration on the systems
On Wed, May 06, 2020 at 02:25:41PM -0700, Joe Perches wrote:
> On Wed, 2020-05-06 at 14:15 -0700, Kees Cook wrote:
> > From: Pavel Tatashin
> >
> > Add a new member to struct pstore_info for passing information about
> > kmesg dump maximum reason. This allows a finer control of what kmesg
> >
On Tue, May 05, 2020 at 08:27:52AM -0700, Alexander Duyck wrote:
> As it turns out that deferred_free_range will be setting the
> migratetype for the page. In a sparse config the migratetype bits are
> stored in the section bitmap. So to avoid cacheline bouncing it would
> make sense to section
On Wed, May 6, 2020 at 3:21 PM Daniel Jordan wrote:
>
> On Tue, May 05, 2020 at 07:55:43AM -0700, Alexander Duyck wrote:
> > One question about this data. What is the power management
> > configuration on the systems when you are running these tests? I'm
> > just curious if CPU frequency scaling,
On 5/6/20 3:02 PM, Babu Moger wrote:
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
> @@ -818,6 +818,10 @@ static __init void svm_set_cpu_caps(void)
> if (boot_cpu_has(X86_FEATURE_LS_CFG_SSBD) ||
> boot_cpu_has(X86_FEATURE_AMD_SSBD))
>
Hello,
On Wed, May 06, 2020 at 03:27:57PM -0700, Randy Dunlap wrote:
> Hi,
>
> Typo(s):
>
> On 5/6/20 3:22 PM, Serge Semin wrote:
> > diff --git a/drivers/clk/baikal-t1/Kconfig b/drivers/clk/baikal-t1/Kconfig
> > new file mode 100644
> > index ..e1257af9f49e
> > --- /dev/null
> >
On Wed, May 06, 2020 at 12:16:13PM -0700, Eric Biggers wrote:
> On Wed, May 06, 2020 at 02:47:19PM +0800, Gao Xiang wrote:
> > On Wed, May 06, 2020 at 09:58:22AM +0800, Gao Xiang wrote:
> > > On Tue, May 05, 2020 at 06:24:28PM -0700, Eric Biggers wrote:
> > > > On Wed, May 06, 2020 at 08:14:07AM
On 2020-05-06 4:21 p.m., Dave Hansen wrote:
>> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>> index 1197b5596d5a..8630b9fa06f5 100644
>> --- a/arch/x86/Kconfig
>> +++ b/arch/x86/Kconfig
>> @@ -1886,11 +1886,11 @@ config X86_UMIP
>>specific cases in protected and virtual-8086 modes.
Analogously to the introduction of panic_on_warn, this patch
introduces a kernel option named panic_on_taint in order to
provide a simple and generic way to stop execution and catch
a coredump when the kernel gets tainted by any given taint flag.
This is useful for debugging sessions as it avoids
Hi,
Typo(s):
On 5/6/20 3:22 PM, Serge Semin wrote:
> diff --git a/drivers/clk/baikal-t1/Kconfig b/drivers/clk/baikal-t1/Kconfig
> new file mode 100644
> index ..e1257af9f49e
> --- /dev/null
> +++ b/drivers/clk/baikal-t1/Kconfig
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier:
On 5/6/20 3:21 PM, Dave Hansen wrote:
> I'm really just wondering what the point of the churn is.
The config option is also in the manpages, fwiw:
http://man7.org/linux/man-pages/man7/pkeys.7.html
By the way, I am regretting ever sticking "INTEL_" in there. Seems like
a good best
On Wed, May 6, 2020 at 2:00 AM Jun Li wrote:
> John Stultz 于2019年10月30日周三 上午5:18写道：
> > On Tue, Oct 29, 2019 at 2:11 AM Felipe Balbi wrote:
> > > John Stultz writes:
> > > > From: Yu Chen
> > > >
> > > > It needs more time for the device controller to clear the CmdAct of
> > > > DEPCMD on
On Wed, May 06, 2020 at 05:02:21PM -0500, Babu Moger wrote:
> static __init int svm_hardware_setup(void)
> @@ -1300,6 +1304,8 @@ static void svm_vcpu_load(struct kvm_vcpu *vcpu, int
> cpu)
> indirect_branch_prediction_barrier();
> }
> avic_vcpu_load(vcpu, cpu);
> +
> +
Baikal-T1 is supposed to be supplied with a high-frequency external
oscillator. But in order to create signals suitable for each IP-block
embedded into the SoC the oscillator output is primarily connected to
a set of CCU PLLs. There are five of them to create clocks for the MIPS
P5600 cores, an
Nearly each Baikal-T1 IP-core is supposed to have a clock source
of particular frequency. But since there are greater than five
IP-blocks embedded into the SoC, the CCU PLLs can't fulfill all the
needs. Baikal-T1 CCU provides a set of fixed and configurable clock
dividers in order to generate a
After being gained by the CCU PLLs the signals must be transformed to
be suitable for the clock-consumers. This is done by a set of dividers
embedded into the CCU. A first block of dividers is used to create
reference clocks for AXI-bus of high-speed peripheral IP-cores of the
chip. The second
Clocks Control Unit is the core of Baikal-T1 SoC responsible for the chip
subsystems clocking and resetting. The CCU is connected with an external
fixed rate oscillator, which signal is transformed into clocks of various
frequencies and then propagated to either individual IP-blocks or to groups
Baikal-T1 Clocks Control Unit is responsible for transformation of a
signal coming from an external oscillator into clocks of various
frequencies to propagate them then to the corresponding clocks
consumers (either individual IP-blocks or clock domains). In order
to create a set of high-frequency
On Tue, May 05, 2020 at 07:55:43AM -0700, Alexander Duyck wrote:
> One question about this data. What is the power management
> configuration on the systems when you are running these tests? I'm
> just curious if CPU frequency scaling, C states, and turbo are
> enabled?
Yes, intel_pstate is
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 1197b5596d5a..8630b9fa06f5 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1886,11 +1886,11 @@ config X86_UMIP
> specific cases in protected and virtual-8086 modes. Emulated
> results are dummy.
>
> -config
Hi all,
On Tue, 14 Apr 2020 11:07:22 +0200 Thomas Gleixner wrote:
>
> Stephen reported the following build warning on a ARM multi_v7_defconfig
> build with GCC 9.2.1:
>
> kernel/futex.c: In function 'do_futex':
> kernel/futex.c:1676:17: warning: 'oldval' may be used uninitialized in this
>
On Wed, May 06, 2020 at 08:10:57PM +0200, Christophe Leroy wrote:
> Le 06/05/2020 à 19:58, Segher Boessenkool a écrit :
> >> #define __put_user_asm_goto(x, addr, label, op) \
> >>asm volatile goto( \
> >>- "1: " op "%U1%X1
Move dump_misc_regs earlier so decoded register contents are shown
even if ECC cannot be enabled. The dump gives info such as number of
memory controllers, so it serves as a sensible smoke-check even on
platforms without ECC memory.
Signed-off-by: Alexander Monakov
Cc: Borislav Petkov
Cc:
Add the internal audio DAC to the gxl SoC DT
Signed-off-by: Jerome Brunet
---
arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
b/arch/arm64/boot/dts/amlogic/meson-gxl.dtsi
index
Add the internal DAC support on the libretech CC. The output of this
DAC is provided on the 3.5mm jack connector.
Signed-off-by: Jerome Brunet
---
.../amlogic/meson-gxl-s905x-libretech-cc.dts | 30 +++
1 file changed, 30 insertions(+)
diff --git
add the internal DAC glue support on the g12 and sm1 family
This glue connects the different TDM interfaces of the SoC to
the internal audio DAC codec.
Signed-off-by: Jerome Brunet
---
arch/arm64/boot/dts/amlogic/meson-g12.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git
add internal audio DAC support on the g12 and sm1 SoC family
Signed-off-by: Jerome Brunet
---
arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-g12-common.dtsi
This patchset adds support for the internal audio DAC found on the gxl,
g12 and sm1 SoC family.
It was mainly tested on the gxl libretech-cc and g12a u200.
/!\
This series (patches 1 in particular) depends on this reset binding [0].
Philipp has provided an immutable with it here [1]
[0]:
Add the necessary bits to support the internal audio DAC the p230/q200
reference design derivated boards. The output of this DAC is provided
on the 3.5mm jack connector
Signed-off-by: Jerome Brunet
---
.../boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 32 +++
1 file changed, 32
There are now several commercially available processors that have h/w
fixes for the TSX Async Abort (TAA) issue as indicated by enumerating
the ARCH_CAPABILITIES "TAA_NO" bit.
Change the default setting to "auto" so that these CPUs will leave
TSX enabled by default.
This can still be overridden
Add the internal DAC support on the libretech CC. The output of this
DAC is provided on the 9J5 connector.
Signed-off-by: Jerome Brunet
---
.../amlogic/meson-gxl-s805x-libretech-ac.dts | 30 +++
1 file changed, 30 insertions(+)
diff --git
Add the internal DAC support on the libretech CC. The output of this
DAC is provided on the 9J4 connector.
Signed-off-by: Jerome Brunet
---
.../dts/amlogic/meson-gx-libretech-pc.dtsi| 31 +++
1 file changed, 31 insertions(+)
diff --git
On Wed, May 06, 2020 at 05:42:42PM -0400, Nathaniel McCallum wrote:
> Tested on Enarx. This requires a patch[0] for v29 support.
>
> Tested-by: Nathaniel McCallum
>
> However, we did uncover a small usability issue. See below.
>
> [0]:
>
On Wed, May 6, 2020 at 2:56 PM Andrii Nakryiko
wrote:
>
> On Wed, May 6, 2020 at 2:47 PM Ian Rogers wrote:
> >
> > On Wed, May 6, 2020 at 2:33 PM Andrii Nakryiko
> > wrote:
> > >
> > > On Wed, May 6, 2020 at 1:54 PM Ian Rogers wrote:
> > > >
> > > > Don't include libbpf_internal.h as it is
On 5/6/2020 9:24 AM, Masahiro Yamada wrote:
>> To me this is a regression, as it used to work and now it does not, thus
>> we should be fixing it, any idea about how we go about it without doing
>> a plain revert?
>
>
> In fact, a patch exists.
>
>
On Wed, May 06, 2020 at 10:03:52PM +0800, Jason Yan wrote:
> The '==' expression itself is bool, no need to convert it to bool again.
> This fixes the following coccicheck warning:
Make sense.
It may belong to bpf-next instead.
Acked-by: Martin KaFai Lau
AMD's next generation of EPYC processors support the MPK (Memory
Protection Keys) feature.
So, rename X86_INTEL_MEMORY_PROTECTION_KEYS to X86_MEMORY_PROTECTION_KEYS.
No functional changes.
Signed-off-by: Babu Moger
---
Documentation/core-api/protection-keys.rst |3 ++-
The Memory Protection Key (MPK) feature provides a way for applications
to impose page-based data access protections (read/write, read-only or
no access), without requiring modification of page tables and subsequent
TLB invalidations when the application changes protection domains.
This feature
Hi Paolo,
I love your patch! Yet something to improve:
[auto build test ERROR on tip/auto-latest]
[also build test ERROR on linus/master v5.7-rc4 next-20200505]
[cannot apply to kvm/linux-next linux/master]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve
201 - 300 of 1543 matches
Mail list logo
