On Sat, Oct 03, 2020 at 10:55:06AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Oct 02, 2020 at 06:17:45PM -0700, Ricardo Neri wrote:
> > Recent Intel processors combine CPUs with different types of micro-
> > architecture in the same package. There may be applications interested in
> > knowing the
On 10/5/20 5:05 PM, Russ Weight wrote:
>
> On 10/5/20 12:38 AM, Wu, Hao wrote:
>>> Subject: [PATCH v2 1/7] fpga: sec-mgr: intel fpga security manager class
>>> driver
>>>
>>> Create the Intel Security Manager class driver. The security
>>> manager provides interfaces to manage secure updates
On Mon, Oct 05, 2020 at 12:04:19PM +0200, Thierry Reding wrote:
> > +err_bus_set: __maybe_unused;
> > + bus_set_iommu(_bus_type, NULL);
> > +err_unregister:
> > + iommu_device_unregister(>iommu);
> > +err_sysfs:
> > + iommu_device_sysfs_remove(>iommu);
>
> Can you please switch to label
On Sat, Oct 03, 2020 at 10:53:45AM +0200, Greg Kroah-Hartman wrote:
> On Fri, Oct 02, 2020 at 06:17:42PM -0700, Ricardo Neri wrote:
> > Hybrid CPU topologies combine CPUs of different microarchitectures in the
> > same die. Thus, even though the instruction set is compatible among all
> > CPUs,
Quoting khs...@codeaurora.org (2020-10-05 11:02:10)
> >> + dp_del_event(dp_display, EV_DISCONNECT_PENDING_TIMEOUT);
> >> +
> >> dp_display_disable(dp_display, 0);
> >>
> >> rc = dp_display_unprepare(dp);
> >> if (rc)
> >> DRM_ERROR("DP display
On Tue, Oct 6, 2020 at 2:44 AM Matthew Wilcox wrote:
> On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote:
> > It seems to me like, if you want to make UAF exploitation harder at
> > the heap allocator layer, you could do somewhat more effective things
> > with a probably much smaller
/scm/linux/kernel/git/torvalds/linux.git
bcf876870b95592b52519ed4aafcf9d95999bc9c
config: i386-randconfig-s032-20201005 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-15) 9.3.0
reproduce:
# apt-get install sparse
# sparse version: v0.6.2-201-g24bdaac6-dirty
#
https
On Tue, Oct 06, 2020 at 12:56:33AM +0200, Jann Horn wrote:
> It seems to me like, if you want to make UAF exploitation harder at
> the heap allocator layer, you could do somewhat more effective things
> with a probably much smaller performance budget. Things like
> preventing the reallocation of
On Sat, Oct 03, 2020 at 10:49:34AM +0200, Borislav Petkov wrote:
> On Fri, Oct 02, 2020 at 06:17:41PM -0700, Ricardo Neri wrote:
> > Patch 1 of the series proposes the generic interface, with hooks
> > that architectures can override to suit their needs. The three patches
> > patches implement
On Fri, Oct 02, 2020 at 04:09:30PM -0700, Doug Anderson wrote:
> Hi,
>
> On Fri, Oct 2, 2020 at 3:28 PM Rob Herring wrote:
> >
> > On Fri, Oct 2, 2020 at 12:08 PM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Sep 30, 2020 at 1:20 PM Rob Herring wrote:
> > > >
> > > > > > >
On Sat, Oct 03, 2020 at 11:04:29AM +0200, Borislav Petkov wrote:
> On Fri, Oct 02, 2020 at 07:17:30PM -0700, Luck, Tony wrote:
> > On Sat, Oct 03, 2020 at 03:39:29AM +0200, Thomas Gleixner wrote:
> > > On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
> > > > Add support to discover and enumerate
Hi, Boris,
On Mon, Oct 05, 2020 at 11:35:06AM +0200, Borislav Petkov wrote:
> On Mon, Sep 28, 2020 at 03:12:53PM -0700, Fenghua Yu wrote:
> > MBM total and local readings are corrected by the following correction
> > factor table on Broadwell server and Skylake server.
> >
> > core
: powerpc-randconfig-r035-20201005 (attached as .config)
compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project
39fc4a0b0af69772ee360b5f729b1ec453217793)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin
On 10/5/2020 3:26 PM, Cristian Marussi wrote:
Hi,
this series introduces the support for the new SCMI Voltage Domain Protocol
defined by the upcoming SCMIv3.0 specification, whose BETA release is
available at [1].
Afterwards, a new generic SCMI Regulator driver is developed on top of the
On Mon, 5 Oct 2020 19:18:47 +0100
Julien Grall wrote:
> Hi Masami,
>
> On 05/10/2020 14:39, Masami Hiramatsu wrote:
> > Use per_cpu_ptr_to_phys() instead of virt_to_phys() for per-cpu
> > address conversion.
> >
> > In xen_starting_cpu(), per-cpu xen_vcpu_info address is converted
> > to gfn
On Thu, 1 Oct 2020 at 20:19, Joe Perches wrote:
>
> On Thu, 2020-10-01 at 14:39 -0500, Segher Boessenkool wrch/ote:
> > Hi!
> >
> > On Thu, Oct 01, 2020 at 12:15:39PM +0200, Miguel Ojeda wrote:
> > > > So it looks like the best option is to exclude these
> > > > 2 files from conversion.
> > >
> >
I am sending out this patch mainly to clarify the source of a problem
I am seeing.
An idle tcp connection is timing out on a 4.19 kernel after
conntrack unregister/re-register. By playing with SO_KEEPALIVE
setsockopts on the client I can make it timeout in a few seconds.
I could not find any
On Mon, Oct 05, 2020 at 09:00:10PM +0200, Michał Mirosław wrote:
> On Mon, Oct 05, 2020 at 10:36:36AM -0700, dmitry.torok...@gmail.com wrote:
> > Hi Michał,
> >
> > On Mon, Oct 05, 2020 at 01:09:08PM +0200, Michał Mirosław wrote:
> > > and breaking the loop will desync touch
> > > state (I would
On Mon, Oct 05, 2020 at 10:36:39AM -0700, Darrick J. Wong wrote:
> On Mon, Oct 05, 2020 at 01:14:54AM -0700, Josh Triplett wrote:
> > Ran into an ext4 regression when testing upgrades to 5.9-rc kernels:
> >
> > Commit e7bfb5c9bb3d ("ext4: handle add_system_zone() failure in
> >
Signed-off-by: kernel test robot
---
system_heap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma-buf/heaps/system_heap.c
b/drivers/dma-buf/heaps/system_heap.c
index 952f1fd9dacfda..fa17959d81795d 100644
--- a/drivers/dma-buf/heaps/system_heap.c
+++
On 10/5/20 9:26 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.19.150 release.
There are 38 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
On 10/5/20 9:26 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.4.70 release.
There are 57 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
On Sat, Oct 03, 2020 at 12:46:29PM +0200, Thomas Gleixner wrote:
> On Fri, Oct 02 2020 at 19:17, Tony Luck wrote:
>
> > On Sat, Oct 03, 2020 at 03:39:29AM +0200, Thomas Gleixner wrote:
> >> On Fri, Oct 02 2020 at 13:19, Ricardo Neri wrote:
> >> > Add support to discover and enumerate CPUs in
On Mon, Oct 05, 2020 at 03:48:09PM -0700, Ben Gardon wrote:
> On Fri, Sep 25, 2020 at 6:25 PM Paolo Bonzini wrote:
> >
> > On 25/09/20 23:23, Ben Gardon wrote:
> > > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> > > index 42dde27decd75..c07831b0c73e1 100644
> > > ---
Currently, we perform some memory init functions in paging init. But,
that will be an issue for NUMA support where DT needs to be flattened
before numa initialization and memblock_present can only be called
after numa initialization.
Move memory initialization related functions to a separate
On 10/5/20 9:25 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 5.8.14 release.
There are 85 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
Use the generic numa implementation to add NUMA support for RISC-V.
This is based on Greentime's patch[1] but modified to use generic NUMA
implementation and few more fixes.
[1] https://lkml.org/lkml/2020/1/10/233
Co-developed-by: Greentime Hu
Signed-off-by: Greentime Hu
Signed-off-by: Atish
This series attempts to move the ARM64 numa implementation to common
code so that RISC-V can leverage that as well instead of reimplementing
it again.
RISC-V specific bits are based on initial work done by Greentime Hu [1] but
modified to reuse the common implementation to avoid duplication.
[1]
As we are using generic numa implementation code, modify the acpi & numa
init functions name to indicate that generic implementation.
Signed-off-by: Atish Patra
Reviewed-by: Jonathan Cameron
Tested-by: Jonathan Cameron
---
arch/arm64/kernel/acpi_numa.c | 13 -
arch/arm64/mm/init.c
From: Greentime Hu
These two functions are used to distinguish between PROT_NONENUMA
protections and hinting fault protections.
Signed-off-by: Greentime Hu
---
arch/riscv/include/asm/pgtable.h | 20
1 file changed, 20 insertions(+)
diff --git
ARM64 numa implementation is generic enough that RISC-V can reuse that
implementation with very minor cosmetic changes. This will help both
ARM64 and RISC-V in terms of maintanace and feature improvement
Move the numa implementation code to common directory so that both ISAs
can reuse this. This
On October 5, 2020 6:41 PM, Junio C Hamano wrote:
> An early preview release Git v2.29.0-rc0 is now available for
> testing at the usual places. It is comprised of 588 non-merge
> commits since v2.28.0, contributed by 76 people, 22 of which are
> new faces.
NonStop build/tests are running. Will
On 10/5/20 12:38 AM, Wu, Hao wrote:
>> Subject: [PATCH v2 1/7] fpga: sec-mgr: intel fpga security manager class
>> driver
>>
>> Create the Intel Security Manager class driver. The security
>> manager provides interfaces to manage secure updates for the
>> FPGA and BMC images that are stored in
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/mach-imx/mach-mx31moboard.c
between commit:
f47e22d65d08 ("dma-mapping: split ")
from the dma-mapping tree and commit:
c93197b0041d ("ARM: imx: Remove i.MX31 board files")
from the arm-soc tree.
I fixed
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/mach-imx/mach-imx27_visstrim_m10.c
between commit:
f47e22d65d08 ("dma-mapping: split ")
from the dma-mapping tree and commit:
879c0e5e0ac7 ("ARM: imx: Remove i.MX27 board files")
from the arm-soc tree.
I
On Mon, Oct 05, 2020 at 10:36:39AM -0700, Darrick J. Wong wrote:
> > Commit e7bfb5c9bb3d ("ext4: handle add_system_zone() failure in
> > ext4_setup_system_zone()") breaks mounting of read-only ext4 filesystems
> > with intentionally overlapping bitmap blocks.
> >
> > On an always-read-only
months ago
config: openrisc-randconfig-r001-20201005 (attached as .config)
compiler: or1k-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
#
https
As more email from git history gets aimed at the OpenWall
kernel-hardening@ list, there has been a desire to separate "new topics"
from "on-going" work. To handle this, the superset of hardening email
topics are now to be directed to linux-harden...@vger.kernel.org. Update
the MAINTAINERS file and
From: Nick Desaulniers
Date: Mon, 5 Oct 2020 10:50:35 -0700
> Now that the lore archive has been set up
> (https://lore.kernel.org/linux-toolchains/), would you mind linking to
> it from http://vger.kernel.org/vger-lists.html under archives of
> linux-toolchains?
Done.
On Mon, Oct 05, 2020 at 04:19:49PM -0700, Randy Dunlap wrote:
> On 10/5/20 3:53 PM, Kees Cook wrote:
> > As more email from git history gets aimed at the OpenWall
> > kernel-hardening@ list, there has been a desire to separate "new topics"
> > from "on-going" work. To handle this, the superset of
On Sun, Oct 04, 2020 at 06:43:36PM +0300, Leon Romanovsky wrote:
> This series extends __sg_alloc_table_from_pages to allow chaining of
> new pages to already initialized SG table.
>
> This allows for the drivers to utilize the optimization of merging contiguous
> pages without a need to pre
On Tue, Oct 06, 2020 at 12:43:31AM +0200, Daniel Vetter wrote:
> > iow I think I can outright delete the frame vector stuff.
>
> Ok this doesn't work, because dma_mmap always uses a remap_pfn_range,
> which is a VM_IO | VM_PFNMAP vma and so even if it's cma backed and
> not a carveout, we can't
On 10/5/20 9:25 AM, Alan Stern wrote:
On Mon, Oct 05, 2020 at 05:21:30PM +0200, Andrey Konovalov wrote:
On Mon, Oct 5, 2020 at 5:18 PM Greg Kroah-Hartman
wrote:
On Mon, Oct 05, 2020 at 05:08:11PM +0200, Andrey Konovalov wrote:
Dear USB and USB/IP maintainers,
While fuzzing the USB/IP stack
cpumask can change underneath us, which is generally safe except when we
call into hv_cpu_number_to_vp_number(): if cpumask ends up empty we pass
num_cpu_possible() into hv_cpu_number_to_vp_number(), causing it to read
garbage. As reported by KASAN:
[ 83.504763] BUG: KASAN: slab-out-of-bounds
We have code that calls into hv_cpu_number_to_vp_number() without
checking that the cpu number is valid, which would cause
hv_cpu_number_to_vp_number() to dereference invalid memory.
Instead, have hv_cpu_number_to_vp_number() fail gracefully and add a
warning to make sure we catch these issues
Hi Kenny,
On Wed, Apr 29, 2020 at 08:41:26PM +0200, Kenny Levinsen wrote:
> All evdev clients share a common waitgroup. On new input events, this
> waitgroup is woken once for every client that did not filter the events,
I am having trouble parsing the changelog (I think I agree with the
change
On Mon, Oct 5, 2020 at 3:41 PM Junio C Hamano wrote:
>
> An early preview release Git v2.29.0-rc0 is now available for
> testing at the usual places.
I've run Bitbucket Server's test matrix over the release candidate. No
failures to report.
Thanks again for these early milestones! I really
On Mon, Oct 05, 2020 at 02:59:04PM -0500, Rob Herring wrote:
> On Mon, Oct 5, 2020 at 2:36 PM Alan Stern wrote:
> >
> > On Mon, Oct 05, 2020 at 12:18:12PM -0700, Matthias Kaehlcke wrote:
> > > On Mon, Oct 05, 2020 at 12:15:27PM -0400, Alan Stern wrote:
> > > > The conclusion is that we need to
On Mon, Oct 5, 2020 at 8:00 AM Qais Yousef wrote:
>
> +CC Steve and Peter - they might be interested.
>
> On 10/02/20 11:07, Rob Clark wrote:
> > On Fri, Oct 2, 2020 at 4:01 AM Qais Yousef wrote:
> > >
> > > On 09/30/20 14:17, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > The android
On 10/5/20 3:53 PM, Kees Cook wrote:
> As more email from git history gets aimed at the OpenWall
> kernel-hardening@ list, there has been a desire to separate "new topics"
> from "on-going" work. To handle this, the superset of hardening email
> topics are now to be directed to
On Monday, October 5, 2020 5:31 PM, Sudip Mukherjee
wrote:
> find_tt() can return NULL or the error value in ERR_PTR() and
> dereferencing the return value without checking for the error can
> lead to a possible dereference of NULL pointer or ERR_PTR().
Looks fine to me. There is in fact no
Hi Viresh,
On Monday 05 Oct 2020 at 13:28:22 (+0530), Viresh Kumar wrote:
> On 27-08-20, 12:27, Ionela Voinescu wrote:
> > I am in the middle of unifying AMU counter and cpufreq invariance through
> > something like this, so if you like the idea and you don't think I'm
> > stepping too much on
Rob Herring 於 2020年10月6日 週二 上午2:57寫道：
>
> On Mon, Oct 5, 2020 at 12:17 PM Phil Chang wrote:
> >
> > Hi Chun-Kuang
>
> Please don't top post to the lists.
>
> > Sorry for typo. In fact, the dts of new SoC is not upstream yet. I'm so
> > sorry for couldn't show the detail now.
>
> Don't have to
05.10.2020 23:52, Wolfram Sang пишет:
> On Wed, Sep 30, 2020 at 01:18:43AM +0300, Dmitry Osipenko wrote:
>> Hello!
>>
>> This series performs refactoring of the Tegra I2C driver code and hardens
>> the atomic-transfer mode.
>
> Applied to for-next, thanks to everyone! Please send incremental
On Mon, Oct 5, 2020 at 3:30 PM Andy Lutomirski wrote:
>
> x86_32 stackprotector is a maintenance nightmare. Clean it up. This
> disables stackprotector on x86_32 on GCC 8.1 and on all clang
> versions -- I'll file a bug for the latter.
This should be doable on 64-bit too. All that would need
I proposed two algorithms in my last response. The following summarizes the
results from executing your scenario:
bound queues:
0.0
0.1
1.0
2.0
2.1
algorithm: use filtering on assign/unassign
scenario:
echo 0 > assign_domain
echo 1 > assign_domain
echo 1 > assign_adapter
matrix:
1.0
1.1
On Mon, Oct 5, 2020 at 7:15 AM Daniel Vetter wrote:
>
> On Mon, Oct 05, 2020 at 03:15:24PM +0300, Ville Syrjälä wrote:
> > On Fri, Oct 02, 2020 at 10:55:52AM -0700, Rob Clark wrote:
> > > On Fri, Oct 2, 2020 at 4:05 AM Ville Syrjälä
> > > wrote:
> > > >
> > > > On Fri, Oct 02, 2020 at 01:52:56PM
On Thu, Oct 1, 2020 at 9:43 PM Alexander Popov wrote:
> On 29.09.2020 21:35, Alexander Popov wrote:
> > This is the second version of the heap quarantine prototype for the Linux
> > kernel. I performed a deeper evaluation of its security properties and
> > developed new features like quarantine
As more email from git history gets aimed at the OpenWall
kernel-hardening@ list, there has been a desire to separate "new topics"
from "on-going" work. To handle this, the superset of hardening email
topics are now to be directed to linux-harden...@vger.kernel.org. Update
the MAINTAINTERS file
An early preview release Git v2.29.0-rc0 is now available for
testing at the usual places. It is comprised of 588 non-merge
commits since v2.28.0, contributed by 76 people, 22 of which are
new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The
On Fri, Sep 25, 2020 at 6:25 PM Paolo Bonzini wrote:
>
> On 25/09/20 23:23, Ben Gardon wrote:
> > diff --git a/arch/x86/kvm/mmu/tdp_mmu.c b/arch/x86/kvm/mmu/tdp_mmu.c
> > index 42dde27decd75..c07831b0c73e1 100644
> > --- a/arch/x86/kvm/mmu/tdp_mmu.c
> > +++ b/arch/x86/kvm/mmu/tdp_mmu.c
> > @@
On Mon, Oct 5, 2020 at 8:54 PM Daniel Vetter wrote:
>
> On Mon, Oct 5, 2020 at 8:37 PM Jason Gunthorpe wrote:
> >
> > On Mon, Oct 05, 2020 at 08:16:33PM +0200, Daniel Vetter wrote:
> >
> > > > kvm is some similar hack added for P2P DMA, see commit
> > > >
From: Jaegeuk Kim
In order to conduct FFU or RPMB operations, UFS needs to clear UAC. This patch
clears it explicitly, so that we could get no failure given early execution.
Cc: Alim Akhtar
Cc: Avri Altman
Cc: Can Guo
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 70
From: Jaegeuk Kim
This adds user-friendly tracepoints with group id.
Cc: Alim Akhtar
Cc: Avri Altman
Cc: Can Guo
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 6 --
include/trace/events/ufs.h | 21 +
2 files changed, 21 insertions(+), 6 deletions(-)
From: Jaegeuk Kim
Must have WQ_MEM_RECLAIM
``WQ_MEM_RECLAIM``
All wq which might be used in the memory reclaim paths **MUST**
have this flag set. The wq is guaranteed to have at least one
execution context regardless of memory pressure.
Cc: Alim Akhtar
Cc: Avri Altman
Cc: Can Guo
From: Jaegeuk Kim
When giving a stress test which enables/disables clkgating, we hit device
timeout sometimes. This patch avoids subtle racy condition to address it.
Cc: Alim Akhtar
Cc: Avri Altman
Cc: Can Guo
Signed-off-by: Jaegeuk Kim
---
drivers/scsi/ufs/ufshcd.c | 12 ++--
1
On Mon, 5 Oct 2020 03:44:01 +0200, Jann Horn wrote:
> Currently, init_listener() tries to prevent adding a filter with
> SECCOMP_FILTER_FLAG_NEW_LISTENER if one of the existing filters already
> has a listener. However, this check happens without holding any lock that
> would prevent another
On Mon, Oct 5, 2020 at 4:47 PM Paul Cercueil wrote:
>
> Hi,
>
> Le lun. 5 oct. 2020 à 16:05, Daniel Vetter a écrit :
> > On Mon, Oct 05, 2020 at 11:01:50PM +1100, Stephen Rothwell wrote:
> >> Hi Paul,
> >>
> >> On Sun, 04 Oct 2020 22:11:23 +0200 Paul Cercueil
> >> wrote:
> >> >
> >> >
On 05/10/2020 09:13:08-0400, Peter Geis wrote:
> Good Morning,
>
> While testing suspend to ram on the Ouya, I encountered an interesting
> issue with the rtc-tps65910 driver.
> Attempting to use rtc-wake on the default configuration returned:
> rtcwake: /dev/rtc0 not enabled for wakeup events
>
Add SCMI Voltage Domain device name to the core list of supported protocol
devices.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/driver.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/firmware/arm_scmi/driver.c
b/drivers/firmware/arm_scmi/driver.c
index
Add a simple regulator based on SCMI Voltage Domain Protocol.
Supported operations are:
- .enable / .disable / .is_enabled: routed via SCMI Voltage Domain Protocol
- .get_voltage / .set_voltage: routed via SCMI Voltage Domain Protocol
- .get_voltage_sel/.set_voltage_sel: using regulator framework
Add devicetree bindings to support regulators based on SCMI Voltage
Domain Protocol.
Signed-off-by: Cristian Marussi
---
.../devicetree/bindings/arm/arm,scmi.txt | 44 +++
1 file changed, 44 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt
Hi,
this series introduces the support for the new SCMI Voltage Domain Protocol
defined by the upcoming SCMIv3.0 specification, whose BETA release is
available at [1].
Afterwards, a new generic SCMI Regulator driver is developed on top of the
new SCMI VD Protocol.
The series is currently based
Add SCMI Voltage Domain protocol support.
Signed-off-by: Cristian Marussi
---
drivers/firmware/arm_scmi/Makefile | 2 +-
drivers/firmware/arm_scmi/common.h | 1 +
drivers/firmware/arm_scmi/driver.c | 2 +
drivers/firmware/arm_scmi/voltage.c | 378
On Sun, 4 Oct 2020 17:14:09 -0500
Tom Zanussi wrote:
> From: Steven Rostedt
>
> Change the format for printing synthetic field strings to limit the
> length of the string printed even if it's not correctly terminated.
>
> Description from Steve:
>
> I also added this for a bit of paranoid,
Signed-off-by: Alejandro Colomar
---
man3/off_t.3 | 1 +
1 file changed, 1 insertion(+)
create mode 100644 man3/off_t.3
diff --git a/man3/off_t.3 b/man3/off_t.3
new file mode 100644
index 0..db50c0f09
--- /dev/null
+++ b/man3/off_t.3
@@ -0,0 +1 @@
+.so man7/system_data_types.7
--
Signed-off-by: Alejandro Colomar
---
man7/system_data_types.7 | 50
1 file changed, 50 insertions(+)
diff --git a/man7/system_data_types.7 b/man7/system_data_types.7
index b8cbc8ffe..916efef08 100644
--- a/man7/system_data_types.7
+++
Hi Michael,
On 2020-10-03 13:39, Michael Kerrisk (man-pages) wrote:
Hi Alex,
[...]
off_t would be great.
In case you are looking for some other candidates, some others
that I would be interested to see go into the page would be
fd_set
clock_t
clockid_t
and probably dev_t
Great!
off_t is
On Mon, Oct 05, 2020 at 09:40:52AM -0700, Dave Hansen wrote:
> On 10/5/20 8:02 AM, Greg KH wrote:
> > On Mon, Oct 05, 2020 at 05:23:45PM +0300, Jarkko Sakkinen wrote:
> >> [*] One thing I've been wondering for a long time is that, why new code
> >> should have the copyright platters in the first
Hi Johannes,
On Thu, Oct 1, 2020 at 8:12 AM Johannes Weiner wrote:
>
> Hello Shakeel,
>
> On Wed, Sep 30, 2020 at 08:26:26AM -0700, Shakeel Butt wrote:
> > On Mon, Sep 28, 2020 at 2:03 PM Johannes Weiner wrote:
> > > Workloads may not
> > > allocate anything for hours, and then suddenly
On Thu, Oct 01, 2020 at 12:17:30PM +0100, Lorenzo Pieralisi wrote:
> On Thu, Oct 01, 2020 at 09:42:43AM +0200, Thomas Petazzoni wrote:
> > Fixes the following build warning when CONFIG_OF is disabled:
> >
> > drivers/pci/controller/dwc/pcie-armada8k.c:344:34: warning:
> >
On 9/29/20 5:04 PM, Arvind Sankar wrote:
> There are use cases for storing the offset of a symbol in kernel_info.
> For example, the trenchboot series [0] needs to store the offset of the
> Measured Launch Environment header in kernel_info.
>
> Since commit (note: commit ID from tip/master)
>
>
On 10/5/20 2:30 PM, Halil Pasic wrote:
On Mon, 5 Oct 2020 12:24:39 -0400
Tony Krowiak wrote:
On 9/27/20 9:01 PM, Halil Pasic wrote:
On Fri, 21 Aug 2020 15:56:11 -0400
Tony Krowiak wrote:
Let's hot plug/unplug adapters, domains and control domains assigned to or
unassigned from an AP
The BQ256XX family of devices are highly integrated buck chargers
for single cell batteries.
Signed-off-by: Ricardo Rivera-Matos
v5 - adds power_supply_put_battery_info() and devm_add_action_or_rest() calls
v6 - implements bq256xx_remove function
---
drivers/power/supply/Kconfig |
Hello,
This patchset introduces the bq256xx family of charging ICs. The bq256xx
ICs are highly integrated, buck, switching chargers intended for use in
smartphones, tablets, and portable electronics.
Ricardo Rivera-Matos (2):
dt-bindings: power: Add the bq256xx dt bindings
power: supply:
Add the bindings for the bq256xx series of battery charging ICs.
Datasheets:
- https://www.ti.com/lit/ds/symlink/bq25600.pdf
- https://www.ti.com/lit/ds/symlink/bq25601.pdf
- https://www.ti.com/lit/ds/symlink/bq25600d.pdf
- https://www.ti.com/lit/ds/symlink/bq25601d.pdf
-
UV class systems no longer use System Controller for monitoring of CPU
activity provided by this driver. Other methods have been developed
for BIOS and the management controller (BMC). This patch removes that
supporting code.
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
---
Add Copyrights to those files that have been updated for UV5 changes.
Signed-off-by: Mike Travis
---
arch/x86/include/asm/uv/bios.h | 1 +
arch/x86/include/asm/uv/uv_hub.h| 1 +
arch/x86/include/asm/uv/uv_mmrs.h | 1 +
arch/x86/kernel/apic/x2apic_uv_x.c | 1 +
Hi Geert,
On Mon, Oct 05, 2020 at 02:50:49PM +0200, Geert Uytterhoeven wrote:
> The Toshiba Visconti TMPV7700 series pin controller is only present on
> Visconti SoCs. Hence add a dependency on ARCH_VISCONTI, to prevent
> asking the user about this driver when configuring a kernel without
>
Hi all,
Commit
82a18d4ce1ef ("cma: decrease CMA_ALIGNMENT lower limit to 2")
is missing a Signed-off-by from its committer.
--
Cheers,
Stephen Rothwell
pgpcX1Tk8qypU.pgp
Description: OpenPGP digital signature
On 10/5/2020 2:21 PM, Borislav Petkov wrote:
On Mon, Oct 05, 2020 at 03:39:22PM -0500, Mike Travis wrote:
A patch to add and process the UV Arch Type field in the UVsystab passed
from UV BIOS to the kernel.
What does that mean?
There have been recent cases where OEM's want to use the
On 10/5/2020 2:16 PM, Borislav Petkov wrote:
On Mon, Oct 05, 2020 at 03:39:19PM -0500, Mike Travis wrote:
Make a small symbol change (is_uv() ==> is_uv_sys()) to accommodate a
change in the uv_mmrs.h file (is_uv() is the new arch selector function).
Signed-off-by: Mike Travis
Reviewed-by:
find_tt() can return NULL or the error value in ERR_PTR() and
dereferencing the return value without checking for the error can
lead to a possible dereference of NULL pointer or ERR_PTR().
Signed-off-by: Sudip Mukherjee
---
drivers/usb/host/ehci-sched.c | 4
1 file changed, 4 insertions(+)
On Mon, Oct 05, 2020 at 03:39:22PM -0500, Mike Travis wrote:
> A patch to add and process the UV Arch Type field in the UVsystab passed
> from UV BIOS to the kernel.
What does that mean?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
On Mon, Oct 5, 2020 at 6:45 AM Dave Martin wrote:
>
> On Tue, Sep 29, 2020 at 01:57:42PM -0700, Chang S. Bae wrote:
> > During signal entry, the kernel pushes data onto the normal userspace
> > stack. On x86, the data pushed onto the user stack includes XSAVE state,
> > which has grown over time
On Mon, 05 Oct 2020 14:12:44 PDT (-0700), ati...@atishpatra.org wrote:
On Mon, Oct 5, 2020 at 12:46 PM Palmer Dabbelt wrote:
On Mon, 05 Oct 2020 11:40:54 PDT (-0700), sch...@linux-m68k.org wrote:
> On Okt 05 2020, Palmer Dabbelt wrote:
>
>> On Mon, 05 Oct 2020 01:25:22 PDT (-0700),
On Mon, Oct 05, 2020 at 03:39:19PM -0500, Mike Travis wrote:
> Make a small symbol change (is_uv() ==> is_uv_sys()) to accommodate a
> change in the uv_mmrs.h file (is_uv() is the new arch selector function).
>
> Signed-off-by: Mike Travis
> Reviewed-by: Dimitri Sivanich
> Reviewed-by: Steve
On Mon, Oct 5, 2020 at 12:46 PM Palmer Dabbelt wrote:
>
> On Mon, 05 Oct 2020 11:40:54 PDT (-0700), sch...@linux-m68k.org wrote:
> > On Okt 05 2020, Palmer Dabbelt wrote:
> >
> >> On Mon, 05 Oct 2020 01:25:22 PDT (-0700), sch...@linux-m68k.org wrote:
> >>> On Sep 14 2020, Aurelien Jarno wrote:
>
Hi,
These releases include a security fix for the LTTng kernel tracer.
This issue was introduced very early in the LTTng modules 2.0 development,
prior to the lttng-modules v2.0.0 release. Therefore all lttng-modules
releases are affected. Users are encouraged to upgrade.
See master branch
Make modifications to the MMIOH mappings to accommodate changes for UV5.
Signed-off-by: Mike Travis
Reviewed-by: Steve Wahl
Reported-by: kernel test robot
---
arch/x86/kernel/apic/x2apic_uv_x.c | 212 -
1 file changed, 144 insertions(+), 68 deletions(-)
diff --git
101 - 200 of 1486 matches
Mail list logo
