Occasionally when logging out of the ttyS0 aka serial console I see that
irq 4: Affinity broken due to vector space exhaustion.
is output to the console.
At boot the default smp_affinity is
/proc/irq/4/smp_affinity:00ff,,00ff
The irqbalance service runs and can change t
On 10 Nov 2020, at 13:39, 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???s an important
On Mon, Nov 9, 2020 at 11:36 PM Ard Biesheuvel wrote:
>
> BE32 != BE8
Oh? Sorry, what does BE8 stand for? arch/arm/mm/Kconfig says:
CONFIG_CPU_ENDIAN_BE8
Support for the BE-8 (big-endian) mode on ARMv6 and ARMv7 processors.
vs:
CPU_ENDIAN_BE32
Support for the BE-32 (big-endian) mode on pre-ARM
On Tue, 10 Nov 2020, Pablo Neira Ayuso wrote:
> Hi Casey,
>
> On Wed, Nov 04, 2020 at 04:49:17PM -0800, Casey Schaufler wrote:
> > Change netlink netfilter interfaces to use lsmcontext
> > pointers, and remove scaffolding.
> >
> > Reviewed-by: Kees Cook
> > Reviewed-by: John Johansen
> > Acked
On 11/10/2020 12:00 PM, John Stultz wrote:
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 msm9853 that also needs the
change.
Ap
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/trinity_dpm.c:146:18: warning: ‘trinity_sysls_default’
defined but not used [-Wunused-const-variable=]
drivers/gpu/drm/radeon/trinity_dpm.c:131:18: warning:
‘trinity_mgcg_shls_disable’ defined but not used [-Wunused-const-
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/r600.c:1615:5: warning: no previous prototype for
‘r600_gpu_check_soft_reset’ [-Wmissing-prototypes]
1615 | u32 r600_gpu_check_soft_reset(struct radeon_device *rdev)
| ^
Cc: Alex Deucher
Cc: "Chri
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/rv770_dpm.c:47:18: warning: no previous prototype for
‘rv770_get_ps’ [-Wmissing-prototypes]
47 | struct rv7xx_ps *rv770_get_ps(struct radeon_ps *rps)
| ^~~~
drivers/gpu/drm/radeon/rv770_dpm.c:54:26: warning: no pr
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen.c: In function ‘evergreen_gpu_init’:
drivers/gpu/drm/radeon/evergreen.c:1419: warning: Function parameter or member
'async' not described in 'evergreen_page_flip'
Cc: Alex Deucher
Cc: "Christian König"
Cc: Davi
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/si.c: In function ‘si_gpu_init’:
drivers/gpu/drm/radeon/si.c:3090: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: Daniel Ve
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/r600.c:3480:5: warning: no previous prototype for
‘r600_ih_ring_alloc’ [-Wmissing-prototypes]
3480 | int r600_ih_ring_alloc(struct radeon_device *rdev)
| ^~
drivers/gpu/drm/radeon/r600.c:3516:6: warning: n
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen_hdmi.c:37:6: warning: no previous prototype
for ‘dce4_audio_enable’ [-Wmissing-prototypes]
drivers/gpu/drm/radeon/evergreen_hdmi.c:67:6: warning: no previous prototype
for ‘evergreen_hdmi_update_acr’ [-Wmissing-p
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ni.c: In function ‘cayman_gpu_init’:
drivers/gpu/drm/radeon/ni.c:2679: warning: Function parameter or member 'ring'
not described in 'cayman_vm_flush'
drivers/gpu/drm/radeon/ni.c:2679: warning: Function parameter or member
This set is part of a larger effort attempting to clean-up W=1
kernel builds, which are currently overwhelmingly riddled with
niggly little warnings.
Exciting times (using Arm as the benchmark):
Before these sets:
5031 drivers/gpu/
3923 drivers/gpu/drm/amd/
258 drivers/gpu/drm/radeon/
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_irq_kms.c:53:13: warning: no previous prototype
for ‘radeon_driver_irq_handler_kms’ [-Wmissing-prototypes]
53 | irqreturn_t radeon_driver_irq_handler_kms(int irq, void *arg)
| ^
drivers/
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ni.c: In function ‘cayman_gpu_init’:
drivers/gpu/drm/radeon/ni.c:880: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: Daniel
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_sync.c:92: warning: Function parameter or member
'rdev' not described in 'radeon_sync_resv'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: amd-...@lists.freedeskto
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_dp_mst.c: In function ‘radeon_mst_encoder_dpms’:
drivers/gpu/drm/radeon/radeon_dp_mst.c:366:6: warning: variable ‘ret’ set but
not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen.c: In function ‘evergreen_gpu_init’:
drivers/gpu/drm/radeon/evergreen.c:3135:6: warning: variable ‘mc_shared_chmap’
set but not used [-Wunused-but-set-variable]
Cc: Alex Deucher
Cc: "Christian König"
Cc: David
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_mn.c:51: warning: Function parameter or member
'cur_seq' not described in 'radeon_mn_invalidate'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ni.c:1378:6: warning: no previous prototype for
‘cayman_cp_int_cntl_setup’ [-Wmissing-prototypes]
1378 | void cayman_cp_int_cntl_setup(struct radeon_device *rdev,
| ^~~~
drivers/gpu/drm/radeon/ni.c:173
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/evergreen_cs.c:1026: warning: Function parameter or
member 'p' not described in 'evergreen_cs_packet_parse_vline'
drivers/gpu/drm/radeon/evergreen_cs.c:1026: warning: Excess function parameter
'parser' description in 'ever
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 vmemmap associated
>> with HugeTLB pages. Now only support x86.
>>
>> S
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ni_dpm.c:727:23: warning: no previous prototype for
‘ni_get_pi’ [-Wmissing-prototypes]
727 | struct ni_power_info *ni_get_pi(struct radeon_device *rdev)
| ^
drivers/gpu/drm/radeon/ni_dpm.c:734:15: warning: no prev
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/r600_cs.c:793: warning: Function parameter or member
'p' not described in 'r600_cs_packet_parse_vline'
drivers/gpu/drm/radeon/r600_cs.c:793: warning: Excess function parameter
'parser' description in 'r600_cs_packet_parse_
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/sumo_dpm.c:81:25: warning: no previous prototype for
‘sumo_get_pi’ [-Wmissing-prototypes]
81 | struct sumo_power_info *sumo_get_pi(struct radeon_device *rdev)
| ^~~
Cc: Alex Deucher
Cc: "Christian König"
Cc: Dav
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/r100.c:163: warning: Function parameter or member
'async' not described in 'r100_page_flip'
drivers/gpu/drm/radeon/r100.c:848: warning: Function parameter or member
'rdev' not described in 'r100_ring_hdp_flush'
drivers/gp
On Wed, Nov 4, 2020 at 11:58 AM Lukasz Luba wrote:
>
> Hi Rafael,
>
> On 11/3/20 9:05 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > The Energy Model supports power values expressed in an abstract scale.
> > This has an impact on Intelligent Power Allocation (IPA) and should be
> > documented properly
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_prime.c:34:18: warning: no previous prototype
for ‘radeon_gem_prime_get_sg_table’ [-Wmissing-prototypes]
34 | struct sg_table *radeon_gem_prime_get_sg_table(struct drm_gem_object *obj)
| ^~~~
On Tue, Nov 10, 2020 at 06:40:45PM +0200, Vladimir Oltean wrote:
> I am fairly confident that this is how your hardware works, because
> that's also how peer delay wants to be timestamped, it seems.
So I was confident and also wrong, it appears. My KSZ9477 datasheet
says:
In the host-to-switch di
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/atombios_i2c.c:100:5: warning: no previous prototype
for ‘radeon_atom_hw_i2c_xfer’ [-Wmissing-prototypes]
100 | int radeon_atom_hw_i2c_xfer(struct i2c_adapter *i2c_adap,
| ^~~
drivers/gpu/drm/radeon/at
commit 6471384af2a6 ("mm: security: introduce init_on_alloc=1 and
init_on_free=1 boot options") resulted with init_on_alloc=1 in all pages
leaving the buddy via alloc_pages() and friends to be
initialized/cleared/zeroed on allocation.
However, the same logic is currently not applied to
alloc_conti
On 11/9/20 2:29 AM, Greg Kroah-Hartman wrote:
> On Sat, Nov 07, 2020 at 03:10:06PM +0100, Greg Kroah-Hartman wrote:
>> On Fri, Nov 06, 2020 at 08:27:44PM +, Vineet Gupta wrote:
>>> Hi Stable Team,
>>>
>>> On 10/19/20 7:19 PM, Vineet Gupta wrote:
This reverts commit 00fdec98d9881bf5173af09a
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: Rework PINCTRL_MSM to be a depenency rather then
> > a selected config") being queued in LinusW's tree, as a new
>
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_ttm.c:931:5: warning: no previous prototype for
‘radeon_mmap’ [-Wmissing-prototypes]
931 | int radeon_mmap(struct file *filp, struct vm_area_struct *vma)
| ^~~
Cc: Alex Deucher
Cc: "Christian König"
Cc: D
And the piece of code that has never been executed.
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/ci_dpm.c: In function ‘ci_set_dpm_event_sources’:
drivers/gpu/drm/radeon/ci_dpm.c:1369:28: warning: variable ‘dpm_event_src’ set
but not used [-Wunused-but-set-variable]
The PLL status polling loops in the set_rate callbacks of some PLLs
have no timeout detection and may become endless loops when something
goes wrong with the PLL.
For some PLLs there is already the ktime API based timeout detection,
but it will not work in all conditions when .set_rate gets called
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_ib.c:61: warning: Function parameter or member
'vm' not described in 'radeon_ib_get'
Cc: Alex Deucher
Cc: "Christian König"
Cc: David Airlie
Cc: Daniel Vetter
Cc: amd-...@lists.freedesktop.org
Cc: dri-de...@lists
On Fri, Nov 06, 2020 at 04:25:48PM +0100, Thierry Reding wrote:
> On Thu, Nov 05, 2020 at 05:47:21PM +, Robin Murphy wrote:
> > On 2020-11-05 16:43, Thierry Reding wrote:
> > > On Thu, Sep 24, 2020 at 01:27:25PM +0200, Thierry Reding wrote:
> > > > On Tue, Sep 15, 2020 at 02:36:48PM +0200, Thie
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: Rework PINCTRL_MSM to be a depenency rather then
a selected config") being queu
On Mon, Nov 9, 2020 at 1:45 PM Ard Biesheuvel wrote:
>
> On Mon, 9 Nov 2020 at 22:09, Nick Desaulniers wrote:
> >
> > I didn't see anything in linux-next today, or
> > https://www.armlinux.org.uk/developer/patches/ Incoming or Applied.
> >
> > Did it just get merged into the for-next branch, or i
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/cik_sdma.c:949: warning: Function parameter or member
'ring' not described in 'cik_dma_vm_flush'
drivers/gpu/drm/radeon/cik_sdma.c:949: warning: Function parameter or member
'vm_id' not described in 'cik_dma_vm_flush'
dri
> On Nov 10, 2020, at 7:25 AM, David Sterba wrote:
>
> On Mon, Nov 09, 2020 at 02:01:41PM -0500, Chris Mason wrote:
>> On 6 Nov 2020, at 13:38, Christoph Hellwig wrote:
>>> You just keep resedning this crap, don't you? Haven't you been told
>>> multiple times to provide a proper kernel API by no
Fixes the following W=1 kernel build warning(s):
drivers/gpu/drm/radeon/radeon_vm.c:131: warning: Function parameter or member
'rdev' not described in 'radeon_vm_get_bos'
drivers/gpu/drm/radeon/radeon_vm.c:643: warning: Excess function parameter
'start' description in 'radeon_vm_update_page_di
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 'evergreen_copy_
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: ‘mc3_cac_conf
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: Daniel
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 but
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 funct
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 u
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 si
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:
> srab@1
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 v
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’ [-Wmissing-prototypes
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 usag
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 resour
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 resour
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 resour
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 usag
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 resour
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 statistical
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 resour
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 resour
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 resour
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 resour
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 resour
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 a
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 resour
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 resour
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 functiona
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 *de
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 i
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 en
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
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 r
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 case).
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 i
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 arch/arm/
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 move_mount()
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 p
> 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
> __cpuhp_re
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 as
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 take
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 moti
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: Dmitry
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 (!device_property_p
701 - 800 of 1567 matches
Mail list logo
