Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen_dma.c:112: warning: Function parameter or
member 'resv' not described in 'evergreen_copy_dma'
drivers/gpu/drm/radeon/evergreen_dma.c:112: warning: Excess function parameter
'fence' description in
These haven't been used since the driver was upstreamed in 2013.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/kv_dpm.c:161:40: warning: ‘cpl_cac_config_reg’ defined
but not used [-Wunused-const-variable=]
drivers/gpu/drm/radeon/kv_dpm.c:156:40: warning:
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/cik.c: In function ‘cik_gpu_init’:
drivers/gpu/drm/radeon/cik.c:3180:6: warning: variable ‘mc_shared_chmap’ set
but not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc:
The Exynos clock output driver can be built as module (it does not have
to be part of core init process) for better customization. Adding a
KConfig entry allows also compile testing for build coverage.
Signed-off-by: Krzysztof Kozlowski
---
drivers/clk/samsung/Kconfig | 10
On Tue, Nov 03, 2020 at 03:28:26PM +, Lee Jones wrote:
> Fixes the following W=1 kernel build warning(s):
>
> drivers/soc/tegra/fuse/speedo-tegra124.c: In function
> ‘tegra124_init_speedo_data’:
> drivers/soc/tegra/fuse/speedo-tegra124.c:105:38: warning: variable
> ‘soc_iddq_value’ set
On 11/9/20 6:42 PM, Muchun Song wrote:
> On Tue, Nov 10, 2020 at 12:48 AM Oscar Salvador wrote:
>>
>> On Sun, Nov 08, 2020 at 10:10:56PM +0800, Muchun Song wrote:
>>
>> Unrelated to this patch but related in general, I am not sure about Mike but
>> would it be cleaner to move all the vmemmap
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.c:105:56: warning: variable
> ‘soc_iddq’ set but not
On Mon, Nov 09, 2020 at 07:31:04PM -0800, Florian Fainelli wrote:
> Upon discussion with Kurt, Rob and Vladimir it appears that we should be
> allowing ethernet-switch as a node name, update dsa.yaml accordingly.
>
> Signed-off-by: Florian Fainelli
> ---
Reviewed-by: Vladimir Oltean
On Tue, Nov 10, 2020 at 11:33 AM Jeffrey Hugo wrote:
>
> On 11/10/2020 12:32 PM, John Stultz wrote:
> > On Tue, Nov 10, 2020 at 11:29 AM Jeffrey Hugo wrote:
> >>
> >> On 11/10/2020 12:00 PM, John Stultz wrote:
> >>> One fixup following my patch commit be117ca32261 ("pinctrl:
> >>> qcom: Kconfig:
On Tue, Nov 10, 2020 at 09:24:36AM +0800, Chao Yu wrote:
> Fields in struct f2fs_move_range won't change in f2fs_ioc_move_range(),
> let's avoid copying this structure's data to userspace.
>
> Signed-off-by: Chao Yu
> ---
Reviewed-by: Eric Biggers
On Tue, Nov 10, 2020 at 09:24:37AM +0800, Chao Yu wrote:
> Eric reported a ioctl bug in below link:
>
> https://lore.kernel.org/linux-f2fs-devel/20201103032234.GB2875@sol.localdomain/
>
> That said, on some 32-bit architectures, u64 has only 32-bit alignment,
> notably i386 and x86_32, so that
On Fri, Nov 06, 2020 at 09:13:30PM +0530, Sameer Pujar wrote:
> DMA device nodes should follow regex pattern of "^dma-controller(@.*)?$".
> This is a preparatory patch to use YAML doc format for ADMA.
>
> Signed-off-by: Sameer Pujar
> ---
> arch/arm64/boot/dts/nvidia/tegra210-p2371-2180.dts | 2
Hello Sir,
On Tue, Nov 10, 2020 at 09:58:15AM -0800, Jakub Kicinski wrote:
> On Sun, 8 Nov 2020 00:48:35 +0530 Anmol Karn wrote:
> > + dev = rose_dev_get(dest);
>
> this calls dev_hold internally, you never release that reference in
> case ..neigh->dev is NULL
>
> > +
On Mon, Nov 09, 2020 at 07:31:06PM -0800, Florian Fainelli wrote:
> Update the switch unit name from srab to ethernet-switch, allowing us to
> fix warnings such as:
>
> CHECK arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml
> arch/arm/boot/dts/bcm4708-buffalo-wzr-1750dhp.dt.yaml:
>
On Fri, Nov 06, 2020 at 09:13:31PM +0530, Sameer Pujar wrote:
> Move ADMA documentation to YAML format.
>
> Signed-off-by: Sameer Pujar
> ---
> .../bindings/dma/nvidia,tegra210-adma.txt | 56
> .../bindings/dma/nvidia,tegra210-adma.yaml | 99
>
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:
> >> The purpose of introducing HUGETLB_PAGE_FREE_VMEMMAP is to configure
> >> whether to enable the feature of freeing unused
On Tue, 10 Nov 2020 08:39:24 +0530 Souptick Joarder
wrote:
> On Fri, Nov 6, 2020 at 4:55 PM Alex Shi wrote:
> >
> > Otherwise it cause gcc warning:
> > ^~~
> > ../mm/filemap.c:830:14: warning: no previous prototype for
> > ‘__add_to_page_cache_locked’
On Thu, Nov 05, 2020 at 11:29:28PM +0530, Deepak R Varma wrote:
> idr_init() uses base 0 which is an invalid identifier for this driver.
> The new function idr_init_base allows IDR to set the ID lookup from
> base 1. This avoids all lookups that otherwise starts from 0 since
> 0 is always unused.
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 is to clearly differentiate
atomic_t counter usages from atomic_t
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 around to INT_MIN when it overflows and
should not be used to guard
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 around to INT_MIN when it overflows and
should not be used to guard
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 around to INT_MIN when it overflows and
should not be used to guard
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 is to clearly differentiate
atomic_t counter usages from atomic_t
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 around to INT_MIN when it overflows and
should not be used to guard
Add a new selftest for testing seqnum_ops. This test loads test_seqnum_ops
test module and unloads it. The test module runs tests and prints results
to dmesg.
There are a number of atomic_t usages in the kernel where atomic_t api
is used strictly for counting sequence numbers and other
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 around to INT_MIN when it overflows and
should not be used to guard
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 around to INT_MIN when it overflows and
should not be used to guard
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 around to INT_MIN when it overflows and
should not be used to guard
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 around to INT_MIN when it overflows and
should not be used to guard
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 around to INT_MIN when it overflows and
should not be used to guard
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 seconds if the
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 around to INT_MIN when it overflows and
should not be used to guard
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 around to INT_MIN when it overflows and
should not be used to guard
It's convenient to have page->objects initialized before calling
into account_slab_page(). In particular, this information can be
used to pre-alloc the obj_cgroup vector.
Let's call account_slab_page() a bit later, after the initialization
of page->objects.
This commit doesn't bring any
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 memory efficient, but
requires an expensive cmpxchg() to set up the
On Thu, Oct 08, 2020 at 03:53:51PM +0800, yulei.ker...@gmail.com wrote:
> +static struct inode *
> +dmemfs_get_inode(struct super_block *sb, const struct inode *dir, umode_t
> mode,
> + dev_t dev);
WTF is 'dev' for?
> +static int
> +dmemfs_mknod(struct inode *dir, struct dentry
In the Rockchip DRM LVDS component driver, the endpoint id provided to
drm_of_find_panel_or_bridge is grabbed from the endpoint's reg property.
However, the property may be missing in the case of a single endpoint.
Initialize the endpoint_id variable to 0 to avoid using an
uninitialized variable
Frequency invariant accounting calculations need the ratio
freq_curr/freq_max, but freq_max is unknown as it depends on dynamic power
allocation between cores: AMD EPYC CPUs implement "Core Performance Boost".
Three candidates are considered to estimate this value:
- maximum non-boost frequency
-
v2 at https://lore.kernel.org/lkml/20201110183054.15883-1-ggherdov...@suse.cz/
Changes wrt v2:
- "code golf" on the function function init_freq_invariance_cppc().
Make better use of the "secondary" argument to init_freq_invariance(),
which was introduced at b56e7d45e807 ("x86, sched: Don't
From: Nathan Fontenot
This is the first pass in creating the ability to calculate the
frequency invariance on AMD systems. This approach uses the CPPC
highest performance and nominal performance values that range from
0 - 255 instead of a high and base frquency. This is because we do
not have
The value freq_max/freq_base is a fundamental component of frequency
invariance calculations. It may come from a variety of sources such as MSRs
or ACPI data, tracking it down when troubleshooting a system could be
non-trivial. It is worth saving it in the kernel logs.
# dmesg | grep 'Estimated
Hello Guenter,
On Sun, Nov 8, 2020 at 5:51 PM Guenter Roeck wrote:
>
> On Sun, Oct 25, 2020 at 02:59:13AM +0200, Luka Kovacic wrote:
> > Add the IEI WT61P803 PUZZLE HWMON driver, that handles the fan speed
> > control via PWM, reading fan speed and reading on-board temperature
> > sensors.
> >
>
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.
> > >
> > > That's fine (I did wonder if that were the
On Tue, 2020-11-10 at 19:30 +0100, Giovanni Gherdovich wrote:
> v1 at https://lore.kernel.org/lkml/20201110083936.31994-1-ggherdov...@suse.cz/
>
> Changes wrt v1:
>
> - made initialization safe under CPU hotplug.
> The function init_freq_invariance_cppc now lets only the first caller
> into
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 ENDIAN arch/arm/configs/ixp4xx_defconfig
> CONFIG_CPU_BIG_ENDIAN=y
>
> Also it appeared
On Tue, 2020-11-10 at 17:43 +0100, Alban Crequy wrote:
> Hi,
>
> I tested the patches on top of 5.10.0-rc3+ and I could mount an NFS
> share with a different user namespace. fsopen() is done in the
> container namespaces (user, mnt and net namespaces) while fsconfig(),
> fsmount() and
Hello,
On Wed, Nov 4, 2020 at 4:22 PM Lee Jones wrote:
>
> On Tue, 20 Oct 2020, kernel test robot wrote:
>
> > Hi Luka,
> >
> > Thank you for the patch! Perhaps something to improve:
> >
> > [auto build test WARNING on hwmon/hwmon-next]
> > [also build test WARNING on v5.9]
> > [cannot apply to
> On Nov 10, 2020, at 10:31 AM, Andrii Nakryiko
> wrote:
>
> On Tue, Nov 10, 2020 at 9:50 AM Song Liu wrote:
>>
>>
>>
>>> On Nov 9, 2020, at 5:19 PM, Andrii Nakryiko wrote:
>>>
>>> Adjust in-kernel BTF implementation to support a split BTF mode of
>>> operation.
>>> Changes are mostly
On Tue, Nov 10, 2020 at 07:01:18PM +, Chris Co wrote:
> From: Chris Co
>
> When invoking kexec() on a Linux guest running on a Hyper-V host, the
> kernel panics.
>
> RIP: 0010:cpuhp_issue_call+0x137/0x140
> Call Trace:
> __cpuhp_remove_state_cpuslocked+0x99/0x100
>
On Wed, 2020-11-11 at 00:36 +0530, Aditya Srivastava wrote:
> Currently checkpatch warns us if there is no 'Signed-off-by' line
> for the patch.
trivial style and a comment:
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
[]
> @@ -2755,6 +2757,10 @@ sub process {
> if
> On Nov 9, 2020, at 5:19 PM, Andrii Nakryiko wrote:
>
> Allocate ID for vmlinux BTF. This makes it visible when iterating over all BTF
> objects in the system. To allow distinguishing vmlinux BTF (and later kernel
> module BTF) from user-provided BTFs, expose extra kernel_btf flag, as well
Hello,
On Tue, Oct 13, 2020 at 10:21:31AM +0200, Uwe Kleine-König wrote:
> When a driver keeps a clock prepared (or enabled) during the whole
> lifetime of the driver, these helpers allow to simplify the drivers.
I'd really like to make use of these helpers, so it would be great if
you could
From: Matteo Croce
The kernel cmdline reboot= option offers some sort of control
on how the reboot is issued.
Add handles in sysfs to allow setting these reboot options, so they
can be changed when the system is booted, other than at boot time.
The handlers are under /kernel/reboot, can be read
On Tue, Nov 10, 2020 at 04:07:23PM +0100, Uwe Kleine-König wrote:
> The driver core doesn't check the return value of the remove callback
> because there is only little software can do when hardware disappears.
>
> So change the callback to not return a value at all and adapt all users.
> The
On Thu, Nov 05, 2020 at 02:44:08AM +0300, Dmitry Osipenko wrote:
> Add OPP and SoC core voltage scaling support to the display controller
> driver. This is required for enabling system-wide DVFS on older Tegra
> SoCs.
>
> Tested-by: Peter Geis
> Tested-by: Nicolas Chauvet
> Signed-off-by:
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.
> > +*/
> > + if
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
>
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
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
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
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
> 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.
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
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
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
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
>
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
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
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
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,
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
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
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:
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:
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
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
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
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:
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:
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
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:
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
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.
> +++
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’:
> >
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
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:
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
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
901 - 1000 of 1567 matches
Mail list logo
