On 11/10/20 11:50 AM, Matthew Wilcox wrote:
> On Tue, Nov 10, 2020 at 11:31:31AM -0800, Mike Kravetz wrote:
>> On 11/9/20 5:52 AM, Oscar Salvador wrote:
>>> On Sun, Nov 08, 2020 at 10:10:55PM +0800, Muchun Song wrote:
>
> I don't like config options. I like boot options even less. I don't
> know
On Mon, Nov 09, 2020 at 06:14:33PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 09, 2020 at 08:24:52AM -0800, Paul E. McKenney wrote:
> > On Mon, Nov 09, 2020 at 01:23:17PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 05, 2020 at 03:05:08PM -0800, paul...@kernel.org wrote:
> > > > From: "Joel Ferna
Peter Zijlstra writes:
> On Thu, Oct 29, 2020 at 02:18:45PM -0400, Daniel Jordan wrote:
>> rebuild_sched_domains_locked() prevented the race during the cgroup2
>> cpuset series up until the Fixes commit changed its check. Make the
>> check more robust so that it can detect an offline CPU in any e
On 10/11/20 18:52, Luck, Tony wrote:
Look at what it is trying to do ... change the behavior of the platform w.r.t.
logging
of memory errors. How does that make any sense for a guest ...
Logging of memory errors certainly makes sense for a guest, KVM already
does MCE forwarding as you probab
On Tue, Nov 10, 2020 at 9:11 PM 'Nick Desaulniers' via Clang Built
Linux wrote:
>
> On Tue, Nov 10, 2020 at 12:10 PM Jian Cai wrote:
> >
> > I tried to verify with ixp4xx_defconfig, and I noticed it also used
> > CONFIG_CPU_BIG_ENDIAN=y to enable big endianness as follows,
> >
> > linux$ grep EN
> On Nov 10, 2020, at 10:39 AM, Christoph Hellwig wrote:
>
> On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
>> You do consistently ask for a shim layer, but you haven???t explained what
>> we gain by diverging from the documented and tested API of the upstream zstd
>> project. It
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
> +Decrement interface
> +---
> +
> +Decrements sequence number and doesn't return the new value. ::
> +
> +seqnum32_dec() --> atomic_dec()
> +seqnum64_dec() --> atomic64_dec()
Why would you need to decreme
On Tue, Nov 10, 2020 at 09:41:40PM +0100, Greg KH wrote:
> On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
> > +Decrement interface
> > +---
> > +
> > +Decrements sequence number and doesn't return the new value. ::
> > +
> > +seqnum32_dec() --> atomic_dec()
> >
On Tue, Nov 10, 2020 at 12:53:38PM -0700, Shuah Khan wrote:
> seqnum_ops api is introduced to be used when a variable is used as
> a sequence/stat counter and doesn't guard object lifetimes. This
> clearly differentiates atomic_t usages that guard object lifetimes.
>
> seqnum32 variables wrap arou
Hi Greg,
On 10/26/20 9:49 AM, Grzegorz Jaszczyk wrote:
> Since the of_device_get_match_data() doesn't return error code, remove
> wrong IS_ERR test. Proper check against NULL pointer is already done
> later before usage: if (data && data->...).
>
> Additionally, proceeding with empty device data
On Tue, Nov 10, 2020 at 12:53:26PM -0700, Shuah Khan wrote:
> There are a number of atomic_t usages in the kernel where atomic_t api
> is used strictly for counting sequence numbers and other statistical
> counters and not for managing object lifetime.
>
> The purpose of these Sequence Number Ops
> One note... I'll double check, but on my XPS 13 9380, as I recall, I
> have to manually disable autosuspend on all of the XHCI controllers
> and internal hubs after running "powertop --auto-tune", or else any
> external mouse attached to said USB device will be dead to the world
> for 2-3 seco
On Thu, Nov 05, 2020 at 02:44:04AM +0300, Dmitry Osipenko wrote:
> Introduce sync state API that will be used by Tegra device drivers. This
> new API is primarily needed for syncing state of SoC devices that are left
> ON after bootloader or permanently enabled. All these devices belong to a
> shar
On Tue, 10 Nov 2020 11:57:53 -0800 Roman Gushchin wrote:
> In general it's unknown in advance if a slab page will contain
> accounted objects or not. In order to avoid memory waste, an
> obj_cgroup vector is allocated dynamically when a need to account
> of a new object arises. Such approach is m
On Tue, Nov 10, 2020 at 12:56:11AM +0530, Vidya Sagar wrote:
> DesignWare core has a TLP digest (TD) override bit in one of the control
> registers of ATU. This bit also needs to be programmed for proper ECRC
> functionality. This is currently identified as an issue with DesignWare
> IP version 4.9
On Thu, Nov 05, 2020 at 02:44:15AM +0300, Dmitry Osipenko wrote:
[...]
> +static void tegra_pwm_deinit_opp_table(void *data)
> +{
> + struct device *dev = data;
> + struct opp_table *opp_table;
> +
> + opp_table = dev_pm_opp_get_opp_table(dev);
> + dev_pm_opp_of_remove_table(dev);
>
On Tue, Nov 10, 2020 at 7:37 AM Peter Zijlstra wrote:
>
> On Tue, Nov 10, 2020 at 04:12:57PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 09, 2020 at 10:12:37AM +0800, Like Xu wrote:
> > > The Precise Event Based Sampling(PEBS) supported on Intel Ice Lake server
> > > platforms can provide an arch
On Fri, Nov 06, 2020 at 11:04:19AM +0300, Dan Carpenter wrote:
> On Thu, Nov 05, 2020 at 04:24:30PM -0600, Bjorn Helgaas wrote:
> > On Wed, Oct 07, 2020 at 03:33:45PM +0300, Dan Carpenter wrote:
> > > On Wed, Oct 07, 2020 at 12:46:15PM +0100, Colin King wrote:
> > > > From: Colin Ian King
> > > >
Prarit,
On Tue, Nov 10 2020 at 14:24, Prarit Bhargava wrote:
> Occasionally when logging out of the ttyS0 aka serial console I see that
>
> irq 4: Affinity broken due to vector space exhaustion.
>
> *** console shutdown, IRQ released for cpu on socket 1
> *** console starts back up again, IR
Hi Alex,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[also build test ERROR on v5.10-rc3 next-20201110]
[cannot apply to nfsd/nfsd-next cel/for-next linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting
I'm announcing the release of the 5.9.8 kernel.
Only upgrade if you are vunerable to this Intel advisory:
https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00389.html
Hint, if you are using SGX, then upgrade. And then possibly reconsider
the decisions you have re
diff --git a/Makefile b/Makefile
index 035d86a0d291..ac292d6dd262 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 9
-SUBLEVEL = 7
+SUBLEVEL = 8
EXTRAVERSION =
NAME = Kleptomaniac Octopus
diff --git a/drivers/powercap/powercap_s
I'm announcing the release of the 5.4.77 kernel.
Please see the 5.9.8 announcement if you are curious if you should
upgrade or not:
https://lore.kernel.org/lkml/1605041246232...@kroah.com/
The updated 5.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/st
I'm announcing the release of the 4.4.243 kernel.
Please see the 5.9.8 announcement if you are curious if you should
upgrade or not:
https://lore.kernel.org/lkml/1605041246232...@kroah.com/
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/s
diff --git a/Makefile b/Makefile
index 842ed8411810..2e24b568b93f 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 5
PATCHLEVEL = 4
-SUBLEVEL = 76
+SUBLEVEL = 77
EXTRAVERSION =
NAME = Kleptomaniac Octopus
diff --git a/drivers/powercap/powercap
diff --git a/Makefile b/Makefile
index 0ba3fd914426..99badda272d7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 242
+SUBLEVEL = 243
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys
diff --git a/Makefile b/Makefile
index d41de2c1159e..c6fcfe4bfeed 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 242
+SUBLEVEL = 243
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/drivers/powercap/powercap_sys.c b/drivers/powercap/powercap_sys.c
I'm announcing the release of the 4.9.243 kernel.
Please see the 5.9.8 announcement if you are curious if you should
upgrade or not:
https://lore.kernel.org/lkml/1605041246232...@kroah.com/
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/s
I'm announcing the release of the 4.19.157 kernel.
Please see the 5.9.8 announcement if you are curious if you should
upgrade or not:
https://lore.kernel.org/lkml/1605041246232...@kroah.com/
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git
diff --git a/Makefile b/Makefile
index 82891b34e19e..245bcd8dd7b7 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 19
-SUBLEVEL = 156
+SUBLEVEL = 157
EXTRAVERSION =
NAME = "People's Front"
diff --git a/drivers/powercap/powercap_
I'm announcing the release of the 4.14.206 kernel.
Please see the 5.9.8 announcement if you are curious if you should
upgrade or not:
https://lore.kernel.org/lkml/1605041246232...@kroah.com/
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git
diff --git a/Makefile b/Makefile
index fff3ca75d35a..2d5ec8b7bcf5 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 205
+SUBLEVEL = 206
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/drivers/powercap/powercap_sys
On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote:
> On 10 November 2020 18:56:17 GMT, Thomas Gleixner wrote:
>>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
>>> On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
If I could get post-5.5 kernels to boot at all with the AMD IOMMU
>>
On Tue, 10 Nov 2020, Alex Deucher wrote:
> On Tue, Nov 10, 2020 at 4:41 AM Lee Jones wrote:
> >
> > On Tue, 10 Nov 2020, Sam Ravnborg wrote:
> >
> > > Hi Lee,
> > >
> > > > > the *d.h headers are supposed to just be hardware definitions. I'd
> > > > > prefer to keep driver stuff out of them.
> >
On 11/10/20 1:42 PM, Greg KH wrote:
On Tue, Nov 10, 2020 at 12:53:38PM -0700, Shuah Khan wrote:
seqnum_ops api is introduced to be used when a variable is used as
a sequence/stat counter and doesn't guard object lifetimes. This
clearly differentiates atomic_t usages that guard object lifetimes.
On Tue, Nov 10, 2020 at 12:53:27PM -0700, Shuah Khan wrote:
> Sequence Numbers wrap around to INT_MIN when it overflows and should not
Why would sequence numbers be signed? I know they're built on top of
atomic_t, which is signed, but conceptually a sequence number is unsigned.
> +++ b/Documenta
On Tue, 10 Nov 2020, Thierry Reding wrote:
> On Tue, Nov 03, 2020 at 03:28:37PM +, Lee Jones wrote:
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/soc/tegra/fuse/speedo-tegra210.c: In function
> > ‘tegra210_init_speedo_data’:
> > drivers/soc/tegra/fuse/speedo-tegra210
On Mon, 2 Nov 2020 at 16:04, Adrian Ratiu wrote:
>
> Dear all,
>
> This is v5 of the series adding VP9 profile 0 decoding to rkvdec.
>
> All feedback from v4 should be addressed, there's just one thing I did
> not address: ref_frame_sign_biases in the uAPI. The userspace tool I'm
I believe that H
On Thu, Nov 5, 2020 at 9:52 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/scheduler/sched_main.c:74: warning: Function parameter or
> member 'sched' not described in 'drm_sched_rq_init'
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Sumit Semwal
Hi all,
Commit
97cc16943f23 ("iwlwifi: mvm: write queue_sync_state only for sync")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpkw2d1CHp6t.pgp
Description: OpenPGP digital signature
On Thu, Nov 5, 2020 at 9:52 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/scheduler/sched_entity.c:316: warning: Function parameter or
> member 'f' not described in 'drm_sched_entity_clear_dep'
> drivers/gpu/drm/scheduler/sched_entity.c:316: warnin
On Thu, Nov 5, 2020 at 9:52 AM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_drv.c: In function
> ‘radeon_pmops_runtime_suspend’:
> drivers/gpu/drm/radeon/radeon_drv.c:455:6: warning: variable ‘ret’ set but
> not used [-Wunused-but-set-
Hi all,
In commit
e4b5575da267 ("ARM: OMAP2+: Manage MPU state properly for
omap_enter_idle_coupled()")
Fixes tag
Fixes: 8ca5ee624b4c ("ARM: OMAP2+: Restore MPU power domain if
cpu_cluster_pm_enter() fails")
has these problem(s):
- Target SHA1 does not exist
Maybe you meeant
Fixes:
10.11.2020 23:29, Thierry Reding пишет:
>> +
>> +dc->opp_table = dev_pm_opp_get_opp_table(dc->dev);
>> +if (IS_ERR(dc->opp_table))
>> +return dev_err_probe(dc->dev, PTR_ERR(dc->opp_table),
>> + "failed to prepare OPP table\n");
>> +
>> +if (of
10.11.2020 23:50, Thierry Reding пишет:
> On Thu, Nov 05, 2020 at 02:44:15AM +0300, Dmitry Osipenko wrote:
> [...]
>> +static void tegra_pwm_deinit_opp_table(void *data)
>> +{
>> +struct device *dev = data;
>> +struct opp_table *opp_table;
>> +
>> +opp_table = dev_pm_opp_get_opp_table(d
On Tue, 10 Nov 2020, Alex Deucher wrote:
> On Thu, Nov 5, 2020 at 9:52 AM Lee Jones wrote:
> >
> > Fixes the following W=1 kernel build warning(s):
> >
> > drivers/gpu/drm/radeon/radeon_drv.c: In function
> > ‘radeon_pmops_runtime_suspend’:
> > drivers/gpu/drm/radeon/radeon_drv.c:455:6: warnin
[+cc Nicolas, Jingoo, Gustavo, Toan]
On Sun, Nov 08, 2020 at 08:11:40PM +0100, Martin Kaiser wrote:
> Replace the two separate calls for removing the irq handler and data with a
> single irq_set_chained_handler_and_data() call.
This is similar to these:
36f024ed8fc9 ("PCI/MSI: pci-xgene-msi: C
10.11.2020 23:47, Thierry Reding пишет:
...
> tegra_soc_for_each_device
>
> I wonder if you copy/pasted this or if you got really lucky to mistype
> this all three times.
Copied of course :)
I added a special spell checking rule for this typo, but it does help
reliably.
...
>> +terga_soc_fo
10.11.2020 23:32, Mark Brown пишет:
> On Tue, Nov 10, 2020 at 09:29:45PM +0100, Thierry Reding wrote:
>> On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote:
>
>>> + /*
>>> +* Voltage scaling is optional and trying to set voltage for a dummy
>>> +* regulator will error out.
>
Hi Al,
On Tue, 10 Nov 2020 19:00:36 + Al Viro wrote:
>
> On Tue, Oct 27, 2020 at 04:59:12AM +, Al Viro wrote:
>
> > I'll rebase that branch on top of sparc tree tomorrow (and eventually I'd
> > like
> > it to go through the sparc tree anyway).
>
> Done - sorry for disappearing ;-/
N
On Thu 05 Nov 03:56 CST 2020, Rajendra Nayak wrote:
> Add device tree binding Documentation details for Qualcomm SC7280
> TLMM block.
>
> Signed-off-by: Rajendra Nayak
> Reviewed-by: Rob Herring
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> ---
> v2: Consolidated functions under phase_flag
On Thu 05 Nov 03:56 CST 2020, Rajendra Nayak wrote:
> diff --git a/drivers/pinctrl/qcom/pinctrl-sc7280.c
> b/drivers/pinctrl/qcom/pinctrl-sc7280.c
[..]
> +static const struct msm_pinctrl_soc_data sc7280_pinctrl = {
> + .pins = sc7280_pins,
> + .npins = ARRAY_SIZE(sc7280_pins),
> + .fun
On Tue 10 Nov 07:31 CST 2020, Linus Walleij wrote:
> On Thu, Nov 5, 2020 at 8:38 AM Maulik Shah wrote:
>
> > When GPIOs that are routed to PDC are used as output they can still latch
> > the IRQ pending at GIC. As a result the spurious IRQ was handled when the
> > client driver change the direct
On 10 November 2020 21:01:17 GMT, Thomas Gleixner wrote:
>On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote:
>
>> On 10 November 2020 18:56:17 GMT, Thomas Gleixner
> wrote:
>>>On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
On Tue, Nov 10 2020 at 16:33, David Woodhouse wrote:
>
Hi Rafael,
On Tue, 10 Nov 2020 18:43:04 +0100 "Rafael J. Wysocki"
wrote:
>
> > Fixes: 15d09e830bbc ("clk: qcom: camcc: Add camera clock controller driver
> > for SC7180")
>
> Applied to the PM tree as 5.10-rc material, thanks!
The problem is that the commit that this one fixes is in the clk tr
Dear Linus,
Please git pull the following branch:
git pull git://git.kernel.org/pub/scm/linux/kernel/git/konrad/swiotlb.git
stable/for-linus-5.10-rc2
which has two tiny fixes that make drivers under Xen unhappy under certain
conditions.
Thank you!
Christoph Hellwig (1):
swiotlb: remo
11.11.2020 00:22, Dmitry Osipenko пишет:
> I added a special spell checking rule for this typo, but it does help
> reliably.
does *not*
Hi Peter/Igor,
I went through this series while trying to grasp a bit more of all the
virtio inner workings and needs and I'll leave a few detailed comments
down below.
In short at first, I think I can say that there are a couple of places
where I noticed you had to play all sort of tricks to fit
On Wed, Nov 04, 2020 at 09:27:33AM +0100, Christoph Hellwig wrote:
> ssize_t seq_read(struct file *file, char __user *buf, size_t size, loff_t
> *ppos)
> {
> - struct seq_file *m = file->private_data;
> + struct iovec iov = { .iov_base = buf, .iov_len = size};
> + struct kiocb kiocb
On Wed, Oct 14, 2020 at 9:01 AM Zhe Li wrote:
>
> From: lizhe
>
> The jffs2 mount options will be ignored when remounting jffs2.
> It can be easily reproduced with the steps listed below.
> 1. mount -t jffs2 -o compr=none /dev/mtdblockx /mnt
> 2. mount -o remount compr=zlib /mnt
>
> Since ec10a24
On Fri, Nov 06, 2020 at 02:31:44PM +0100, Karol Herbst wrote:
> On Fri, Nov 6, 2020 at 3:17 AM Jeremy Cline wrote:
> >
> > Make use of the devm_drm_dev_alloc() API to bind the lifetime of
> > nouveau_drm structure to the drm_device. This is important because a
> > reference to nouveau_drm is acces
On Tue, Nov 10, 2020 at 09:32:53PM +, Al Viro wrote:
> AFAICS, not all callers want that semantics, but I think it's worth
> a new primitive. I'm not saying it should be a prereq for your
> series, but either that or an explicit iov_iter_revert() is needed.
Seeing that it already went into m
On Tue, 10 Nov 2020 at 21:38, Arnd Bergmann wrote:
>
> On Tue, Nov 10, 2020 at 9:11 PM 'Nick Desaulniers' via Clang Built
> Linux wrote:
> >
> > On Tue, Nov 10, 2020 at 12:10 PM Jian Cai wrote:
> > >
> > > I tried to verify with ixp4xx_defconfig, and I noticed it also used
> > > CONFIG_CPU_BIG_
On Mon, 2 Nov 2020 20:40:07 +0530, Sameer Pujar wrote:
> This series is a prepraration for using generic graph driver for Tegra210
> audio. Tegra audio graph series will be sent in a separate series because
> it has some dependency over other series for documentation work. This
> series can focus o
On Fri, 6 Nov 2020 14:48:17 +0800, Pi-Hsun Shih wrote:
> In regulator_late_cleanup when is_enabled failed, don't try to disable
> the regulator since it would likely to fail too and causing confusing
> error messages.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator
On Mon, 2 Nov 2020 18:18:10 +0200, Viorel Suman (OSS) wrote:
> The break condition copied by mistake as same
> as loop condition in the previous version, but must
> be the opposite. So fix it.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1]
On Tue, 10 Nov 2020 10:19:16 +0200, Matti Vaittinen wrote:
> RFC for adding a support for typical voltage scaling connection
>
> In few occasions there has been a need to scale the voltage output
> from bucks on BD71837. Usually this is done when buck8 is used to
> power specific GPU which can uti
On 2020.11.10 09:22 Rafael J. Wysocki wrote:
> On Monday, November 9, 2020 5:49:49 PM CET Rafael J. Wysocki wrote:
>>
>> Even after the changes made very recently, the handling of the powersave
>> governor is not exactly as expected when intel_pstate operates in the
>> "passive" mode with HWP enabl
On Mon, Nov 9, 2020 at 11:51 AM Adrian Ratiu wrote:
>
> On Fri, 06 Nov 2020, Nick Desaulniers
> wrote:
> > +#pragma clang loop vectorize(enable)
> > do {
> > p1[0] ^= p2[0] ^ p3[0] ^ p4[0] ^ p5[0]; p1[1] ^=
> > p2[1] ^ p3[1] ^ p4[1] ^ p5[1];
> > ``` seems t
On 10/30/20 6:18 AM, Mickaël Salaün wrote:
seccomp_bpf.c uses unshare(CLONE_NEWPID), which requires CONFIG_PID_NS
to be set.
Cc: Kees Cook
Cc: Shuah Khan
Cc: Tycho Andersen
Fixes: 6a21cc50f0c7 ("seccomp: add a return code to trap to userspace")
Signed-off-by: Mickaël Salaün
---
tools/testi
On Tue, 10 Nov 2020 at 17:39, Arvind Sankar wrote:
>
> Commit
> d9e9a6418065 ("x86/mm/pti: Allocate a separate user PGD")
> changed the PGD allocation to allocate PGD_ALLOCATION_ORDER pages, so in
> the error path it should be freed using free_pages() rather than
> free_page().
>
> Commit
> 06
[+cc Florian, sorry, I hadn't seen your ack when I sent the below]
On Tue, Nov 10, 2020 at 03:21:36PM -0600, Bjorn Helgaas wrote:
> [+cc Nicolas, Jingoo, Gustavo, Toan]
>
> On Sun, Nov 08, 2020 at 08:11:40PM +0100, Martin Kaiser wrote:
> > Replace the two separate calls for removing the irq handl
In the case that the SPI mux isn't set, the transfer_one_message
function returns without finalizing the message. This means that
the transfer never completes, resulting in hung tasks and an
eventual kernel panic. Fix it by finalizing the transfer in this
case.
Fixes: 9211a441e606 ("spi: fsi: Chec
On Thu, Nov 5, 2020 at 9:52 AM Lee Jones wrote:
>
> These 3 variables are used in *some* sourcefiles which include
> amdgpu.h, but not *all*. This leads to a flurry of build warnings.
>
> Fixes the following W=1 kernel build warning(s):
>
> from drivers/gpu/drm/amd/amdgpu/amdgpu.h:67,
> drivers
10.11.2020 23:29, Thierry Reding пишет:
>> +/* legacy device-trees don't have OPP table */
>> +if (!device_property_present(dc->dev, "operating-points-v2"))
>> +return 0;
> "Legacy" is a bit confusing here. For one, no device trees currently
> have these tables and secondly, for
On Thu, Nov 5, 2020 at 9:52 AM Lee Jones wrote:
>
> - Demote non-conformant headers
> - Fix misnaming issues
> - Rename labels with identical names
> - Remove incorrect descriptions
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_device.c:637:6: warning:
Hi, Peter,
> On Sun, Nov 08, 2020 at 04:29:16AM +, Fenghua Yu wrote:
> > split_lock_detect=
> > #AC for split lock #DB for bus lock
> >
> > off Do nothing Do nothing
> >
> > warnKernel OOPs Warn once per
On Tue, Nov 10, 2020 at 12:50:08PM -0800, Andrew Morton wrote:
> On Tue, 10 Nov 2020 11:57:53 -0800 Roman Gushchin wrote:
>
> > In general it's unknown in advance if a slab page will contain
> > accounted objects or not. In order to avoid memory waste, an
> > obj_cgroup vector is allocated dynami
On Fri, Nov 6, 2020 at 4:50 PM Lee Jones wrote:
>
> Both source files include atom.h, which seems like a reasonable
> location to place an atom based function into.
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_atombios.c:1791:6: warning: no previous
> pr
On Fri, Nov 6, 2020 at 4:50 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_kms.c:61:6: warning: no previous prototype for
> ‘radeon_driver_unload_kms’ [-Wmissing-prototypes]
> drivers/gpu/drm/radeon/radeon_kms.c:104:5: warning: no prev
One fixup following my patch commit be117ca32261 ("pinctrl:
qcom: Kconfig: Rework PINCTRL_MSM to be a depenency rather then
a selected config") being queued in LinusW's tree, as a new
config entry was added for the msm8953 that also needs the
change.
Applies to LinusW's pinctrl devel tree.
Cc: An
On Fri, Nov 6, 2020 at 4:50 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_drv.c:2: warning: Cannot understand * file
> radeon_drv.c
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Gareth H
On Fri, Nov 6, 2020 at 4:50 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> 62 | void radeon_driver_unload_kms(struct drm_device *dev)
> | ^~~~
> drivers/gpu/drm/radeon/radeon_kms.c:105:5: warning: no previous prototype
> for ‘radeon_driver_load
The numeric values that represent the event ring channel type are
identical to the values that represent the matching protocol used
for a channel. Use a new gsi_channel_type enumerated type to
represent the values programmed for both cases, using "CHANNEL_TYPE"
in member names in place of "EVT_CHT
Replace constants defined with an "_FVAL" suffix with values defined
in enumerated types, to be consistent with other usage in the driver.
Signed-off-by: Alex Elder
---
drivers/net/ipa/gsi.c | 2 +-
drivers/net/ipa/gsi_reg.h | 26 +-
2 files changed, 18 insertions(+)
This series rearranges and consolidates some GSI register
definitions. Its general aim is to make things more
consistent, by:
- Using enumerated types to define the values held in GSI register
fields
- Defining field values in "gsi_reg.h", together with the
definition of the register (
The gsi_err_code and gsi_err_type enumerated types are values that
fields in the GSI ERROR_LOG register can take on. Move their
definitions out of "gsi.c" and into "gsi_reg.h", alongside the
definition of the ERROR_LOG register offset and field symbols.
Drop the "_ERR" suffix in the names of the
The gsi_channel_type enumerated type define values used for the
channel type/protocol for event rings and channels. Move its
definition out of "gsi.c" and into "gsi_reg.h", alongside the
definition of the CH_C_CNTXT_0 register offset and its fields.
Add a comment near the definition of the EV_CH_E
The gsi_ch_cmd_opcode, gsi_evt_cmd_opcode, and gsi_generic_cmd_opcode
enumerated types are values that fields in the GSI command registers
can take on. Move their definitions out of "gsi.c" and into "gsi_reg.h",
alongside the definition of registers they are associated with.
Signed-off-by: Alex E
On Fri, Nov 6, 2020 at 4:50 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_kms.c:756:5: warning: no previous prototype
> for ‘radeon_get_vblank_counter_kms’ [-Wmissing-prototypes]
> 756 | u32 radeon_get_vblank_counter_kms(struct drm_cr
On Sat, Nov 7, 2020 at 2:33 AM Joe Perches wrote:
>
> On Fri, 2020-11-06 at 23:55 -0800, Nick Desaulniers wrote:
> > Clang is more aggressive about -Wformat warnings when the format flag
> > specifies a type smaller than the parameter. Fixes 8 instances of:
> >
> > warning: format specifies type '
On Tue, Nov 10, 2020 at 12:43:16PM -0500, William Breathitt Gray wrote:
> On Tue, Nov 10, 2020 at 10:52:42PM +0530, Syed Nayyar Waris wrote:
> > On Tue, Nov 10, 2020 at 6:05 PM William Breathitt Gray
> > wrote:
> > >
> > > On Tue, Nov 10, 2020 at 11:02:43AM +0100, Michal Simek wrote:
> > > >
> > >
Define the GSI global interrupt types with an enumerated type whose
values are the bit positions representing the global interrupt types.
Similarly, define the GSI general interrupt types with an enumerated
type whose values are the bit positions of general interrupt types.
Signed-off-by: Alex El
On 11/10/20 3:30 PM, David Woodhouse wrote:
>
>
> On 10 November 2020 21:01:17 GMT, Thomas Gleixner wrote:
>> On Tue, Nov 10 2020 at 19:21, David Woodhouse wrote:
>>
>>> On 10 November 2020 18:56:17 GMT, Thomas Gleixner
>> wrote:
On Tue, Nov 10 2020 at 18:50, Thomas Gleixner wrote:
> O
On 10/11/2020 20:54, Bjorn Helgaas wrote:
> On Fri, Nov 06, 2020 at 11:04:19AM +0300, Dan Carpenter wrote:
>> On Thu, Nov 05, 2020 at 04:24:30PM -0600, Bjorn Helgaas wrote:
>>> On Wed, Oct 07, 2020 at 03:33:45PM +0300, Dan Carpenter wrote:
On Wed, Oct 07, 2020 at 12:46:15PM +0100, Colin King w
On Fri, Nov 6, 2020 at 4:50 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/atombios_crtc.c:1796: warning: Excess function
> parameter 'encoder' description in 'radeon_get_shared_nondp_ppll'
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc:
On Tue, 2020-11-10 at 14:00 -0800, Nick Desaulniers wrote:
> Yeah, we could go through and remove %h and %hh to solve this, too, right?
Yup.
I think one of the checkpatch improvement mentees is adding
some suggestion and I hope an automated fix mechanism for that.
https://lore.kernel.org/lkml/5
If CONFIG_ZSMALLOC is enabled with xtensa then the build fails with:
mm/zsmalloc.c:43:10: fatal error: asm/sparsemem.h: No such file or directory
Disable CONFIG_ZSMALLOC for xtensa as xtensa arch has not defined
sparsemem.h.
Signed-off-by: Sudip Mukherjee
---
Build failed with next-20201110
On Mon, Nov 9, 2020 at 4:19 PM Lee Jones wrote:
>
> Fixes the following W=1 kernel build warning(s):
>
> drivers/gpu/drm/radeon/radeon_ttm.c: In function ‘radeon_ttm_tt_create’:
> drivers/gpu/drm/radeon/radeon_ttm.c:611:24: warning: variable ‘rdev’ set but
> not used [-Wunused-but-set-variable]
On Sat, 7 Nov 2020 23:45:30 -0500 Soheil Hassas Yeganeh
wrote:
> On Sat, Nov 7, 2020 at 8:43 PM Andrew Morton
> wrote:
> >
> > On Fri, 6 Nov 2020 18:16:27 -0500 Soheil Hassas Yeganeh
> > wrote:
> >
> > > From: Soheil Hassas Yeganeh
> > >
> > > This patch series is a follow up based on the
801 - 900 of 1567 matches
Mail list logo
