Quoting Tudor Ambarus (2021-02-03 07:43:32)
> These are all "early clocks" that require initialization just at
> of_clk_init() time. Use CLK_OF_DECLARE() to declare them.
>
> This also fixes a problem that was spotted when fw_devlink was
> set to 'on' by default: the boards failed to boot. The rea
On Tue, Feb 09, 2021 at 09:13:43PM +0100, Uladzislau Rezki wrote:
> On Thu, Feb 04, 2021 at 01:46:48PM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 29, 2021 at 09:05:04PM +0100, Uladzislau Rezki (Sony) wrote:
> > > To stress and test a single argument of kfree_rcu() call, we
> > > should to have
This patch fixes a warning, of the line ending with a '(',
generated by checkpatch.pl.
Signed-off-by: Mukul Mehar
---
Changes since v1:
- Fixed indentation.
---
drivers/staging/most/sound/sound.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/most/soun
On Tue, Feb 9, 2021 at 4:22 PM Roman Gushchin wrote:
>
> On Tue, Feb 09, 2021 at 09:46:40AM -0800, Yang Shi wrote:
> > The shrinker_info is dereferenced in a couple of places via
> > rcu_dereference_protected
> > with different calling conventions, for example, using mem_cgroup_nodeinfo
> > help
As it turns out, vendor HDMI PHY driver for H6 has a pretty big table
of predefined values for various pixel clocks. However, most of them are
not useful/tested because they come from reference driver code. Vendor
PHY driver is concerned with only few of those, namely 27 MHz, 74.25
MHz, 148.5 MHz,
On Tue, Feb 09, 2021 at 09:46:42AM -0800, Yang Shi wrote:
> Currently the number of deferred objects are per shrinker, but some slabs,
> for example,
> vfs inode/dentry cache are per memcg, this would result in poor isolation
> among memcgs.
>
> The deferred objects typically are generated by __
On Tue, Feb 9, 2021 at 4:39 PM Roman Gushchin wrote:
>
> On Tue, Feb 09, 2021 at 09:46:41AM -0800, Yang Shi wrote:
> > Currently registered shrinker is indicated by non-NULL
> > shrinker->nr_deferred.
> > This approach is fine with nr_deferred at the shrinker level, but the
> > following
> > pat
On Tue, 2021-02-09 at 19:44 +, Song Liu wrote:
> > On Feb 9, 2021, at 10:59 AM, Joe Perches wrote:
> > On Tue, 2021-02-09 at 10:33 -0800, Song Liu wrote:
> > > BPF programs explicitly initialise global variables to 0 to make sure
> > > clang (v10 or older) do not put the variables in the commo
On Mon, Feb 08, 2021 at 04:00:47PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.19.175 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 kno
On Tue, Feb 9, 2021 at 1:43 AM Mike Rapoport wrote:
>
> This a small cleanup in memblock for 5.12 merge window.
If it's going to make Andrew's patches easier to apply during the 5.12
timeframe, I'm happy to pull this early.
Yes/No?
Linus
From: Peter Shier
Fixes: 678e90a349a4 ("KVM: selftests: Test IPI to halted vCPU in xAPIC while
backing page moves")
Cc: Andrew Jones
Cc: Jim Mattson
Signed-off-by: Peter Shier
Signed-off-by: Sean Christopherson
---
Delta patch taken verbatim from Peter's original submission. Applying the
o
On Tue, Feb 09, 2021 at 09:46:45AM -0800, Yang Shi wrote:
> Now shrinker's nr_deferred is per memcg for memcg aware shrinkers, add to
> parent's
> corresponding nr_deferred when memcg offline.
>
> Acked-by: Vlastimil Babka
> Acked-by: Kirill Tkhai
> Signed-off-by: Yang Shi
Acked-by: Roman Gus
On Tue, 09 Feb 2021 16:58:12 -0600
Tom Zanussi wrote:
> Did you apply '[PATCH v7 5/6] selftests/ftrace: Update synthetic event
> syntax errors' before you ran the test? It actually removes the test
> that failed. Here's what I get with all patches applied:
I thought I did, but I forgot that I
On Tue, Feb 09, 2021 at 09:46:44AM -0800, Yang Shi wrote:
> Now nr_deferred is available on per memcg level for memcg aware shrinkers, so
> don't need
> allocate shrinker->nr_deferred for such shrinkers anymore.
>
> The prealloc_memcg_shrinker() would return -ENOSYS if !CONFIG_MEMCG or memcg
> i
On Mon, Feb 08, 2021 at 04:00:32PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.4.97 release.
> There are 65 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.
Hello,
syzbot found the following issue on:
HEAD commit:dd86e7fa Merge tag 'pci-v5.11-fixes-2' of git://git.kernel..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=105930c4d0
kernel config: https://syzkaller.appspot.com/x/.config?x=266a5362c89c8127
das
On Mon, Feb 08, 2021 at 01:55:54PM -0500, Jonathan Marek wrote:
> The cleanup patch broke a6xx_gmu_clear_oob, fix it by adding the missing
> bitshift operation.
>
> Fixes: 555c50a4a19b ("drm/msm: Clean up GMU OOB set/clear handling")
> Signed-off-by: Jonathan Marek
Thanks. I feel silly that I m
On Tue, Feb 9, 2021 at 5:10 PM Roman Gushchin wrote:
>
> On Tue, Feb 09, 2021 at 09:46:42AM -0800, Yang Shi wrote:
> > Currently the number of deferred objects are per shrinker, but some slabs,
> > for example,
> > vfs inode/dentry cache are per memcg, this would result in poor isolation
> > amo
On Tue, Feb 09, 2021 at 09:46:43AM -0800, Yang Shi wrote:
> Use per memcg's nr_deferred for memcg aware shrinkers. The shrinker's
> nr_deferred
> will be used in the following cases:
> 1. Non memcg aware shrinkers
> 2. !CONFIG_MEMCG
> 3. memcg is disabled by boot parameter
>
> Signed
On Mon, Feb 08, 2021 at 03:59:47PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 5.10.15 release.
> There are 120 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 kno
On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote:
> On Tue, 09 Feb 2021 15:16:45 -0800
> nnet wrote:
>
> > I've two of these and I've just swapped them (and re-pasted the heat sinks).
> >
> > The second one ran under load for awhile and now has frozen as well.
> >
> > Under a moderate load `w
On Tue, Feb 09, 2021 at 05:07:07PM -0800, Yang Shi wrote:
> On Tue, Feb 9, 2021 at 4:22 PM Roman Gushchin wrote:
> >
> > On Tue, Feb 09, 2021 at 09:46:40AM -0800, Yang Shi wrote:
> > > The shrinker_info is dereferenced in a couple of places via
> > > rcu_dereference_protected
> > > with different
These are copies of existing tests, with just 31 --> N. This ensures
the recently added "N" alias transparently works in any normally
numeric fields of a region specification.
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
Signed-off-by: Paul Gortmaker
---
lib/test_bitmap.c | 10 +++
As of [1], we no longer want EXT4_KUNIT_TESTS and others to `select`
their deps. This means it can get harder to get all the right things
selected as we gain more tests w/ more deps over time.
This patch (and [2]) proposes we store kunitconfig fragments in-tree to
represent sets of tests. (N.B. ri
It makes sense to do all the checks in check_region() and not 1/2
in check_region and 1/2 in set_region.
Since set_region is called immediately after check_region, the net
effect on runtime is zero, but it gets rid of an if (...) return...
Cc: Yury Norov
Cc: Rasmus Villemoes
Cc: Andy Shevchenko
On Tue, Feb 09, 2021 at 05:12:51PM -0800, Yang Shi wrote:
> On Tue, Feb 9, 2021 at 4:39 PM Roman Gushchin wrote:
> >
> > On Tue, Feb 09, 2021 at 09:46:41AM -0800, Yang Shi wrote:
> > > Currently registered shrinker is indicated by non-NULL
> > > shrinker->nr_deferred.
> > > This approach is fine
The basic objective here was to add support for "nohz_full=8-N" and/or
"rcu_nocbs="4-N" -- essentially introduce "N" as a portable reference
to the last core, evaluated at boot for anything using a CPU list.
The thinking behind this, is that people carve off a few early CPUs to
support housekeepin
While this is done for all bitmaps, the original use case in mind was
for CPU masks and cpulist_parse() as described below.
It seems that a common configuration is to use the 1st couple cores for
housekeeping tasks. This tends to leave the remaining ones to form a
pool of similarly configured cor
On Tue, Feb 09, 2021 at 05:25:16PM -0800, Yang Shi wrote:
> On Tue, Feb 9, 2021 at 5:10 PM Roman Gushchin wrote:
> >
> > On Tue, Feb 09, 2021 at 09:46:42AM -0800, Yang Shi wrote:
> > > Currently the number of deferred objects are per shrinker, but some
> > > slabs, for example,
> > > vfs inode/de
l-dvb tree from next-20210209 for today.
--
Cheers,
Stephen Rothwell
pgpMGzEs9n9ZT.pgp
Description: OpenPGP digital signature
> @@ -1552,6 +1552,7 @@ static int marvell_read_status_page(struct phy_device
> *phydev, int page)
> phydev->asym_pause = 0;
> phydev->speed = SPEED_UNKNOWN;
> phydev->duplex = DUPLEX_UNKNOWN;
> + phydev->port = fiber ? PORT_FIBRE : PORT_TP;
>
> if (phydev->autoneg ==
On Tue, Feb 9, 2021 at 5:27 PM Roman Gushchin wrote:
>
> On Tue, Feb 09, 2021 at 09:46:43AM -0800, Yang Shi wrote:
> > Use per memcg's nr_deferred for memcg aware shrinkers. The shrinker's
> > nr_deferred
> > will be used in the following cases:
> > 1. Non memcg aware shrinkers
> > 2. !C
On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
> On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote:
> > On Tue, 09 Feb 2021 15:16:45 -0800
> > nnet wrote:
> >
> > > I've two of these and I've just swapped them (and re-pasted the heat
> > > sinks).
> > >
> > > The second one ran under load for aw
On Tue, Feb 09, 2021 at 05:38:52PM +0100, Michael Walle wrote:
> At the moment, PORT_MII is reported in the ethtool ops. This is odd
> because it is an interface between the MAC and the PHY and no external
> port. Some network card drivers will overwrite the port to twisted pair
> or fiber, though.
On Tue, Feb 09, 2021 at 05:40:43PM +0100, Michael Walle wrote:
> Simpify the initializations of the structures. There is no functional
> change.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
On Tue, Feb 9, 2021 at 5:34 PM Roman Gushchin wrote:
>
> On Tue, Feb 09, 2021 at 05:12:51PM -0800, Yang Shi wrote:
> > On Tue, Feb 9, 2021 at 4:39 PM Roman Gushchin wrote:
> > >
> > > On Tue, Feb 09, 2021 at 09:46:41AM -0800, Yang Shi wrote:
> > > > Currently registered shrinker is indicated by n
On Tue, Feb 09, 2021 at 05:40:44PM +0100, Michael Walle wrote:
> According to the datasheet of the IP101A/G there is no revision field
> and MII_PHYSID2 always reads as 0x0c54. Use PHY_ID_MATCH_EXACT() then.
>
> Signed-off-by: Michael Walle
Lets hope the datasheet is correct and up to date, beca
Excerpts from Christophe Leroy's message of February 10, 2021 2:13 am:
>
>
> Le 09/02/2021 à 02:55, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am:
>>> When r3 is not modified, reload it from regs->orig_r3 to free
>>> volatile registers. This avo
On Tue, Feb 09, 2021 at 05:40:45PM +0100, Michael Walle wrote:
> Don't sometimes use the address operator and sometimes not. Drop it and
> make the code look uniform.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
Excerpts from Christophe Leroy's message of February 10, 2021 12:31 am:
>
>
> Le 09/02/2021 à 03:02, Nicholas Piggin a écrit :
>> Excerpts from Christophe Leroy's message of February 9, 2021 1:10 am:
>>> For book3s/64, FULL_REGS() is 'true' at all time, so the test voids.
>>> For others, non vola
On Tue, Feb 9, 2021 at 5:40 PM Roman Gushchin wrote:
>
> On Tue, Feb 09, 2021 at 05:25:16PM -0800, Yang Shi wrote:
> > On Tue, Feb 9, 2021 at 5:10 PM Roman Gushchin wrote:
> > >
> > > On Tue, Feb 09, 2021 at 09:46:42AM -0800, Yang Shi wrote:
> > > > Currently the number of deferred objects are pe
Quoting Pali Rohár (2021-01-14 04:40:25)
> From: Marek Behún
>
> Remove the .set_parent method in clk_pm_cpu_ops.
>
> This method was supposed to be needed by the armada-37xx-cpufreq driver,
> but was never actually called due to wrong assumptions in the cpufreq
> driver. After this was fixed in
Quoting Pali Rohár (2021-01-14 04:40:27)
> It was observed that the workaround introduced by commit 61c40f35f5cd
> ("clk: mvebu: armada-37xx-periph: Fix switching CPU rate from 300Mhz to
> 1.2GHz") when base CPU frequency is 1.2 GHz is also required when base
> CPU frequency is 1 GHz. Otherwise swi
Quoting Pali Rohár (2021-01-14 04:40:28)
> When CPU frequency is at 250 MHz and set_rate() is called with 500 MHz (L1)
> quickly followed by a call with 1 GHz (L0), the CPU does not necessarily
> stay in L1 for at least 20ms as is required by Marvell errata.
>
> This situation happens frequently w
Excerpts from Christophe Leroy's message of February 10, 2021 3:03 am:
>
>
> Le 09/02/2021 à 15:31, David Laight a écrit :
>> From: Segher Boessenkool
>>> Sent: 09 February 2021 13:51
>>>
>>> On Tue, Feb 09, 2021 at 12:36:20PM +1000, Nicholas Piggin wrote:
What if you did this?
>>>
+sta
On Tue, Feb 09, 2021 at 05:40:46PM +0100, Michael Walle wrote:
> The PHY core already resets the PHY before .config_init() if a
> .soft_reset() op is registered. Drop the open-coded ip1xx_reset().
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
On Tue, Feb 09, 2021 at 05:40:48PM +0100, Michael Walle wrote:
> This bit is reserved as 'always-write-1'. While this is not a particular
> error, because we are only setting it, guard it by checking the model to
> prevent errors in the future.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andre
On a Sapphire Rapids server, it failed to inject correctable errors
to the RCiEP device e8:02.0 which was associated with the RCEC device
e8:00.4. See the following error log before applying the patch:
aer-inject -s e8:02.0 examples/correctable
Error: Failed to write, No such device
This was beca
On Tue, Feb 09, 2021 at 05:40:49PM +0100, Michael Walle wrote:
> Registers >= 16 are paged. Be sure to set the page. It seems this was
> working for now, because the default is correct for the registers used
> in the driver at the moment. But this will also assume, nobody will
> change the page sel
On Tue, Feb 9, 2021, at 5:51 PM, nnet wrote:
> On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
> > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote:
> > > On Tue, 09 Feb 2021 15:16:45 -0800
> > > nnet wrote:
> > >
> > > > I've two of these and I've just swapped them (and re-pasted the heat
> >
On Tue, Feb 09, 2021 at 05:40:50PM +0100, Michael Walle wrote:
> The IP101G provides three counters: RX packets, CRC errors and symbol
> errors. The error counters can be configured to clear automatically on
> read. Unfortunately, this isn't true for the RX packet counter. Because
> of this and bec
On Tue, Feb 09, 2021 at 05:40:51PM +0100, Michael Walle wrote:
> Implement the operations to set desired mode and retrieve the current
> mode.
>
> This feature was tested with an IP101G.
>
> Signed-off-by: Michael Walle
Reviewed-by: Andrew Lunn
Andrew
Hi:
On 2021/2/10 2:56, Mike Kravetz wrote:
> On 2/8/21 7:27 PM, Miaohe Lin wrote:
>> On 2021/2/9 3:52, Mike Kravetz wrote:
>>> On 1/23/21 1:31 AM, Miaohe Lin wrote:
The current implementation of hugetlb_cgroup for shared mappings could have
different behavior. Consider the following two s
On Tue, 09 Feb 2021 17:51:53 -0800
nnet wrote:
> On Tue, Feb 9, 2021, at 5:31 PM, nnet wrote:
> > On Tue, Feb 9, 2021, at 3:26 PM, Marek Behún wrote:
> > > On Tue, 09 Feb 2021 15:16:45 -0800
> > > nnet wrote:
> > >
> > > > I've two of these and I've just swapped them (and re-pasted the heat
On Tue, 2021-02-09 at 13:19 -0800, Song Liu wrote:
> BPF programs explicitly initialise global variables to 0 to make sure
> clang (v10 or older) do not put the variables in the common section.
Acked-by: Joe Perches
So the patch is OK now, but I have a question about the concept:
Do you mean th
Hi all,
Today's linux-next merge of the rdma tree got a conflict in:
drivers/infiniband/sw/rxe/rxe_net.c
between commit:
f1b0a8ea9f12 ("Revert "RDMA/rxe: Remove VLAN code leftovers from RXE"")
from Linus' tree and commit:
899aba891cab ("RDMA/rxe: Fix FIXME in rxe_udp_encap_recv()")
fro
On (21/02/09 10:19), Petr Mladek wrote:
> On Sat 2021-02-06 13:41:24, Muchun Song wrote:
[..]
> What about the following commit message? It uses imperative language
> and explains that the patch just prevents the deadlock. It removes
> some details. The diagram is better than many words.
>
>
>
On (21/02/09 09:39), Petr Mladek wrote:
> > > So then this never re-inits the safe_read_lock?
>
> Yes, but it will also not cause the deadlock.
Right.
> I prefer this approach. It is straightforward because it handles
> read_lock the same way as logbuf_lock.
I'm fine with that approach, but thi
Quoting Daniel Palmer (2020-12-21 00:51:56)
> Hi Stephen,
>
> On Mon, 21 Dec 2020 at 03:44, Stephen Boyd wrote:
> >
> > Quoting Daniel Palmer (2020-12-19 22:35:41)
> > > Hi Stephen,
> > >
> > > On Sun, 20 Dec 2020 at 12:39, Stephen Boyd wrote:
> > > > > + clock-output-names:
> > > > > +minI
On 2/8/2021 10:37 PM, Jason Wang wrote:
On 2021/2/9 下午2:12, Eli Cohen wrote:
On Tue, Feb 09, 2021 at 11:20:14AM +0800, Jason Wang wrote:
On 2021/2/8 下午6:04, Eli Cohen wrote:
On Mon, Feb 08, 2021 at 05:04:27PM +0800, Jason Wang wrote:
On 2021/2/8 下午2:37, Eli Cohen wrote:
On Mon, Feb 08, 2
On Tue, Feb 09, 2021 at 05:32:06PM -0800, Daniel Latypov wrote:
>
> After [2]:
> $ ./tools/testing/kunit.py run --kunitconfig=fs/ext4/.kunitconfig
Any chance that in the future this might become:
$ ./tools/testing/kunit.py run --kunitconfig=fs/ext4
Or better yet, syntactic sugar like:
$ ./to
> -Original Message-
> From: Leo Yan
> Sent: Tuesday, February 9, 2021 8:17 PM
> To: Jianlin Lv
> Cc: john.ga...@huawei.com; w...@kernel.org; mathieu.poir...@linaro.org;
> pet...@infradead.org; mi...@redhat.com; a...@kernel.org; Mark Rutland
> ; alexander.shish...@linux.intel.com;
> jo.
The recent rework of probe_kernel_address() and its conversion to
get_kernel_nofault() inadvertently broke is_prefetch(). Before this change,
probe_kernel_address() was used as a sloppy "read user or kernel memory"
helper, but it doesn't do that any more. The new get_kernel_nofault()
reads *kernel
This series is a whole bunch of page fault cleanups, plus a couple
of OOPS diagnostic improvements. The overall goals are to clean up
handling of the faulting CPL, the USER bit in the error_code, and
the log messages generated by #PF OOPSes.
This series can also be seen as CET preparation. CET i
mm_fault_error() is logically just the end of do_user_addr_fault().
Combine the functions. This makes the code easier to read.
Most of the churn here is from renaming hw_error_code to error_code in
do_user_addr_fault().
This makes no difference at all to the generated code (objdump -dr) as
compa
bad_area() and its relatives are called from many places in fault.c, and
exactly one of them wants the F00F workaround.
__bad_area_nosemaphore() no longer contains any kernel fault code, which
prepares for further cleanups.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
Right now we treat the case of the kernel trying to execute from user
memory more or less just like the kernel getting a page fault on a user
access. In the failure path, we check for erratum #93, try to otherwise
fix up the error, and then oops.
If we manage to jump to the user address space, wi
According to the Revision Guide for AMD Athlon™ 64 and AMD Opteron™
Processors, only early revisions of family 0xF are affected. This will
avoid unnecessarily fetching instruction bytes before sending SIGSEGV to
user programs.
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 13
If fault_signal_pending() returns true, then the core mm has unlocked the
mm for us. Add a comment to help future readers of this code.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --g
In general, page fault errors for WRUSS should be just like get_user(),
etc. Fix three bugs in this area:
There is a comment that says that, if the kernel can't handle a page fault
on a user address due to OOM, the OOM-kill-and-retry logic would be
skipped. The code checked kernel *privilege*, n
Erratum #93 applies to the first generation of AMD K8 CPUs. Skip the
workaround on newer CPUs.
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index cbb1a9754473..3fe2f4800b
efi_recover_from_page_fault() doesn't recover -- it does a special EFI
mini-oops. Rename it to make it clear that it crashes.
While renaming it, I noticed a blatant bug: a page fault oops in a
different thread happening concurrently with an EFI runtime service call
would be misinterpreted as an E
If we get a SMEP violation or a fault that would have been a SMEP
violation if we had SMEP, we shouldn't run fixups. Just OOPS.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arc
Not all callers of no_context() want to run exception fixups.
Separate the OOPS code out from the fixup code in no_context().
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 116 +++-
1 file changed, 62 inserti
A SMAP-violating kernel access is not a recoverable condition. Imagine
kernel code that, outside of a uaccess region, dereferences a pointer to
the user range by accident. If SMAP is on, this will reliably generate
as an intentional user access. This makes it easy for bugs to be
overlooked if co
The name no_context() has never been very clear. It's only called for
faults from kernel mode, so rename it and change the no-longer-useful
user_mode(regs) check to a WARN_ON_ONCE.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 28 ++---
We can drop an indentation level and remove the last
user_mode(regs) == true caller of no_context() by directly OOPSing for
implicit kernel faults from usermode.
Cc: Dave Hansen
Cc: Peter Zijlstra
Signed-off-by: Andy Lutomirski
---
arch/x86/mm/fault.c | 59 -
On 2021-02-10 08:42, Shuah Khan wrote:
ath10k_mac_get_rate_flags_ht() floods dmesg with the following
messages,
when it fails to find a match for mcs=7 and rate=1440.
supported_ht_mcs_rate_nss2:
{7, {1300, 2700, 1444, 3000} }
ath10k_pci :02:00.0: invalid ht params rate 1440 100kbps nss 2
Quoting Rob Herring (2021-02-09 13:13:47)
> On Tue, Feb 02, 2021 at 10:44:33AM -0800, Stephen Boyd wrote:
> > +description: Name for proximity sensor
> > +
> > +required:
> > + - compatible
> > +
> > +unevaluatedProperties: false
> > +additionalProperties: false
>
> Only need one. In this cas
Quoting Stephen Boyd (2021-02-06 19:21:39)
> Quoting Jonathan Cameron (2021-02-06 08:17:11)
> > On Tue, 2 Feb 2021 10:44:34 -0800
> > Stephen Boyd wrote:
> >
> > > +static struct platform_driver cros_ec_mkbp_proximity_driver = {
> > > + .driver = {
> > > + .name = "cros-ec-mkbp-p
Hello Johannes,
在 2021/2/9 下午11:48, Johannes Weiner 写道:
> Hello Chengming,
>
> On Tue, Feb 09, 2021 at 03:10:33PM +0800, Chengming Zhou wrote:
>> When the current task in a cgroup is in_memstall, the corresponding groupc
>> on that cpu is in PSI_MEM_FULL state, so we can exploit that to remove the
This is a different approach to [1] where I tried to add this proximity
sensor logic to the input subsystem. Instead, we'll take the approach of
making a small IIO proximity driver that parses the EC switch bitmap to
find out if the front proximity sensor is detecting something or not.
This allows
Some cros ECs support a front proximity MKBP event via
'EC_MKBP_FRONT_PROXIMITY'. Add this define so it can be used in a
future patch.
Cc: Dmitry Torokhov
Cc: Benson Leung
Cc: Guenter Roeck
Cc: Douglas Anderson
Cc: Gwendal Grignou
Acked-by: Enric Balletbo i Serra
Signed-off-by: Stephen Boyd
Add support for a ChromeOS EC proximity driver that exposes a "front"
proximity sensor via the IIO subsystem. The EC decides when front
proximity is near and sets an MKBP switch 'EC_MKBP_FRONT_PROXIMITY' to
notify the kernel of proximity. Similarly, when proximity detects
something far away it sets
On Tue, Feb 09, 2021 at 10:53:20AM +0100, Michal Simek wrote:
> +static int usb5744_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct device *dev = &client->dev;
> + int ret;
> +
> + /* Trigger gpio reset to the hub. */
> +
Some cros ECs support a front proximity MKBP event via
'EC_MKBP_FRONT_PROXIMITY'. Add a DT binding to document this feature via
a node that is a child of the main cros_ec device node. Devices that
have this ability will describe this in firmware.
Cc: Dmitry Torokhov
Cc: Benson Leung
Cc: Guenter
On 10/02/2021 00:54, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:dd86e7fa Merge tag 'pci-v5.11-fixes-2' of git://git.kernel..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=13e43f90d0
> kernel config: https://syz
On 2/9/21 7:57 PM, Pavel Begunkov wrote:
> On 10/02/2021 00:54, syzbot wrote:
>> Hello,
>>
>> syzbot found the following issue on:
>>
>> HEAD commit:dd86e7fa Merge tag 'pci-v5.11-fixes-2' of git://git.kernel..
>> git tree: upstream
>> console output: https://syzkaller.appspot.com/x/log.tx
On Feb 9, 2021, at 4:22 PM, Theodore Ts'o wrote:
>
> On Wed, Feb 03, 2021 at 11:31:28AM -0500, Theodore Ts'o wrote:
>> On Wed, Feb 03, 2021 at 03:55:06AM -0700, Andreas Dilger wrote:
>>>
>>> It looks like this change will break the dirdata feature, which is similarly
>>> storing a data field bey
The file virtio_mmio.c has defined the function to_virtio_mmio_device,
so use it instead of container_of() to simply code. And remove
superfluous blank lines in this file.
Signed-off-by: Tang Bin
---
drivers/virtio/virtio_mmio.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions
Hi Daniel,
On Wed, Feb 10, 2021 at 4:26 AM Daniel Lezcano
wrote:
>
> On 09/02/2021 17:02, Guo Ren wrote:
> > Hi Daniel,
> >
> > On Sun, Feb 7, 2021 at 5:29 PM Daniel Lezcano
> > wrote:
> >>
> >> On 07/02/2021 04:31, Guo Ren wrote:
> >>> Hi Daniel,
> >>>
> >>> On Thu, Feb 4, 2021 at 4:48 PM Dani
Hi Vincent,
On Tue, Feb 09, 2021 at 07:58:33PM +0100, Vincent Knecht wrote:
> Le mardi 09 février 2021 à 10:13 -0600, Rob Herring a écrit :
> > On Thu, Jan 21, 2021 at 06:43:47PM +0100, Vincent Knecht wrote:
> > > This adds dts bindings for the mstar msg26xx touchscreen.
> > >
> > > Signed-off-by
error=incompatible-pointer-types]
390 | .timedout_job = v3d_generic_job_timedout,
| ^~~~
drivers/gpu/drm/v3d/v3d_sched.c:390:18: note: (near initialization for
'v3d_cache_clean_sched_ops.timedout_job')
Caused by commit
c10983e14e8f ("drm/scheduler: Job timeout handler returns status (v3)")
I have used the drm-misc tree from next-20210209 for today.
--
Cheers,
Stephen Rothwell
pgpgF7aCAHo1q.pgp
Description: OpenPGP digital signature
The function meson_crypto_probe() is only called with an openfirmware
platform device. Therefore there is no need to check that the passed
in device is NULL.
Signed-off-by: Tang Bin
---
drivers/crypto/amlogic/amlogic-gxl-core.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/crypto
gcc version: 11.0.0 20210208 (experimental) (GCC)
Following build error on arm64:
...
In function ‘printf’,
inlined from ‘regs_dump__printf’ at util/session.c:1141:3,
inlined from ‘regs__printf’ at util/session.c:1169:2:
/usr/include/aarch64-linux-gnu/bits/stdio2.h:107:10: \
error:
On 2/2/21 1:57 PM, Ben Gardon wrote:
rwlocks do not currently have any facility to detect contention
like spinlocks do. In order to allow users of rwlocks to better manage
latency, add contention detection for queued rwlocks.
CC: Ingo Molnar
CC: Will Deacon
Acked-by: Peter Zijlstra
Acked-by:
Another pile of networing fixes:
1) ath9k build error fix from Arnd Bergmann
2) dma memory leak fix in mediatec driver from Lorenzo Bianconi.
3) bpf int3 kprobe fix from Alexei Starovoitov.
4) bpf stackmap integer overflow fix from Bui Quang Minh.
5) Add usb device ids for Cinterion MV31 to
On Wed, Feb 10, 2021 at 12:50 AM Namjae Jeon wrote:
>
> Hi folk,
>
> We have released exfatprogs 1.1.0 version. In this release, exfatlabel
> has been added to print or re-write volume label and volume serial value.
> Also, A new dump.exfat util has been added to display statistics from
> a given
On Mon, Feb 08, 2021 at 02:45:51PM +0100, Emil Renner Berthing wrote:
> This converts the driver to use the new tasklet API introduced in
> commit 12cc923f1ccc ("tasklet: Introduce new initialization API")
>
> Signed-off-by: Emil Renner Berthing
Acked-by: Michał Mirosław
> ---
> drivers/mmc/h
VIDEO_ATOMISP depends on VIDEO_V4L2_SUBDEV_API, if VIDEO_V4L2_SUBDEV_API
is not selected, it will cause compilation error
drivers/staging/media/atomisp/pci/atomisp_cmd.c:6079:42: error:
‘struct v4l2_subdev_fh’ has no member named ‘pad’ atomisp_subdev_set_ffmt
(&asd->subdev, fh.pad, V4L2_SUBDEV_F
101 - 200 of 1488 matches
Mail list logo
