On Mon, Jun 03, 2019 at 02:42:19PM +, Rasmus Villemoes wrote:
> The data sheet also mentions the possibility of selecting 200 Mbps for
> the MII ports (ports 5 and 6) by setting the ForceSpd field to
> 0x2 (aka MV88E6065_PORT_MAC_CTL_SPEED_200). However, there's a note
> that "actual speed is
On Mon, Jun 03, 2019 at 02:34:13PM +0800, Pingfan Liu wrote:
> To better reflect the held state of pages and make code self-explaining,
> rename nr as nr_pinned.
>
> Signed-off-by: Pingfan Liu
Reviewed-by: Ira Weiny
> Cc: Ira Weiny
> Cc: Andrew Morton
> Cc: Mike Rapoport
> Cc: Dan Williams
Hi Roman,
I sorry for the delay in my answer, but I needed to set up a minimal
tutorial to show what I am working on and why I need a feature like the
one I am proposing.
Please, have a look of the README.md page here:
https://github.com/virtualsquare/vuos
(everything can be downloaded
On Mon, Jun 03, 2019 at 02:34:12PM +0800, Pingfan Liu wrote:
> As for FOLL_LONGTERM, it is checked in the slow path
> __gup_longterm_unlocked(). But it is not checked in the fast path, which
> means a possible leak of CMA page to longterm pinned requirement through
> this crack.
>
> Place a check
On Mon, Jun 03, 2019 at 02:42:12PM +, Rasmus Villemoes wrote:
> diff --git a/drivers/net/dsa/mv88e6xxx/global1.h
> b/drivers/net/dsa/mv88e6xxx/global1.h
> index bb92a130cbef..2bcbe7c8b279 100644
> --- a/drivers/net/dsa/mv88e6xxx/global1.h
> +++ b/drivers/net/dsa/mv88e6xxx/global1.h
> @@
On 03.06.2019 17:38, Kirill Tkhai wrote:
> On 22.05.2019 18:22, Kirill A. Shutemov wrote:
>> On Mon, May 20, 2019 at 05:00:01PM +0300, Kirill Tkhai wrote:
>>> This patchset adds a new syscall, which makes possible
>>> to clone a VMA from a process to current process.
>>> The syscall supplements
Hello!
On 06/03/2019 04:04 PM, Lee Jones wrote:
>>> Document the bindings used by the Renesas R-Car Gen3 RPC-IF controller.
>>>
>>> Signed-off-by: Mason Yang
>>> ---
>>> .../devicetree/bindings/mfd/renesas-rpc-if.txt | 65
>>> ++
>>> 1 file changed, 65 insertions(+)
On Fri, 2019-05-31 at 15:47 -0500, Alex Elder wrote:
> On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> > On Fri, May 31, 2019 at 6:36 PM Alex Elder
> > wrote:
> > > On 5/31/19 9:58 AM, Dan Williams wrote:
> > > > On Thu, 2019-05-30 at 22:53 -0500, Alex Elder wrote:
> > > >
> > > > My question from
On 05/31/2019 01:34 AM, Arnd Bergmann wrote:
On Thu, May 30, 2019 at 4:16 PM Vincenzo Frascino
wrote:
--- a/arch/mips/vdso/vdso.lds.S
+++ b/arch/mips/vdso/vdso.lds.S
@@ -99,6 +99,10 @@ VERSION
global:
__vdso_clock_gettime;
__vdso_gettimeofday;
+
Update the code to use a flexible array member instead of a pointer in
structure i2c_mux_pinctrl and use the struct_size() helper.
Also, make use of the struct_size() helper instead of an open-coded
version in order to avoid any potential type mistakes, in particular
in the context in which this
On Mon, Jun 3, 2019 at 4:29 PM Geert Uytterhoeven wrote:
> JFYI, when comparing v5.2-rc3[1] to v5.2-rc2[3], the summaries are:
> - build errors: +1/-3
+ error: "devm_ioremap" [drivers/counter/ftm-quaddec.ko] undefined!: => N/A
um-all{yes,mod}config (patch available)
> [1]
>
From: Matthew Wilcox [mailto:wi...@infradead.org]
Sent: Monday, June 3, 2019 5:42 PM
To: Nagal, Amit UTC CCS
On Mon, Jun 03, 2019 at 05:30:57AM +, Nagal, Amit UTC CCS
wrote:
> > [ 776.174308] Mem-Info:
> > [ 776.176650] active_anon:2037 inactive_anon:23 isolated_anon:0 [
On Fri, 2019-05-31 at 17:59 -0600, Subash Abhinov Kasiviswanathan
wrote:
> On 2019-05-31 17:33, Bjorn Andersson wrote:
> > On Fri 31 May 13:47 PDT 2019, Alex Elder wrote:
> >
> > > On 5/31/19 2:19 PM, Arnd Bergmann wrote:
> > > > On Fri, May 31, 2019 at 6:36 PM Alex Elder
> > > > wrote:
> > > >
stable-rc/linux-5.1.y boot: 132 boots: 1 failed, 131 passed
(v5.1.6-41-ge674455b9242)
Full Boot Summary:
https://kernelci.org/boot/all/job/stable-rc/branch/linux-5.1.y/kernel/v5.1.6-41-ge674455b9242/
Full Build Summary:
On Mon, Jun 03, 2019 at 11:22:15AM -0300, Helen Koike wrote:
> isp iommu requires wrapper variants of the clocks.
> noc variants are always on and using the wrapper variants will activate
> {A,H}CLK_ISP{0,1} due to the hierarchy.
>
> Also add the respective power domain.
>
> Refer:
> RK3399 TRM
In module_add_modinfo_attrs if sysfs_create_file
fails, we forget to free allocated modinfo_attrs
and roll back the sysfs files.
Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference counting")
Signed-off-by: YueHaibing
---
v3: reuse module_remove_modinfo_attrs
v2: free from '--i'
On 2019/6/3 20:11, Miroslav Benes wrote:
> On Thu, 30 May 2019, YueHaibing wrote:
>
>> In module_add_modinfo_attrs if sysfs_create_file
>> fails, we forget to free allocated modinfo_attrs
>> and roll back the sysfs files.
>>
>> Fixes: 03e88ae1b13d ("[PATCH] fix module sysfs files reference
On Mon, 2019-06-03 at 11:22 -0300, Helen Koike wrote:
> isp iommu requires wrapper variants of the clocks.
> noc variants are always on and using the wrapper variants will activate
> {A,H}CLK_ISP{0,1} due to the hierarchy.
>
> Also add the respective power domain.
>
> Refer:
> RK3399 TRM v1.4
This adds the clone3 system call.
As mentioned several times already (cf. [7], [8]) here's the promised
patchset for clone3().
We recently merged the CLONE_PIDFD patchset (cf. [1]). It took the last
free flag from clone().
Independent of the CLONE_PIDFD patchset a time namespace has been
Hi Marc,
On 2019/6/3 18:17, Marc Zyngier wrote:
> On 27/05/2019 10:39, Yongliang Gao wrote:
>> harden_branch_predictor() call smp_processor_id() in preemptible
>> context, this would cause a bug messages.
>>
>> The bug messages is as follows:
>> BUG: using smp_processor_id() in preemptible
On 6/3/2019 4:31 PM, James Bottomley wrote:
On Mon, 2019-06-03 at 16:29 +0200, Roberto Sassu wrote:
On 6/3/2019 3:43 PM, James Bottomley wrote:
On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
On 5/30/2019 2:00 PM, Mimi Zohar wrote:
On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu
Wire up the clone3() call on x86.
This patch only wires up clone3() on x86. Some of the arches look like they
need special assembly massaging and it is probably smarter if the
appropriate arch maintainers would do the actual wiring.
Signed-off-by: Christian Brauner
Cc: Arnd Bergmann
Cc: Kees
This adds support for the Marvell 88E6250. I've checked that each
member in the ops-structure makes sense, and basic switchdev
functionality works fine.
It uses the new dual_chip option, and since its port registers start
at SMI address 0x08 or 0x18 (i.e., always sw_addr + 0x08), we need to
The data sheet also mentions the possibility of selecting 200 Mbps for
the MII ports (ports 5 and 6) by setting the ForceSpd field to
0x2 (aka MV88E6065_PORT_MAC_CTL_SPEED_200). However, there's a note
that "actual speed is determined by bit 8 above", and flipping back a
page, one finds that bits
The MV88E6352_G2_WDOG_CTL_* bits almost, but not quite, describe the
watchdog control register on the mv88e6250. Among those actually
referenced in the code, only QC_ENABLE differs (bit 6 rather than bit
5).
Reviewed-by: Andrew Lunn
Reviewed-by: Vivien Didelot
Signed-off-by: Rasmus Villemoes
On Mon, Jun 03, 2019 at 10:19:18AM -0400, Stephen Smalley wrote:
> On 5/31/19 7:31 PM, Sean Christopherson wrote:
> >enclave_load() is roughly analogous to the existing file_mprotect().
> >
> >Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave
> >VMAs are backed by a single
The mv88e6250 has a rather different way of reporting the link, speed
and duplex status. A simple difference is that the link bit is bit 12
rather than bit 11 of the port status register.
It gets more complicated for speed and duplex, which do not have
separate fields. Instead, there's a four-bit
The new mv88e6250_g1_reset() is identical to mv88e6352_g1_reset() except
for the call of mv88e6352_g1_wait_ppu_polling(), so refactor the 6352
version in term of the 6250 one. No functional change.
Signed-off-by: Rasmus Villemoes
---
drivers/net/dsa/mv88e6xxx/global1.c | 14 +-
1
The mv88e6250 has port_base_addr 0x8 or 0x18 (depending on
configuration pins), so it constitutes a new family and hence needs
its own compatible string.
Signed-off-by: Rasmus Villemoes
---
Documentation/devicetree/bindings/net/dsa/marvell.txt | 7 +--
1 file changed, 5 insertions(+), 2
The 88e6250 (as well as 6220, 6071, 6070, 6020) do not support
multi-chip (indirect) addressing. However, one can still have two of
them on the same mdio bus, since the device only uses 16 of the 32
possible addresses, either addresses 0x00-0x0F or 0x10-0x1F depending
on the ADDR4 pin at reset
These are almost identical to the 6185 variants, but have fewer bits
for the FID.
Bit 10 of the VTU_OP register (offset 0x05) is the VidPolicy bit,
which one should probably preserve in mv88e6xxx_g1_vtu_op(), instead
of always writing a 0. However, on the 6352 family, that bit is
located at bit
All the currently supported chips have .num_databases either 256 or
4096, so this patch does not change behaviour for any of those. The
mv88e6250, however, has .num_databases == 64, and it does not put the
upper two bits in ATU control 13:12, but rather in ATU Operation
9:8. So change the logic to
This adds support for the mv88e6250 chip. Initially based on the
mv88e6240, this time around, I've been through each ->ops callback and
checked that it makes sense, either replacing with a 6250 specific
variant or dropping it if no equivalent functionality seems to exist
for the 6250. Along the
Quite a few of the existing supported chips that use
mv88e6085_g1_ieee_pri_map as ->ieee_pri_map (including, incidentally,
mv88e6085 itself) actually have a reset value of 0xfa50 in the
G1_IEEE_PRI register.
The data sheet for the mv88e6095, however, does describe a reset value
of 0xfa41.
So
Hi all,
On Tue, 4 Jun 2019 00:31:53 +1000 Stephen Rothwell
wrote:
>
> Hi Krzysztof,
>
> On Mon, 3 Jun 2019 16:10:40 +0200 Krzysztof Kozlowski wrote:
> >
> > Indeed it looks like effect of merge conflict resolution or applying.
> > When I look at MMOTS, it is the same as yours:
> >
On 22.05.2019 18:22, Kirill A. Shutemov wrote:
> On Mon, May 20, 2019 at 05:00:01PM +0300, Kirill Tkhai wrote:
>> This patchset adds a new syscall, which makes possible
>> to clone a VMA from a process to current process.
>> The syscall supplements the functionality provided
>> by
On Mon, Jun 3, 2019 at 10:18 AM Boris Brezillon
wrote:
>
> On Mon, 3 Jun 2019 10:11:20 -0400
> Kamal Dasu wrote:
>
> > Boris,
> >
> > On Sat, Jun 1, 2019 at 3:57 AM Boris Brezillon
> > wrote:
> > >
> > > On Thu, 30 May 2019 17:20:35 -0400
> > > Kamal Dasu wrote:
> > >
> > > > Refactored NAND
On Mon, 3 Jun 2019 at 16:32, Stephen Rothwell wrote:
>
> Hi Krzysztof,
>
> On Mon, 3 Jun 2019 16:10:40 +0200 Krzysztof Kozlowski wrote:
> >
> > Indeed it looks like effect of merge conflict resolution or applying.
> > When I look at MMOTS, it is the same as yours:
> >
I have been recently debugging some pcplist corruptions, where it would be
useful to perform struct page checks immediately as pages are allocated from
and freed to pcplists, which is now only possible by rebuilding the kernel with
CONFIG_DEBUG_VM (details in Patch 2 changelog).
To make this kind
CONFIG_DEBUG_PAGEALLOC has been redesigned by 031bc5743f15
("mm/debug-pagealloc: make debug-pagealloc boottime configurable") to allow
being always enabled in a distro kernel, but only perform its expensive
functionality when booted with debug_pagelloc=on. We can further reduce
the overhead when
The page allocator checks struct pages for expected state (mapcount, flags etc)
as pages are being allocated (check_new_page()) and freed (free_pages_check())
to provide some defense against errors in page allocator users. Prior commits
479f854a207c ("mm, page_alloc: defer debugging checks of
When debug_pagealloc is enabled, we currently allocate the page_ext array to
mark guard pages with the PAGE_EXT_DEBUG_GUARD flag. Now that we have the
page_type field in struct page, we can use that instead, as guard pages are
neither PageSlab nor mapped to userspace. This reduces memory overhead
Hello Masahiro,
On Sat, Jun 01, 2019 at 11:09:15AM +0900, Masahiro Yamada wrote:
> On Sat, Jun 1, 2019 at 2:45 AM George G. Davis
> wrote:
> > > Following this pattern, does this work for you?
> > >
> > > diff --git a/scripts/checkstack.pl b/scripts/checkstack.pl
> > > index
Hi Krzysztof,
On Mon, 3 Jun 2019 16:10:40 +0200 Krzysztof Kozlowski wrote:
>
> Indeed it looks like effect of merge conflict resolution or applying.
> When I look at MMOTS, it is the same as yours:
>
On Mon, Jun 3, 2019 at 3:31 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:69bbe8c7 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output:
The following error occurs for the `make ARCH=arm64 checkstack` case:
aarch64-linux-gnu-objdump -d vmlinux $(find . -name '*.ko') | \
perl ./scripts/checkstack.pl arm64
wrong or unknown architecture "arm64"
As suggested by Masahiro Yamada, fix the above error using regular
expressions in the
Below is the list of build error/warning regressions/improvements in
v5.2-rc3[1] compared to v5.1[2].
Summarized:
- build errors: +2/-0
- build warnings: +149/-111
JFYI, when comparing v5.2-rc3[1] to v5.2-rc2[3], the summaries are:
- build errors: +1/-3
- build warnings: +64/-63
Note
On Mon, 3 Jun 2019, syzbot wrote:
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:69bbe8c7 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=15d280f2a0
On Fri, May 31, 2019 at 02:22:27PM -0700, Andy Lutomirski wrote:
>
> > On May 31, 2019, at 2:05 PM, Jiri Kosina wrote:
> >
> >> On Fri, 31 May 2019, Andy Lutomirski wrote:
> >>
> >> The Intel SDM Vol 3 34.10 says:
> >>
> >> If the HLT instruction is restarted, the processor will generate a
>
isp iommu requires wrapper variants of the clocks.
noc variants are always on and using the wrapper variants will activate
{A,H}CLK_ISP{0,1} due to the hierarchy.
Also add the respective power domain.
Refer:
RK3399 TRM v1.4 Fig. 2-4 RK3399 Clock Architecture Diagram
RK3399 TRM v1.4 Fig. 8-1
Hi Gregory,
On Mon, 03 Jun 2019 16:11:51 +0200 Gregory CLEMENT
wrote:
>
> But now it should be available.
Looks good now, thanks.
--
Cheers,
Stephen Rothwell
pgpOpQhgn06Ru.pgp
Description: OpenPGP digital signature
On 5/31/19 7:31 PM, Sean Christopherson wrote:
enclave_load() is roughly analogous to the existing file_mprotect().
Due to the nature of SGX and its Enclave Page Cache (EPC), all enclave
VMAs are backed by a single file, i.e. /dev/sgx/enclave, that must be
MAP_SHARED. Furthermore, all enclaves
On Mon, Jun 03, 2019 at 10:01:28AM +0200, Peter Zijlstra wrote:
> On Sat, Jun 01, 2019 at 06:27:33PM -0400, Joel Fernandes (Google) wrote:
> > +#define list_for_each_entry_rcu(pos, head, member, cond...)
> > \
> > + if (COUNT_VARGS(cond) != 0) {
On Mon, 3 Jun 2019 10:11:20 -0400
Kamal Dasu wrote:
> Boris,
>
> On Sat, Jun 1, 2019 at 3:57 AM Boris Brezillon
> wrote:
> >
> > On Thu, 30 May 2019 17:20:35 -0400
> > Kamal Dasu wrote:
> >
> > > Refactored NAND ECC and CMD address configuration code to use inline
> > > functions.
> >
> >
Clean up asym packing to follow the default load balance behavior:
- classify the group by creating a group_asym_capacity field.
- calculate the imbalance in calculate_imbalance() instead of bypassing it.
We don't need to test twice same conditions anymore to detect asym packing
and we
Hi,
On 03-06-19 15:55, Benjamin Tissoires wrote:
On Mon, Jun 3, 2019 at 11:51 AM Hans de Goede wrote:
Hi Again,
On 03-06-19 11:11, Hans de Goede wrote:
not sure about the rest of logitech issues yet) next week.
The main problem seems to be the request_module patches. Although I also
Hi,
On Mon, Jun 3, 2019 at 3:02 PM Uladzislau Rezki wrote:
>
> Hello, Krzysztof.
>
> On Mon, Jun 03, 2019 at 11:07:46AM +0200, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > On recent next I see bugs during boot (after bringing up user-space or
> > during reboot):
> > kernel BUG at
Hi Stephen,
> Hi all,
>
> Tyring to fetch the mvebu tree
> (git://git.infradead.org/linux-mvebu.git#for-next) for the past several
> days produces this error message:
>
> fatal: Couldn't find remote ref refs/heads/for-next
Sorry for this, the main reason was that I didn't create a for-next
Boris,
On Sat, Jun 1, 2019 at 3:57 AM Boris Brezillon
wrote:
>
> On Thu, 30 May 2019 17:20:35 -0400
> Kamal Dasu wrote:
>
> > Refactored NAND ECC and CMD address configuration code to use inline
> > functions.
>
> I'd expect the compiler to be smart enough to decide when inlining is
>
Clean up asym packing to follow the default load balance behavior:
- classify the group by creating a group_asym_capacity field.
- calculate the imbalance in calculate_imbalance() instead of bypassing it.
We don't need to test twice same conditions anymore to detect asym packing
and we
On Mon, 3 Jun 2019 at 15:59, Uladzislau Rezki wrote:
>
> Hello, Krzysztof.
>
> On Mon, Jun 03, 2019 at 11:07:46AM +0200, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > On recent next I see bugs during boot (after bringing up user-space or
> > during reboot):
> > kernel BUG at ../mm/vmalloc.c:470!
> >
On Mon, 3 Jun 2019 08:04:09 +, Rasmus Villemoes
wrote:
> mv88e6xxx_g1_stats_wait has no users outside global1.c, so make it
> static.
>
> Signed-off-by: Rasmus Villemoes
Reviewed-by: Vivien Didelot
Hi all,
In commit
3ddc3f3057ff ("phy: renesas: rcar-gen2: Fix memory leak at error paths")
Fixes tag
Fixes: 1233f59f745 ("phy: Renesas R-Car Gen2 PHY driver")
has these problem(s):
- SHA1 should be at least 12 digits long
Can be fixed by setting core.abbrev to 12 (or more) or (for
These changes + the stateless decoder v4 patch are now available here:
https://hverkuil.home.xs4all.nl/codec-api/uapi/v4l/dev-mem2mem.html
Easier to read than a patch :-)
Regards,
Hans
On 6/3/19 1:28 PM, Hans Verkuil wrote:
> Since Thomasz was very busy with other things, I've taken
Hello, Krzysztof.
On Mon, Jun 03, 2019 at 11:07:46AM +0200, Krzysztof Kozlowski wrote:
> Hi,
>
> On recent next I see bugs during boot (after bringing up user-space or
> during reboot):
> kernel BUG at ../mm/vmalloc.c:470!
> On all my boards. On QEMU I see something similar, although the
>
Hi Linus,
The following changes since commit a188339ca5a396acc588e5851ed7e19f66b0ebd9:
Linux 5.2-rc1 (2019-05-19 15:47:09 -0700)
are available in the Git repository at:
ssh://g...@gitolite.kernel.org/pub/scm/linux/kernel/git/greentime/linux.git
tags/nds32-for-linux-5.2-rc3
for you to
On Mon, Jun 3, 2019 at 11:51 AM Hans de Goede wrote:
>
> Hi Again,
>
> On 03-06-19 11:11, Hans de Goede wrote:
>
>
> >> not sure about the rest of logitech issues yet) next week.
> >
> > The main problem seems to be the request_module patches. Although I also
Can't we use
Sehr geehrte Damen und Herren,
nach unserem Besuch Ihrer Homepage möchten wir Ihnen ein Angebot von Produkten
vorstellen, das Ihnen ermöglichen wird, den Verkauf Ihrer Produkte sowie
Dienstleistungen deutlich zu erhöhen.
Die Datenbanken der Firmen sind in für Sie interessante und relevante
+ Adrian
On Thu, 30 May 2019 at 11:20, Takao Orito wrote:
>
> SD Host controller on Milbeaut consists of two controller parts.
> One is core controller F_SDH30, this is similar to sdhci-fujitsu
> controller.
> Another is bridge controller.
> This bridge controller is not compatible with
On Fri, 31 May 2019 at 13:32, Colin King wrote:
>
> From: Colin Ian King
>
> The calculation of slots results in a value in the range 1..8
> and so slots can never be zero. The check for slots == 0 is
> always going to be false, hence it is redundant and can be
> removed.
>
>
On Tue, 28 May 2019 at 11:59, Faiz Abbas wrote:
>
> The following patches fix issues with phy configurations for
> sdhci_am654 driver.
>
> v3:
> Changed order of patches so that the first one can be applied easily to
> stable tree.
>
> v2:
> 1. Split patch 1 into 2 separate patches.
> 2. Improved
On Wed, 15 May 2019 at 16:39, Wang Hai wrote:
>
> If bus_register fails. On its error handling path, it has cleaned up
> what it has done. There is no need to call bus_unregister again.
> Otherwise, if bus_unregister is called, issues such as null-ptr-deref
> will arise.
>
> Syzkaller report
Commit-ID: fff9b6c7d26943a8eb32b58364b7ec6b9369746a
Gitweb: https://git.kernel.org/tip/fff9b6c7d26943a8eb32b58364b7ec6b9369746a
Author: Peter Zijlstra
AuthorDate: Fri, 24 May 2019 13:52:31 +0200
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
Commit-ID: 6a6a9d5fb9f26d2c2127497f3a42adbeb5ccc2a4
Gitweb: https://git.kernel.org/tip/6a6a9d5fb9f26d2c2127497f3a42adbeb5ccc2a4
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:50 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
locking/atomic, s390/pci:
Commit-ID: 2af7a0f91c3a645ec9f1cd68e41472021746db35
Gitweb: https://git.kernel.org/tip/2af7a0f91c3a645ec9f1cd68e41472021746db35
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:49 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
locking/atomic, crypto/nx:
Commit-ID: 3724921396dd1a07c93e3516b8d7c9ff570d17a9
Gitweb: https://git.kernel.org/tip/3724921396dd1a07c93e3516b8d7c9ff570d17a9
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:48 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
locking/atomic: Use s64
Commit-ID: 79c53a83d7a31a5b5c7bafce4f0723bebf26836a
Gitweb: https://git.kernel.org/tip/79c53a83d7a31a5b5c7bafce4f0723bebf26836a
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:47 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:57 +0200
locking/atomic, x86: Use
Commit-ID: 04e8851af767153c0878cc79ce30c0d8806eec43
Gitweb: https://git.kernel.org/tip/04e8851af767153c0878cc79ce30c0d8806eec43
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:46 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, sparc: Use
On Mon, 2019-06-03 at 11:25 +0200, Roberto Sassu wrote:
> On 5/30/2019 2:00 PM, Mimi Zohar wrote:
> > On Wed, 2019-05-29 at 15:30 +0200, Roberto Sassu wrote:
> > > Currently, ima_appraise_measurement() ignores the EVM status when
> > > evm_verifyxattr() returns INTEGRITY_UNKNOWN. If a file has a
>
Commit-ID: 0ca94800762e8a2f7037c9b02ba74aff8016dd82
Gitweb: https://git.kernel.org/tip/0ca94800762e8a2f7037c9b02ba74aff8016dd82
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:45 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, s390: Use
From: Kan Liang
Add new Icelake desktop CPUID for RAPL, CSTATE and UNCORE.
Signed-off-by: Kan Liang
---
arch/x86/events/intel/cstate.c | 1 +
arch/x86/events/intel/rapl.c | 1 +
arch/x86/events/intel/uncore.c | 1 +
3 files changed, 3 insertions(+)
diff --git
Commit-ID: 0754211847d7a228f1c34a49fd122979dfd19a1a
Gitweb: https://git.kernel.org/tip/0754211847d7a228f1c34a49fd122979dfd19a1a
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:44 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, riscv: Use
From: Kan Liang
Add new model number for Icelake desktop and server to perf.
The data source encoding for Icelake server is the same as Skylake
server.
Signed-off-by: Kan Liang
---
arch/x86/events/intel/core.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
From: Kan Liang
Add the CPUID model number of Icelake (ICL) desktop and server
processors to the Intel family list.
Signed-off-by: Kan Liang
Signed-off-by: Qiuxu Zhuo
---
arch/x86/include/asm/intel-family.h | 3 +++
1 file changed, 3 insertions(+)
diff --git
Commit-ID: 33e42ef571979fe6601ac838d338eb599d842a6d
Gitweb: https://git.kernel.org/tip/33e42ef571979fe6601ac838d338eb599d842a6d
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:43 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, riscv: Fix
Commit-ID: 8cd8de59748ba71b476d1b7101f9ecaccd5cb8c2
Gitweb: https://git.kernel.org/tip/8cd8de59748ba71b476d1b7101f9ecaccd5cb8c2
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:42 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, powerpc:
Hi Hans,
On 03.06.2019 14:14, Hans Verkuil wrote:
> Hi Maciej,
>
> Thank you for the patch, but I posted a fix for this earlier already:
>
> https://patchwork.linuxtv.org/patch/56441/
>
> I'll drop this patch in favor of the one above. Apologies for not
> CC-ing you on my patch, I should have
Commit-ID: d184cf1a449ca4cb0d86f3dd82c3337c645ea6c0
Gitweb: https://git.kernel.org/tip/d184cf1a449ca4cb0d86f3dd82c3337c645ea6c0
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:41 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, mips: Use
Commit-ID: d84e28d250150adc6526dcce4ca089e2b57430f3
Gitweb: https://git.kernel.org/tip/d84e28d250150adc6526dcce4ca089e2b57430f3
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:40 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, ia64: Use
On 6/3/19 1:44 PM, Mark Rutland wrote:
On Mon, Jun 03, 2019 at 10:38:48AM +0200, Peter Zijlstra wrote:
On Sat, Jun 01, 2019 at 06:12:53PM -0700, Paul E. McKenney wrote:
Scheduling-clock interrupts can arrive late in the CPU-offline process,
after idle entry and the subsequent call to
Commit-ID: 16f18688af7ea6c65f6daa3efb4661415e2e6041
Gitweb: https://git.kernel.org/tip/16f18688af7ea6c65f6daa3efb4661415e2e6041
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:39 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, arm64: Use
Commit-ID: ef4cdc09260e2b0576423ca708e245e7549aa8e0
Gitweb: https://git.kernel.org/tip/ef4cdc09260e2b0576423ca708e245e7549aa8e0
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:38 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, arm: Use
Commit-ID: 16fbad086976574b99ea7019c0504d0194e95dc3
Gitweb: https://git.kernel.org/tip/16fbad086976574b99ea7019c0504d0194e95dc3
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:37 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, arc: Use
From: Colin Ian King
There is a spelling mistake in the help information, fix this.
Signed-off-by: Colin Ian King
---
samples/bpf/hbm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/samples/bpf/hbm.c b/samples/bpf/hbm.c
index 480b7ad6a1f2..bdfce592207a 100644
---
Commit-ID: 0203fdc160a8c8d8651a3b79aa453ec36cfbd867
Gitweb: https://git.kernel.org/tip/0203fdc160a8c8d8651a3b79aa453ec36cfbd867
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:36 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, alpha: Use
Commit-ID: 982164d62a4b2097c0db28ae7c31fc905af26bb8
Gitweb: https://git.kernel.org/tip/982164d62a4b2097c0db28ae7c31fc905af26bb8
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:34 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic, s390/pci:
Commit-ID: 9255813d5841e158f033e0d83d455bffdae009a4
Gitweb: https://git.kernel.org/tip/9255813d5841e158f033e0d83d455bffdae009a4
Author: Mark Rutland
AuthorDate: Wed, 22 May 2019 14:22:35 +0100
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/atomic: Use s64
On Mon, 20 May 2019 at 12:12, Baolin Wang wrote:
>
> For some Spreadtrum platforms like SC9860 platform, we should enable another
> gate clock '2x_enable' to make the SD host controller work well. Thus add
> documentation for this optional clock.
>
> Signed-off-by: Baolin Wang
> ---
>
Commit-ID: d9349850e188b8b59e5322fda17ff389a1c0cd7d
Gitweb: https://git.kernel.org/tip/d9349850e188b8b59e5322fda17ff389a1c0cd7d
Author: Imre Deak
AuthorDate: Fri, 24 May 2019 23:15:09 +0300
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/lockdep: Fix merging
Commit-ID: 24811637dbfd07c69da7e9db586d35d17e6afca3
Gitweb: https://git.kernel.org/tip/24811637dbfd07c69da7e9db586d35d17e6afca3
Author: Peter Zijlstra
AuthorDate: Mon, 27 May 2019 10:23:26 +0200
Committer: Ingo Molnar
CommitDate: Mon, 3 Jun 2019 12:32:56 +0200
locking/lock_events: Use
601 - 700 of 1209 matches
Mail list logo
