This introduces support for CRC readback on gf119+, using the
documentation generously provided to us by Nvidia:
https://github.com/NVIDIA/open-gpu-doc/blob/master/Display-CRC/display-crc.txt
We expose all available CRC sources. SF, SOR, PIOR, and DAC are exposed
through a single set of "outp" so
While most of the functionality on Nvidia GPUs doesn't require using an
explicit handle instead of the main VRAM handle + offset, there are a
couple of places that do require explicit handles, such as CRC
functionality. Since this means we're about to add another
nouveau-chosen handle, let's just g
In order to make sure that we flush disable updates at the right time
when disabling CRCs, we'll need to be able to look at the outp state to
see if we're changing it at the same time that we're disabling CRCs.
So, expose the struct in disp.h.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouve
This got me confused for a bit while looking over this code: I had been
planning on adding some blocking function calls into this function, but
seeing the irqsave/irqrestore variants of spin_(un)lock() didn't make it
very clear whether or not that would actually be safe.
So I went ahead and review
Currently, we modify the depth value stored in the atomic state when
performing a commit in order to workaround the fact we haven't
implemented support for depths higher then 10 yet. This isn't idempotent
though, as it will happen every atomic commit where we modify the OR
state even if the head's
We refer to the armed hardware assembly as armh elsewhere in nouveau, so
fix the naming here to make it consistent.
This patch contains no functional changes.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/wndw.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
While we're not quite ready yet to add support for flexible wndw
mappings, we are going to need to at least keep track of the static wndw
mappings we're currently using in each head's atomic state. We'll likely
use this in the future to implement real flexible window mapping, but
the primary reason
While we expose the ability to turn off hardware dithering for nouveau,
we actually make the mistake of turning it on anyway, due to
dithering_depth containing a non-zero value if our dithering depth isn't
also set to 6 bpc.
So, fix it by never enabling dithering when it's disabled.
Signed-off-by
Add some kind of vblank workers. The interface is similar to regular
delayed works, and is mostly based off kthread_work. It allows for
scheduling delayed works that execute once a particular vblank sequence
has passed. It also allows for accurate flushing of scheduled vblank
works - in that flushi
Since we'll be allocating resources for kthread_create_worker() in the
next commit (which could fail and require us to clean up the mess),
let's simplify the cleanup process a bit by registering a
drm_vblank_init_release() action for each drm_vblank_crtc so they're
still cleaned up if we fail to in
We'll be rolling back more things in this function, and the way it's
structured is a bit confusing. So, let's clean this up a bit and just
unroll in the event of failure.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/head.c | 33 +
1 file changed, 23 inse
On Wed, Jun 24, 2020 at 03:49:47PM -0700, Andrew Morton wrote:
> On Wed, 24 Jun 2020 22:36:18 + HORIGUCHI NAOYA(堀口 直也)
> wrote:
>
> > On Wed, Jun 24, 2020 at 12:17:42PM -0700, Andrew Morton wrote:
> > > On Wed, 24 Jun 2020 15:01:22 + nao.horigu...@gmail.com wrote:
> > >
> > > > I rebase
Acer C720 running Linux v5.3 reports this in klog:
tpm_tis: 1.2 TPM (device-id 0xB, rev-id 16)
tpm tpm0: tpm_try_transmit: send(): error -5
tpm tpm0: A TPM error (-5) occurred attempting to determine the timeouts
tpm_tis tpm_tis: Could not get TPM timeouts and durations
tpm_tis 00:08: 1.2 TPM (dev
On Wed, Jun 24, 2020 at 11:57:14PM +0800, Kent Gibson wrote:
> On Wed, Jun 24, 2020 at 05:46:33PM +0300, Andy Shevchenko wrote:
> > On Tue, Jun 23, 2020 at 7:03 AM Kent Gibson wrote:
> > >
> > > Merge separate usage of test_bit/set_bit into test_and_set_bit to remove
> > > the possibility of a rac
Hi Tiezhu,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.8-rc2 next-20200624]
[cannot apply to tip/irq/core omap/for-next xlnx/master
arm-jcooper/irqchip/for-next]
[If your patch is applied to the wrong git tree, kindly
The manual call to set_thread_area() via int $0x80 was missing any
indication that the descriptor was a pointer, causing gcc to
occasionally generate wrong code. Add the missing constraint.
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/fsgsbase.c | 3 ++-
1 file changed, 2 inse
The first two are trivial selftest fixes. The third one fixes an actual
regression.
Andy Lutomirski (3):
selftests/x86/fsgsbase: Fix a comment in the ptrace_write_gsbase test
selftests/x86/fsgsbase: Add a missing memory constraint
x86/ptrace: Fix 32-bit PTRACE_SETREGS vs fsbase and gsbase
A comment was unclear. Fix it.
Fixes: 5e7ec8578fa3 ("selftests/x86/fsgsbase: Test ptracer-induced GS base
write with FSGSBASE")
Signed-off-by: Andy Lutomirski
---
tools/testing/selftests/x86/fsgsbase.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftest
Debuggers expect that doing PTRACE_GETREGS, then poking at a tracee
and maybe letting it run for a while, then doing PTRACE_SETREGS will
put the tracee back where it was. In the specific case of a 32-bit
tracer and tracee, the PTRACE_GETREGS/SETREGS data structure doesn't
have fs_base or gs_base f
On Wed, 24 Jun 2020 22:36:18 + HORIGUCHI NAOYA(堀口 直也)
wrote:
> On Wed, Jun 24, 2020 at 12:17:42PM -0700, Andrew Morton wrote:
> > On Wed, 24 Jun 2020 15:01:22 + nao.horigu...@gmail.com wrote:
> >
> > > I rebased soft-offline rework patchset [1][2] onto the latest mmotm. The
> > > rebas
On Wed, Jun 24, 2020 at 03:20:59PM -0700, Dan Williams wrote:
>On Wed, Jun 24, 2020 at 3:06 PM Wei Yang
> wrote:
>>
>> On Wed, Jun 24, 2020 at 09:10:09AM -0700, Dan Williams wrote:
>> >On Tue, Jun 23, 2020 at 11:14 PM Wei Yang
>> > wrote:
>> >>
>> >> On Tue, Jun 23, 2020 at 05:18:28PM +0200, Michal
Quoting Aisheng Dong (2020-06-23 19:59:09)
> > > > > - bool
> > > > > - def_bool ARCH_MXC
> > > > > + tristate "IMX clock"
> > > > > + depends on ARCH_MXC
> > > > >
> > > > > But user can still set MXC_CLK to be m, either via make menuconfig
> > > > > or
> > > > defconfig.
>
Hi Deepak,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.8-rc2 next-20200624]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
Christoph, Sagi and Keith,
On 6/24/20 9:44 AM, Christoph Hellwig wrote:
> This looks good to me, but I'd rather wait a few releases to
> avoid too mush backporting pain.
>
Here is a summary, for longer explanation please have a look at the
end [1] :-
Pros:
1. Code looks uniform and follows stri
Nah, it does not crash. It just does not work properly.
If my memory isn't corrupted, rpmcc doesn't load and regulator
voltages aren't brought up.
It is safe to merge, as the worst case scenario is it just
not loading.
Regards
Konrad
On Mon, Jun 22, 2020 at 4:47 AM Peter Zijlstra wrote:
>
> On Thu, Jun 18, 2020 at 11:18:23PM +0200, Peter Zijlstra wrote:
>
> > > So maybe also do an untraced cond_local_irq_enable()? After all, if
> > > we’re trying to report a bug from IRQs on, it should be okay to have
> > > IRQs on while repo
Hi Christophe,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on firewire/for-next]
[also build test ERROR on v5.8-rc2 next-20200624]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use as documented in
On Wed, Jun 24, 2020 at 12:17:42PM -0700, Andrew Morton wrote:
> On Wed, 24 Jun 2020 15:01:22 + nao.horigu...@gmail.com wrote:
>
> > I rebased soft-offline rework patchset [1][2] onto the latest mmotm. The
> > rebasing required some non-trivial changes to adjust, but mainly that was
> > strai
On 6/24/20 3:23 PM, Randy Dunlap wrote:
> On 6/24/20 3:01 PM, Richard Weinberger wrote:
>> On Wed, Jun 24, 2020 at 11:29 PM Randy Dunlap wrote:
>>>
>>> On 6/24/20 1:36 PM, Kees Cook wrote:
On Wed, Jun 24, 2020 at 09:23:25AM +0200, Richard Weinberger wrote:
> - Ursprüngliche Mail -
My Name is Miss Amina Ibrahim from Libya, I am 23 years old, I am in
St.Christopher's Parish for refugee in Burkina Faso under United
Nations High commission for Refugee,I lost my parents in the recent
war in Libya, right now am in Burkina Faso, please save my life i am
in danger need your help in
On 6/24/20 12:41 PM, Souptick Joarder wrote:
> On Wed, Jun 24, 2020 at 9:07 PM Boris Ostrovsky
> wrote:
>> On 6/23/20 9:36 PM, Souptick Joarder wrote:
>>> On Tue, Jun 23, 2020 at 11:11 PM Boris Ostrovsky
>>> wrote:
On 6/23/20 7:58 AM, Souptick Joarder wrote:
> In 2019, we introduced pin_
Quoting Konrad Dybcio (2020-06-24 08:09:18)
> I should also note that for quite some time a hack [1]
> has been needed on some platforms for the RPMCC to register.
>
> This includes 8992/94, 8956/76 and possibly many more.
>
> With that commit, RPMCC registers fine.
>
What happens if that patch
On 06/18, Chao Yu wrote:
> - Add to account and show per-log dirty_seg, full_seg and valid_blocks
> in debugfs.
> - reformat printed info.
>
> TYPEsegnosecno zoneno dirty_seg full_seg valid_blk
> - COLD data: 1523 1523 1523 1 0399
On Wed, Jun 24, 2020 at 10:41:18AM +0200, David Hildenbrand wrote:
>On 24.06.20 10:13, Wei Yang wrote:
>> On Wed, Jun 24, 2020 at 09:48:43AM +0200, David Hildenbrand wrote:
>>> On 23.06.20 17:18, Michal Hocko wrote:
On Tue 23-06-20 17:42:58, Wei Yang wrote:
> For early sections, we assumes
Hi,
I love your patch! Perhaps something to improve:
[auto build test WARNING on hwmon/hwmon-next]
[also build test WARNING on linux/master robh/for-next linus/master v5.8-rc2
next-20200624]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we
Rename the bit to match latest virtio spec.
Add a compat macro to avoid breaking existing userspace.
Signed-off-by: Michael S. Tsirkin
---
arch/um/drivers/virtio_uml.c | 2 +-
drivers/vdpa/ifcvf/ifcvf_base.h| 2 +-
drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 ++--
drivers/vhost/net.c
On 6/24/20 3:01 PM, Richard Weinberger wrote:
> On Wed, Jun 24, 2020 at 11:29 PM Randy Dunlap wrote:
>>
>> On 6/24/20 1:36 PM, Kees Cook wrote:
>>> On Wed, Jun 24, 2020 at 09:23:25AM +0200, Richard Weinberger wrote:
- Ursprüngliche Mail -
>>> Regardless, it seems arch/x86/um/asm/d
On Wed, Jun 24, 2020 at 3:06 PM Wei Yang
wrote:
>
> On Wed, Jun 24, 2020 at 09:10:09AM -0700, Dan Williams wrote:
> >On Tue, Jun 23, 2020 at 11:14 PM Wei Yang
> > wrote:
> >>
> >> On Tue, Jun 23, 2020 at 05:18:28PM +0200, Michal Hocko wrote:
> >> >On Tue 23-06-20 17:42:58, Wei Yang wrote:
> >> >>
On Wed, Jun 24, 2020 at 02:53:54PM -0700, Stefano Stabellini wrote:
> On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> > > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fa
://github.com/0day-ci/linux/commits/Vaibhav-Gupta/drivers-ide-use-generic-power-management/20200625-013242
base: https://git.kernel.org/pub/scm/linux/kernel/git/davem/ide.git master
config: x86_64-randconfig-a004-20200624 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-13) 9.3.0
reproduce (this
Cc: Andrew Morton
Cc: Matthew Wilcox
Cc: Rafael Aquini
Cc: Fabrizio D'Angelo
Cc: linux...@kvack.org
Cc: triv...@kernel.org
When I increased the upper bound of the min_free_kbytes value in
ee8eb9a5fe863, I forgot to tweak the above comment to reflect
the new value. This patch fixes that mistake
On 6/24/20 2:43 PM, David Miller wrote:
> From: Jisheng Zhang
> Date: Wed, 24 Jun 2020 11:25:16 +0800
>
>> We face an issue with rtl8211f, a pin is shared between INTB and PMEB,
>> and the PHY Register Accessible Interrupt is enabled by default, so
>> the INTB/PMEB pin is always active in polling
Hello
On 6/24/20 12:49 PM, Dan Murphy wrote:
Add programming for the tdm slots for both tx and rx offsets.
Signed-off-by: Dan Murphy
---
sound/soc/codecs/tas2562.c | 17 -
sound/soc/codecs/tas2562.h | 4
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/s
On Wednesday, June 24, 2020 6:04:55 AM EDT David Rheinsberg wrote:
> Hi
>
> On Tue, Jun 23, 2020 at 12:57 AM David Korth
wrote:
> > Based on a similar commit for Sony Sixaxis and DualShock 4 controllers:
> > HID: sony: Initialize the controller LEDs with a device ID value
> >
> > Wii remotes ha
On Wed, 2020-06-24 at 16:37 -0500, Bjorn Helgaas wrote:
> On Fri, Jun 12, 2020 at 01:48:19PM -0700, David E. Box wrote:
> > StorageD3Enable is a boolean property that indicates that the
> > platform
> > wants to use D3 for PCIe storage drives during suspend-to-idle.
>
> Is this something that sho
On Wed, Jun 24, 2020 at 10:51:08AM +0200, David Hildenbrand wrote:
>On 24.06.20 05:56, Wei Yang wrote:
>> On Wed, Jun 24, 2020 at 11:52:36AM +0800, Baoquan He wrote:
>>> On 06/24/20 at 11:46am, Wei Yang wrote:
On Wed, Jun 24, 2020 at 09:47:37AM +0800, Baoquan He wrote:
> On 06/23/20 at 05:
Am Mi., 17. Juni 2020 um 18:13 Uhr schrieb Greg Kroah-Hartman
:
>
> I'm announcing the release of the 5.7.3 kernel.
>
Hello Greg,
> Qiujun Huang (5):
> ath9k: Fix use-after-free Read in htc_connect_service
> ath9k: Fix use-after-free Read in ath9k_wmi_ctrl_rx
> ath9k: Fix use-af
On Wed, Jun 24, 2020 at 1:33 PM Sami Tolvanen wrote:
>
> With LTO, everything is compiled into LLVM bitcode, so we have to link
> each module into native code before modpost. Kbuild uses the .lto.o
> suffix for these files, which also ends up in module information. This
> change strips the unneces
On Wed, Jun 24, 2020 at 09:10:09AM -0700, Dan Williams wrote:
>On Tue, Jun 23, 2020 at 11:14 PM Wei Yang
> wrote:
>>
>> On Tue, Jun 23, 2020 at 05:18:28PM +0200, Michal Hocko wrote:
>> >On Tue 23-06-20 17:42:58, Wei Yang wrote:
>> >> For early sections, we assumes its memmap will never be partially
On Wed, Jun 24, 2020 at 11:29 PM Randy Dunlap wrote:
>
> On 6/24/20 1:36 PM, Kees Cook wrote:
> > On Wed, Jun 24, 2020 at 09:23:25AM +0200, Richard Weinberger wrote:
> >> - Ursprüngliche Mail -
> > Regardless, it seems arch/x86/um/asm/desc.h is not needed any more?
> >>>
> True th
On 6/23/20 1:57 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.14.186 release.
There are 136 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 should be mad
Add basic support to run QEMU via kunit_tool. Add support for i386,
x86_64, arm, arm64, and a couple others.
Signed-off-by: Brendan Higgins
---
This patch is very RFC; nevertheless, I wanted to get it out onto the
list before I fix some of the more obvious problems.
In particular, the most obvi
On 6/23/20 1:55 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.130 release.
There are 206 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 should be mad
On 6/23/20 1:53 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.4.49 release.
There are 314 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 should be made
From: Colin King
Date: Wed, 24 Jun 2020 11:13:02 +0100
> From: Colin Ian King
>
> The error DBG_STATUS_NO_MATCHING_FRAMING_MODE was added to the enum
> enum dbg_status however there is a missing corresponding entry for
> this in the array s_status_str. This causes an out-of-bounds read when
> i
On 6/23/20 1:49 PM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.7.6 release.
There are 477 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 should be made b
On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> On Wed, Jun 24, 2020 at 10:59:47AM -0700, Stefano Stabellini wrote:
> > On Wed, 24 Jun 2020, Michael S. Tsirkin wrote:
> > > On Wed, Jun 24, 2020 at 05:17:32PM +0800, Peng Fan wrote:
> > > > Export xen_swiotlb for all platforms using xen swiotlb
> >
On Wed, Jun 24, 2020 at 01:58:57PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Wed, Jun 24, 2020 at 1:33 PM Sami Tolvanen wrote:
> >
> > Filter out CC_FLAGS_LTO for the vDSO.
>
> Just curious about this patch (and the following one for x86's vdso),
> do you happen to recall speci
On Wed, Jun 24, 2020 at 06:17:35PM +0300, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici
>
> Add a debugfs file to print information in the
> BLACKBOX_INFORMATION register. Contains information
> about the number of stored records, logic index and id
> of the latest record.
How is
On Wed, Jun 24, 2020 at 05:35:58PM -0400, Maurizio Drocco wrote:
> From: Maurizio
>
> cal_bootaggr should include PCRs 8-9 in non-SHA1 digests.
>
> Signed-off-by: Maurizio Drocco
> ---
> Changelog:
> v3:
> - Fixed patch description
> v2:
> - Always include PCRs 8 & 9 to non-sha1 hashes
> v1:
>
On Tue, Jun 23, 2020 at 08:36:57PM +0300, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici
>
> Use the nvmem kernel api to expose the black box
> chip functionality to userspace.
>
> Signed-off-by: Alexandru Tachici
> ---
> drivers/hwmon/pmbus/adm1266.c | 134 +
On Wed, 24 Jun 2020 22:11:56 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-17 23:09:44 [+0200], Stephen Berman wrote:
>>
>> Attached.
>
> I did not forget about this but had recently little time to look into
> this.
No problem!
Steve Berman
On Wed, Jun 24, 2020 at 11:19:08PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 24, 2020 at 01:31:43PM -0700, Sami Tolvanen wrote:
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > index 30827f82ad62..12b115152532 100644
> > --- a/include/linux/compiler.h
> > +++ b/include/linu
From: Sascha Hauer
Date: Wed, 24 Jun 2020 09:00:45 +0200
> When writing the serdes configuration register was moved to
> mvneta_config_interface() the whole code block was removed from
> mvneta_port_power_up() in the assumption that its only purpose was to
> write the serdes configuration registe
From: Sascha Hauer
Date: Wed, 24 Jun 2020 09:00:44 +0200
> In mvneta_config_interface() the RGMII modes are catched by the default
> case which is an error return. The RGMII modes are valid modes for the
> driver, so instead of returning an error add a break statement to return
> successfully.
>
On Wed, Jun 24, 2020 at 11:27:37PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 24, 2020 at 01:31:42PM -0700, Sami Tolvanen wrote:
> > With LTO, LLVM bitcode won't be compiled into native code until
> > modpost_link. This change postpones calls to recordmcount until after
> > this step.
> >
> > In o
From: Jisheng Zhang
Date: Wed, 24 Jun 2020 11:25:16 +0800
> We face an issue with rtl8211f, a pin is shared between INTB and PMEB,
> and the PHY Register Accessible Interrupt is enabled by default, so
> the INTB/PMEB pin is always active in polling mode case.
>
> As Heiner pointed out "I was thi
On Tue, Jun 23, 2020 at 08:36:56PM +0300, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici
>
> Add two ioctl commands for reading the current state
> of the adm1266 sequencer and sending commands.
>
> Signed-off-by: Alexandru Tachici
> Reported-by: kernel test robot
This doesn't
On Fri, Jun 12, 2020 at 01:48:19PM -0700, David E. Box wrote:
> StorageD3Enable is a boolean property that indicates that the platform
> wants to use D3 for PCIe storage drives during suspend-to-idle.
Is this something that should apply to plug-in drives, or does this
only apply to soldered-in th
From: Maurizio
cal_bootaggr should include PCRs 8-9 in non-SHA1 digests.
Signed-off-by: Maurizio Drocco
---
Changelog:
v3:
- Fixed patch description
v2:
- Always include PCRs 8 & 9 to non-sha1 hashes
v1:
- Include non-zero PCRs 8 & 9 to boot aggregates
src/evmctl.c | 15 +--
1 fil
On Tue, Jun 23, 2020 at 08:36:55PM +0300, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici
>
> Adm1266 exposes 9 GPIOs and 16 PDIOs which are currently read-only. They
> are controlled by the internal sequencing engine.
>
> This patch makes adm1266 driver expose GPIOs and PDIOs to u
From: Antoine Tenart
Date: Tue, 23 Jun 2020 16:30:06 +0200
> This series aims at adding support for PHC and timestamping operations
> in the MSCC PHY driver, for the VSC858x and VSC8575. Those PHYs are
> capable of timestamping in 1-step and 2-step for both L2 and L4 traffic.
...
Series applied
On Wed, Jun 24, 2020 at 05:17:52PM -0400, Stefan Berger wrote:
> On 6/23/20 2:13 PM, Bruno Meneguele wrote:
> > On Tue, Jun 23, 2020 at 02:01:22PM -0400, Maurizio Drocco wrote:
> > > From: Maurizio
> > >
> > > If PCRs 8 - 9 are set (i.e. not all-zeros), cal_bootaggr should include
> > > them into
From: Maurizio
cal_bootaggr should include PCRs 8-9 in non-SHA1 digests.
Signed-off-by: Maurizio Drocco
---
Changelog:
v3:
- Fixed patch description
v2:
- Always include PCRs 8 & 9 to non-sha1 hashes
v1:
- Include non-zero PCRs 8 & 9 to boot aggregates
src/evmctl.c | 15 +--
1 fil
On Wed, Jun 24, 2020 at 02:01:59PM -0700, 'Nick Desaulniers' via Clang Built
Linux wrote:
> On Wed, Jun 24, 2020 at 1:33 PM Sami Tolvanen wrote:
> >
> > LLD always splits sections with LTO, which increases module sizes. This
> > change adds a linker script that merges the split sections in the fi
On Wed, Jun 24, 2020 at 2:15 PM Peter Zijlstra wrote:
>
> On Wed, Jun 24, 2020 at 01:31:38PM -0700, Sami Tolvanen wrote:
> > This patch series adds support for building x86_64 and arm64 kernels
> > with Clang's Link Time Optimization (LTO).
> >
> > In addition to performance, the primary motivatio
On Wed, Jun 24, 2020 at 11:15:40PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 24, 2020 at 01:31:38PM -0700, Sami Tolvanen wrote:
> > This patch series adds support for building x86_64 and arm64 kernels
> > with Clang's Link Time Optimization (LTO).
> >
> > In addition to performance, the primary m
On 6/24/20 1:36 PM, Kees Cook wrote:
> On Wed, Jun 24, 2020 at 09:23:25AM +0200, Richard Weinberger wrote:
>> - Ursprüngliche Mail -
> Regardless, it seems arch/x86/um/asm/desc.h is not needed any more?
>>>
True that, we can rip the file.
>>>
>>> Has anyone fixed the uml build erro
On Wed, Jun 24, 2020 at 01:53:52PM -0700, Nick Desaulniers wrote:
> On Wed, Jun 24, 2020 at 1:32 PM Sami Tolvanen wrote:
> >
> > diff --git a/Makefile b/Makefile
> > index ac2c61c37a73..0c7fe6fb2143 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -886,6 +886,22 @@ KBUILD_CFLAGS += $(CC_FL
On Tue, Jun 23, 2020 at 08:36:54PM +0300, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici
>
> PmBus devices support Block Write-Block Read Process
> Call described in SMBus specification v 2.0 with the
> exception that Block writes and reads are permitted to
> have up 255 data bytes
On Wed, Jun 24, 2020 at 01:31:42PM -0700, Sami Tolvanen wrote:
> With LTO, LLVM bitcode won't be compiled into native code until
> modpost_link. This change postpones calls to recordmcount until after
> this step.
>
> In order to exclude specific functions from inspection, we add a new
> code sect
On Wed, Jun 24, 2020 at 03:06:10PM -0600, Jason A. Donenfeld wrote:
> Hi Alexander,
>
> This patch introduced a behavior change around GRO_DROP:
>
> napi_skb_finish used to sometimes return GRO_DROP:
>
> > -static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
> > +static gr
The pull request you sent on Wed, 24 Jun 2020 15:07:12 +0200:
> g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux
> tags/for-linus-2020-06-24
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fbb58011fdd9ca2e2f0e329d11085ddf46830c5a
Thank you!
--
Deet-do
This reverts commit 3363179385629c1804ea846f4e72608c2201a81e.
This change is too restrictive. I've been running UML statically linked kernel
with UML_NET_VECTOR networking in a docker "FROM: scratch" container just fine.
As long as we don't reference network peers by hostname and use only IP
addr
On Wed, Jun 24, 2020 at 01:31:44PM -0700, Sami Tolvanen wrote:
> This change limits function inlining across translation unit
> boundaries in order to reduce the binary size with LTO.
>
> The -import-instr-limit flag defines a size limit, as the number
> of LLVM IR instructions, for importing func
On Wed, Jun 24, 2020 at 01:31:43PM -0700, Sami Tolvanen wrote:
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 30827f82ad62..12b115152532 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -120,7 +120,7 @@ void ftrace_likely_update(struct ftrace
On 6/22/20 11:13 PM, js1...@gmail.com wrote:
> From: Joonsoo Kim
>
> There is no difference between two migration callback functions,
> alloc_huge_page_node() and alloc_huge_page_nodemask(), except
> __GFP_THISNODE handling. This patch adds an argument, gfp_mask, on
> alloc_huge_page_nodemask() a
Hi Andrzej,
On Wed, Jun 24, 2020 at 04:03:30PM +0200, Andrzej Hajda wrote:
> On 24.06.2020 15:33, Laurent Pinchart wrote:
> > On Wed, Jun 24, 2020 at 01:41:27PM +0200, Andrzej Hajda wrote:
> >> Using probe_err code has following advantages:
> >> - shorter code,
> >> - recorded defer probe reason f
On Tue, Jun 23, 2020 at 08:36:53PM +0300, alexandru.tach...@analog.com wrote:
> From: Alexandru Tachici
>
> Add pmbus probing driver for the adm1266 Cascadable
> Super Sequencer with Margin Control and Fault Recording.
> Driver is using the pmbus_core, creating sysfs files
> under hwmon for input
On 6/23/20 2:13 PM, Bruno Meneguele wrote:
On Tue, Jun 23, 2020 at 02:01:22PM -0400, Maurizio Drocco wrote:
From: Maurizio
If PCRs 8 - 9 are set (i.e. not all-zeros), cal_bootaggr should include
them into the digest.
Wouldn't you have to check for not all-zeros in your code?
Stefan
On Wed, Jun 24, 2020 at 01:31:38PM -0700, Sami Tolvanen wrote:
> This patch series adds support for building x86_64 and arm64 kernels
> with Clang's Link Time Optimization (LTO).
>
> In addition to performance, the primary motivation for LTO is to allow
> Clang's Control-Flow Integrity (CFI) to be
On Fri, Jun 12, 2020 at 01:48:19PM -0700, David E. Box wrote:
> StorageD3Enable is a boolean property that indicates that the platform
> wants to use D3 for PCIe storage drives during suspend-to-idle. It is a
> BIOS work around that is currently in use on shipping systems like some
> Intel Comet La
Hi Tomasz,
On 2020-06-24 4:58 a.m., Tomasz Figa wrote:
> On Wed, Jun 24, 2020 at 1:54 PM Krzysztof Kozlowski wrote:
>>
>> On Wed, Jun 24, 2020 at 01:39:50PM +0200, Hans Verkuil wrote:
>>> Can someone from Samsung or someone who knows this SoC take a look at this
>>> series?
>>>
>>> This series l
Hi Vinod,
On Wed, Jun 24, 2020 at 10:56:35PM +0530, Vinod Koul wrote:
> On 24-06-20, 19:39, Laurent Pinchart wrote:
>
> > > > +/* Number of GT lanes */
> > > > +#define NUM_LANES 4
> > >
> > > Should this be coded in driver like this? Maybe future versions of
> > > hardware
On Wed, Jun 24, 2020 at 1:33 PM Sami Tolvanen wrote:
>
> With LTO, llvm-nm prints out symbols for each archive member
> separately, which results in a lot of duplicate dependencies in the
> .mod file when CONFIG_TRIM_UNUSED_SYMS is enabled. When a module
> consists of several compilation units, th
.snip..
> > Actually as per the boot flow :
> >
> > setup_arch() calls reserve_crashkernel() and pci_iommu_alloc() is
> > invoked through mm_init()/mem_init() and not via initmem_init().
> >
> > start_kernel:
> > ...
> > setup_arch()
> > reserve_crashkernel
> > reserve_crashkernel
On Thu, Jun 18, 2020 at 03:59:51PM +0200, Lars Povlsen wrote:
> This patch adds a temperature sensor driver to the Sparx5 SoC.
>
> Signed-off-by: Lars Povlsen
Sorry for the long delay.
We'll still need approval from DT for DT properties.
> ---
> Documentation/hwmon/sparx5-temp.rst | 33 +
On Wed, Jun 24, 2020 at 1:58 PM Nick Desaulniers
wrote:
>
> On Wed, Jun 24, 2020 at 1:33 PM Sami Tolvanen wrote:
> >
> > Filter out CC_FLAGS_LTO for the vDSO.
>
> Just curious about this patch (and the following one for x86's vdso),
> do you happen to recall specifically what the issues with the
Hi Rob,
On 6/12/20 5:49 PM, Suman Anna wrote:
Some Texas Instruments K3 family of SoCs have one of more Digital Signal
Processor (DSP) subsystems that are comprised of either a TMS320C66x
CorePac and/or a next-generation TMS320C71x CorePac processor subsystem.
Add the device tree bindings docume
Hi Linus,
Could you consider this pull request for 5.8-rc3?
1 bugfix patch addresses regression recently reported by
a vendor with specific compiler options. Need to fix it
in this cycle.
This commit has been in -next (since next-20200621) and
tested without strange happening.
Thanks,
Gao Xiang
201 - 300 of 1419 matches
Mail list logo
