On Fri, Aug 21, 2020 at 1:28 AM Tetsuo Handa
wrote:
>
> syzbot is reporting that del_timer_sync() is called from
> mwifiex_usb_cleanup_tx_aggr() from mwifiex_unregister_dev() without
> checking timer_setup() from mwifiex_usb_tx_init() was called [1].
>
> Ganapathi Bhat proposed a possibly cleaner
On 2020-08-24 14:44:55, Mimi Zohar wrote:
> Hi Tyler,
>
> On Tue, 2020-08-11 at 14:26 -0500, Tyler Hicks wrote:
> > v2:
> > - Always return an ERR_PTR from ima_alloc_rule_opt_list() (Nayna)
> > - Add Lakshmi's Reviewed-by to both patches
> > - Rebased on commit 3db0d0c276a7 ("integrity: remove
/proc/cpuinfo shows features which the kernel supports. Some of these
flags are derived from CPUID, and others are derived from other sources,
including some that are entirely software-based. Currently, there is
not any documentation in the kernel about how /proc/cpuinfo flags are
generated and
On Mon, 2020-08-24 at 10:54 -0700, John Hubbard wrote:
> On 8/24/20 3:53 AM, Jeff Layton wrote:
> > This looks fine to me. Let me know if you need this merged via the ceph
> > tree. Thanks!
> >
> > Acked-by: Jeff Layton
> >
>
> Yes, please! It will get proper testing that way, and it doesn't
On Sun, Aug 23, 2020 at 8:42 PM Gustavo A. R. Silva
wrote:
>
> Not sure what the problem was with my pull-request for -rc2. So, I'm giving
> this a second try because I think it is worth it.
Just "a ton of lines changed across subsystems, I feel like I need to check it".
For example, you say
Hi Mauro.
> Before posting the big patch series again, let me send the new
> version folded into a single patch.
Review 1/N
Lots of small details I missed last time.
A good thing is that there is an opportunity to delete som more code.
Sam
> diff --git
Hi Tyler,
On Tue, 2020-08-11 at 14:26 -0500, Tyler Hicks wrote:
> v2:
> - Always return an ERR_PTR from ima_alloc_rule_opt_list() (Nayna)
> - Add Lakshmi's Reviewed-by to both patches
> - Rebased on commit 3db0d0c276a7 ("integrity: remove redundant
>initialization of variable ret") of
From: Jordan Crouse
Add support to create a io-pgtable for use by targets that support
per-instance pagetables. In order to support per-instance pagetables the
GPU SMMU device needs to have the qcom,adreno-smmu compatible string and
split pagetables enabled.
Signed-off-by: Jordan Crouse
From: Jordan Crouse
Add support for allocating private address space instances. Targets that
support per-context pagetables should implement their own function to
allocate private address spaces.
The default will return a pointer to the global address space.
Signed-off-by: Jordan Crouse
From: Jordan Crouse
Add support for using per-instance pagetables if all the dependencies are
available.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
Reviewed-by: Akhil P Oommen
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 63 +++
From: Rob Clark
In $debugfs/gem we already show any vma(s) associated with an object.
Also show process names if the vma's address space is a per-process
address space.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 2 +-
From: Jordan Crouse
Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
split pagetables and per-instance pagetables for drm/msm.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/sdm845-cheza.dtsi | 9 +
From: Rob Clark
For the Adreno GPU's SMMU, we want SCTLR.HUPCF set to ensure that
pending translations are not terminated on iova fault. Otherwise
a terminated CP read could hang the GPU by returning invalid
command-stream data.
Signed-off-by: Rob Clark
---
From: Jordan Crouse
Now that we can get the ctx from the submitqueue, the extra arg is
redundant.
Signed-off-by: Jordan Crouse
[split out of previous patch to reduce churny noise]
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 12 +---
From: Jordan Crouse
Use the aperture settings from the IOMMU domain to set up the virtual
address range for the GPU. This allows us to transparently deal with
IOMMU side features (like split pagetables).
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
On 8/24/20 11:36 AM, John Hubbard wrote:
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some
From: Jordan Crouse
Every Qcom Adreno GPU has an embedded SMMU for its own use. These
devices depend on unique features such as split pagetables,
different stall/halt requirements and other settings. Identify them
with a compatible string so that they can be identified in the
arm-smmu
From: Rob Clark
Set the qcom,adreno-smmu compatible string for the GPU SMMU to enable
split pagetables and per-instance pagetables for drm/msm.
Signed-off-by: Rob Clark
---
arch/arm64/boot/dts/qcom/sc7180.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Rob Clark
Currently it doesn't matter, since we free the ctx immediately. But
when we start refcnt'ing the ctx, we don't want old dangling list
entries to hang around.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_submitqueue.c | 4 +++-
1 file
From: Jordan Crouse
Do a bit of prep work to add the upcoming adreno-smmu implementation.
Add an hook to allow the implementation to choose which context banks
to allocate.
Move some of the common structs to arm-smmu.h in anticipation of them
being used by the implementations and update some
From: Jordan Crouse
Each submitqueue is attached to a context. Add a pointer to the
context to the submitqueue at create time and refcount it so
that it stays around through the life of the queue.
Co-developed-by: Rob Clark
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
From: Jordan Crouse
Add a special implementation for the SMMU attached to most Adreno GPU
target triggered from the qcom,adreno-smmu compatible string.
The new Adreno SMMU implementation will enable split pagetables
(TTBR1) for the domain attached to the GPU device (SID 0) and
hard code it
On Mon, 24 Aug 2020 20:54:33 +0800 Alex Shi wrote:
> The new version which bases on v5.9-rc2. The first 6 patches was picked into
> linux-mm, and add patch 25-32 that do some further post optimization.
32 patches, version 18. That's quite heroic. I'm unsure whether I
should merge it up at
From: Rob Clark
This series adds an Adreno SMMU implementation to arm-smmu to allow GPU hardware
pagetable switching.
The Adreno GPU has built in capabilities to switch the TTBR0 pagetable during
runtime to allow each individual instance or application to have its own
pagetable. In order to
From: Rob Clark
Sprinkle a few `const`s where helpers don't need write access.
Signed-off-by: Rob Clark
---
drivers/iommu/arm/arm-smmu/arm-smmu.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu/arm/arm-smmu/arm-smmu.h
From: Jordan Crouse
Construct the io-pgtable config before calling the implementation specific
init_context function and pass it so the implementation specific function
can get a chance to change it before the io-pgtable is created.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
From: Rob Clark
This interface will be used for drm/msm to coordinate with the
qcom_adreno_smmu_impl to enable/disable TTBR0 translation.
Once TTBR0 translation is enabled, the GPU's CP (Command Processor)
will directly switch TTBR0 pgtables (and do the necessary TLB inv)
synchronized to the
From: Rob Clark
In a later patch, the drvdata will not directly be 'struct msm_gpu *',
so add a helper to reduce the churn.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 10 --
drivers/gpu/drm/msm/msm_gpu.c | 6
From: Rob Clark
This will be populated by adreno-smmu, to provide a way for coordinating
enabling/disabling TTBR0 translation.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 2 --
drivers/gpu/drm/msm/msm_gpu.c | 2 +-
From: Jordan Crouse
Enable TTBR1 for a context bank if IO_PGTABLE_QUIRK_ARM_TTBR1 is selected
by the io-pgtable configuration.
Signed-off-by: Jordan Crouse
Signed-off-by: Rob Clark
---
drivers/iommu/arm/arm-smmu/arm-smmu.c | 21 -
drivers/iommu/arm/arm-smmu/arm-smmu.h |
On Mon, Aug 24, 2020 at 6:47 PM Michael Kelley wrote:
> +
> +#define hv_get_simp(val) (val = hv_get_vpreg(HV_REGISTER_SIPP))
> +
> +#define hv_get_siefp(val) (val = hv_get_vpreg(HV_REGISTER_SIFP))
Macros that modify their arguments are generally a bad idea. Since each one
of these only has a few
This code was using get_user_pages*(), in a "Case 2" scenario
(DMA/RDMA), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_pages*() + unpin_user_pages() calls.
There is some helpful background in [2]: basically, this is a
Changes in v3:
- included missing preliminary patch to define the SB barrier instruction, see
patch change log for details on how it was back ported into v4.9
Changes in v2:
- added missing hunk in hyp/entry.S per Will's feedback
Will Deacon (2):
arm64: Add support for SB barrier and patch
From: Will Deacon
commit 679db70801da9fda91d26caf13bf5b5ccc74e8e8 upstream
Some CPUs can speculate past an ERET instruction and potentially perform
speculative accesses to memory before processing the exception return.
Since the register state is often controlled by a lower privilege level
at
Changes in v2:
- included missing preliminary patch to define the SB barrier instruction
Will Deacon (2):
arm64: Add support for SB barrier and patch in over DSB; ISB sequences
arm64: entry: Place an SB sequence following an ERET instruction
arch/arm64/include/asm/assembler.h | 13
From: Will Deacon
commit bd4fb6d270bc423a9a4098108784f7f9254c4e6d upstream
We currently use a DSB; ISB sequence to inhibit speculation in set_fs().
Whilst this works for current CPUs, future CPUs may implement a new SB
barrier instruction which acts as an architected speculation barrier.
On
From: Will Deacon
commit 679db70801da9fda91d26caf13bf5b5ccc74e8e8 upstream
Some CPUs can speculate past an ERET instruction and potentially perform
speculative accesses to memory before processing the exception return.
Since the register state is often controlled by a lower privilege level
at
From: Will Deacon
commit 679db70801da9fda91d26caf13bf5b5ccc74e8e8 upstream
Some CPUs can speculate past an ERET instruction and potentially perform
speculative accesses to memory before processing the exception return.
Since the register state is often controlled by a lower privilege level
at
From: Will Deacon
commit bd4fb6d270bc423a9a4098108784f7f9254c4e6d upstream
We currently use a DSB; ISB sequence to inhibit speculation in set_fs().
Whilst this works for current CPUs, future CPUs may implement a new SB
barrier instruction which acts as an architected speculation barrier.
On
From: Will Deacon
commit bd4fb6d270bc423a9a4098108784f7f9254c4e6d upstream
We currently use a DSB; ISB sequence to inhibit speculation in set_fs().
Whilst this works for current CPUs, future CPUs may implement a new SB
barrier instruction which acts as an architected speculation barrier.
On
Changes in v2:
- included missing preliminary patch to define the SB barrier instruction
Will Deacon (2):
arm64: Add support for SB barrier and patch in over DSB; ISB sequences
arm64: entry: Place an SB sequence following an ERET instruction
arch/arm64/include/asm/assembler.h | 13
On 8/24/20 11:28 AM, Jean-Philippe Brucker wrote:
>> +/**
>> + * struct ioasid_set - Meta data about ioasid_set
>> + * @type: Token types and other features
> nit: doesn't follow struct order
>
>> + * @token: Unique to identify an IOASID set
>> + * @xa: XArray to store ioasid_set
On Mon, Aug 24, 2020 at 6:48 PM Michael Kelley wrote:
>
> /*
> + * This function is invoked via the ACPI clocksource probe mechanism. We
> + * don't actually use any values from the ACPI GTDT table, but we set up
> + * the Hyper-V synthetic clocksource and do other initialization for
> + *
Hi Krzysztof,
On Mon, Aug 24, 2020 at 1:03 PM Krzysztof Kozlowski wrote:
> + {
> + pinctrl-names = "default";
> + pinctrl-0 = <_ecspi1>;
> + cs-gpios = < 14 GPIO_ACTIVE_HIGH>,
> + < 0 GPIO_ACTIVE_HIGH>;
These should be active low as 'spi-cs-high' is not
This amortises the overhead of retrieving pages from the pagecache
and the overhead of freeing pages if we happen to end up with the
last references to the pages.
Signed-off-by: Matthew Wilcox (Oracle)
---
fs/afs/write.c | 41 -
1 file changed, 24
Since I'm almost certain I didn't get capability checking right for
pre-volta chipsets, let's start logging any caps we find to make things
like this obvious in the future.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 10 ++
1 file changed, 10 insertions(+)
Not entirely sure why this never came up when I originally tested this
(maybe some BIOSes already have this setup?) but the ->caps_init vfunc
appears to cause the display engine to throw an exception on driver
init, at least on my ThinkPad P72:
nouveau :01:00.0: disp: chid 0 mthd 008c data
On 8/24/20 11:28 AM, Jean-Philippe Brucker wrote:
>> +/**
>> + * struct ioasid_data - Meta data about ioasid
>> + *
>> + * @id: Unique ID
>> + * @users Number of active users
>> + * @state Track state of the IOASID
>> + * @set Meta data of the set this IOASID belongs to
From: Tao Ren
Update FMC flash0's label to "spi0.0" so it's consistent with all the
other Facebook OpenBMC platforms.
Signed-off-by: Tao Ren
---
arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Tao Ren
Enable UART4's NRTS4 (A19) pin because the pin is used for RS485
software emulation.
Signed-off-by: Tao Ren
---
arch/arm/boot/dts/aspeed-bmc-facebook-wedge40.dts | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Fri, Aug 21, 2020 at 09:35:11PM -0700, Jacob Pan wrote:
> Rename ioasid_set_data() to ioasid_attach_data() to avoid confusion with
> struct ioasid_set. ioasid_set is a group of IOASIDs that share a common
> token.
>
> Signed-off-by: Jacob Pan
Reviewed-by: Jean-Philippe Brucker
> ---
>
From: Tao Ren
This patch series fixes a few nits in wedge40 device tree.
Patch #1 updates FMC flash label so it's consistent with other Facebook
OpenBMC platforms.
Patch #2 updates UART4 pin settings for the purpose of RS485 software
emulation.
Tao Ren (2):
ARM: dts: aspeed: wedge40: Update
This patch series adds a new pair of PHY APIs that can be used to get/set
all the PHY attributes. It also adds a new PHY attribute max_link_rate.
It includes following patches:
1. v5-0001-phy-Add-new-PHY-attribute-max_link_rate-and-APIs-.patch
This patch adds max_link_rate as a new PHY attribute
On Fri, Aug 21, 2020 at 09:35:12PM -0700, Jacob Pan wrote:
> ioasid_set was introduced as an arbitrary token that are shared by a
> group of IOASIDs. For example, if IOASID #1 and #2 are allocated via the
> same ioasid_set*, they are viewed as to belong to the same set.
>
> For guest SVA usages,
Add new PHY attribute max_link_rate to struct phy_attrs.
Add a pair of PHY APIs to get/set all the PHY attributes.
Use phy_get_attrs() to get attribute values and phy_set_attrs()
to set attribute values.
Signed-off-by: Yuti Amonkar
Signed-off-by: Swapnil Jakhade
Acked-by: Kishon Vijay Abraham I
Use generic PHY framework function phy_set_attrs() to set number
of lanes and maximum link rate supported by PHY.
Signed-off-by: Swapnil Jakhade
Acked-by: Kishon Vijay Abraham I
---
drivers/phy/cadence/phy-cadence-torrent.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
On Mon, 24 Aug 2020 16:42:01 +0300
Andy Shevchenko wrote:
> How making it make's option prevent some "smart" distros to achieve the same?
> AFAIU any compile-time knob will allow to build a kernel w/o a feature and you
> are against of such kernel builds in distros. Catch-22?
Because it will
On Mon, Aug 24, 2020 at 12:38 PM Sasha Levin wrote:
>
> From: Jiansong Chen
>
> [ Upstream commit da2446b66b5e2c7f3ab63912c8d999810e35e8b3 ]
>
> This reverts commit 9c9b17a7d19a8e21db2e378784fff1128b46c9d3.
> Newly released sdma fw (51.52) provides a fix for the issue.
>
> Signed-off-by:
On Mon, Aug 24, 2020 at 12:38 PM Sasha Levin wrote:
>
> From: Jiansong Chen
>
> [ Upstream commit 9c9b17a7d19a8e21db2e378784fff1128b46c9d3 ]
>
> gfxoff is temporarily disabled for navy_flounder,
> since at present the feature has broken some basic
> amdgpu test.
>
> Signed-off-by: Jiansong Chen
On Mon, Aug 24, 2020 at 12:37 PM Sasha Levin wrote:
>
> From: Jiansong Chen
>
> [ Upstream commit da2446b66b5e2c7f3ab63912c8d999810e35e8b3 ]
>
> This reverts commit 9c9b17a7d19a8e21db2e378784fff1128b46c9d3.
> Newly released sdma fw (51.52) provides a fix for the issue.
>
> Signed-off-by:
On Mon, Aug 24, 2020 at 12:36 PM Sasha Levin wrote:
>
> From: Jiansong Chen
>
> [ Upstream commit da2446b66b5e2c7f3ab63912c8d999810e35e8b3 ]
>
> This reverts commit 9c9b17a7d19a8e21db2e378784fff1128b46c9d3.
> Newly released sdma fw (51.52) provides a fix for the issue.
>
> Signed-off-by:
On Mon, Aug 24, 2020 at 12:37 PM Sasha Levin wrote:
>
> From: Jiansong Chen
>
> [ Upstream commit 9c9b17a7d19a8e21db2e378784fff1128b46c9d3 ]
>
> gfxoff is temporarily disabled for navy_flounder,
> since at present the feature has broken some basic
> amdgpu test.
>
> Signed-off-by: Jiansong Chen
On Mon, Aug 24, 2020 at 12:36 PM Sasha Levin wrote:
>
> From: Jiansong Chen
>
> [ Upstream commit 9c9b17a7d19a8e21db2e378784fff1128b46c9d3 ]
>
> gfxoff is temporarily disabled for navy_flounder,
> since at present the feature has broken some basic
> amdgpu test.
>
> Signed-off-by: Jiansong Chen
Hi Lennart,
Thanks for the report, I'll look into it. FWIW, we've been using
LOOP_CONFIGURE on Android with lo_offset/lo_sizelimit without issues,
but it may be a particular configuration that's causing issues.
Thanks,
Martijn
On Mon, Aug 24, 2020 at 5:44 PM Lennart Poettering wrote:
>
> Hi!
>
On Mon, Aug 24, 2020 at 8:38 AM Kirill Tkhai wrote:
>
> Sure, KSM does not increment page counter, when a page becomes PageKsm().
> Is patch comment about that? Even if so, I don't understand what this
> comment is about. "PageKsm() does not take additional counter" is not
> a reason the page
SDHCI presets are not currently used for eMMC HS/HS200/HS400, but are
used for DDR52. The HS400 retuning sequence is:
HS400->DDR52->HS->HS200->Perform Tuning->HS->HS400
This means that when HS400 tuning happens, we transition through DDR52
for a very brief period. This causes presets to be
7ba4521bccd
>> commit: de8f5e4f2dc1f032b46afda0a78cab5456974f89 lockdep: Introduce
>> wait-type checks
>> date: 5 months ago
>> config: arc-randconfig-r004-20200824 (attached as .config)
>> compiler: arc-elf-gcc (GCC) 9.3.0
>> reproduce (this is a W=1 build):
>> wget
&
On Mon, Aug 24, 2020 at 07:54:07PM +0800, Guohua Zhong wrote:
> >> Yet, I have noticed that there is no checking of 'base' in these functions.
> >> But I am not sure how to check is better.As we know that the result is
> >> undefined when divisor is zero. It maybe good to print error and dump
>
On Sun, 23 Aug 2020 13:50:42 +0530 Himadri Pandya wrote:
> Initialize the buffer before passing it to usb_read_cmd() function(s) to
> fix the uninit-was-stored issue in asix_read_cmd().
>
> Fixes: KMSAN: kernel-infoleak in raw_ioctl
Regardless of the ongoing discussion - could you please make
Hi Peter,
On Mon, 24 Aug 2020 16:14:29 +0200
Peter Zijlstra wrote:
> On Mon, Aug 24, 2020 at 12:02:58PM +, eddy...@trendmicro.com wrote:
> > After bisecting, I found this behavior seems to introduce by this
> > commit: (5.8-rc1) 0d00449c7a28a1514595630735df383dec606812 x86:
> > Replace
On 8/24/20 7:00 AM, Stephen Smalley wrote:
+int security_read_policy_kernel(struct selinux_state *state,
+ void **data, size_t *len)
+{
+ int rc;
+
+ rc = security_read_policy_len(state, len);
+ if (rc)
+ return rc;
+
+ *data =
On Mon, Aug 24, 2020 at 12:00 AM Rikard Falkeborn
wrote:
>
> The only usage is to pass its address to devm_phy_create() which takes a
> const pointer. Make it const to allow the compiler to put it in
> read-only memory.
>
> Signed-off-by: Rikard Falkeborn
thank you for this patch! please add my:
-20200823
i386 randconfig-a004-20200823
i386 randconfig-a003-20200823
i386 randconfig-a005-20200823
i386 randconfig-a006-20200823
i386 randconfig-a001-20200823
i386 randconfig-a002-20200824
i386
On 8/24/20 7:34 PM, Kees Cook wrote:
> On Mon, Aug 24, 2020 at 03:59:21PM +0300, Denis Efremov wrote:
>> Modify seccomp_do_user_notification(), __seccomp_filter(),
>> __secure_computing() to use current_pt_regs().
>
> This looks okay. It seems some architectures have a separate
> define for
On 8/19/20 6:43 AM, Geert Uytterhoeven wrote:
> Some EtherAVB variants support internal clock delay configuration, which
> can add larger delays than the delays that are typically supported by
> the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
> properties).
>
> Historically, the
On 8/19/20 6:43 AM, Geert Uytterhoeven wrote:
> Currently, full delay handling is done in both the probe and resume
> paths. Split it in two parts, so the resume path doesn't have to redo
> the parsing part over and over again.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Sergei
On 8/19/20 6:43 AM, Geert Uytterhoeven wrote:
> Convert the Renesas Ethernet AVB (EthernetAVB-IF) Device Tree binding
> documentation to json-schema.
>
> Add missing properties.
> Update the example to match reality.
>
> Signed-off-by: Geert Uytterhoeven
> Reviewed-by: Sergei Shtylyov
>
On 8/19/20 6:43 AM, Geert Uytterhoeven wrote:
> Some EtherAVB variants support internal clock delay configuration, which
> can add larger delays than the delays that are typically supported by
> the PHY (using an "rgmii-*id" PHY mode, and/or "[rt]xc-skew-ps"
> properties).
>
> Add properties for
On 8/19/20 6:43 AM, Geert Uytterhoeven wrote:
> Internal Receive and Transmit Clock Delays are a common setting for
> RGMII capable devices.
>
> While these delays are typically applied by the PHY, some MACs support
> configuring internal clock delay settings, too. Hence add standardized
>
On 8/24/20 3:53 AM, Jeff Layton wrote:
This looks fine to me. Let me know if you need this merged via the ceph
tree. Thanks!
Acked-by: Jeff Layton
Yes, please! It will get proper testing that way, and it doesn't have
any prerequisites, despite being part of this series. So it would be
On 8/24/2020 10:04 AM, Brendan Jackman wrote:
> On Mon, 24 Aug 2020 at 18:43, Casey Schaufler wrote:
>> On 8/24/2020 8:20 AM, Brendan Jackman wrote:
>>> On Fri, 21 Aug 2020 at 00:46, Casey Schaufler
>>> wrote:
On 8/20/2020 9:47 AM, Brendan Jackman wrote:
>>> [...]
What does NOP really
Ben Boeckel wrote:
> > One loss message. I set a flag on the last slot in the pipe ring to say
> > that
> > message loss occurred, but there's insufficient space to store a counter
> > without making the slot larger (and I really don't want to do that).
> >
> > Note that every slot in the
On Mon, Aug 24, 2020 at 10:21:51PM +0530, Naresh Kamboju wrote:
> on x86_64 kasan enabled build this kernel warning noticed while running
> LTP syscalls fork13 test case.
>
> metadata:
> git branch: linux-5.8.y
> git repo:
>
On Mon, Aug 24, 2020 at 05:40:32PM +, Michael Kelley wrote:
> From: Greg KH Sent: Monday, August 24, 2020
> 10:35 AM
> >
> > On Mon, Aug 24, 2020 at 09:46:22AM -0700, Michael Kelley wrote:
> > > The Hyper-V frame buffer driver may be built as a module, and
> > > it needs access to
tead of a global variable. This will prevent reads
> from being reordered across writes, while allowing memory loads to be
> cached/reordered across CRn reads, which should be safe.
>
> Signed-off-by: Arvind Sankar
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82602
I a
From: "Rafael J. Wysocki"
Because hwp_req_cached contains the effective EPP value (0) when the
"performance" scaling algorithm is used in the active mode, replace
it with the cached EPP value during CPU offline to prevent it from
being used (unexpectedly) after switching over from the active
Hi All,
The v2 is here to address feedback from Doug and one issue found by me.
The purpose of this series is to address some peculiarities related to
taking CPUs offline/online and switching between different operation
modes with HWP enabled that have become visible after allowing the
driver to
From: "Rafael J. Wysocki"
After commit f6ebbcf08f37 ("cpufreq: intel_pstate: Implement passive
mode with HWP enabled") it is possible to change the driver status
to "off" via sysfs with HWP enabled, which effectively causes the
driver to unregister itself, but HWP remains active and it forces
From: "Rafael J. Wysocki"
When intel_pstate switches the operation mode from "active" to
"passive" or the other way around, freeing its data structures
representing CPUs and allocating them again from scratch is not
necessary and wasteful. Moreover, if these data structures are
preserved, the
From: "Rafael J. Wysocki"
Make the energy_performance_preference policy attribute in sysfs
always return the last EPP value written to it instead of the one
currently in the HWP Request MSR to avoid possible confusion when
the performance scaling algorithm is used in the active mode with
HWP
From: "Rafael J. Wysocki"
Add ->offline and ->online driver callbacks to prepare for taking a
CPU offline and to restore its working configuration when it goes
back online, respectively, to avoid invoking the ->init callback on
every CPU online which is quite a bit of unnecessary overhead.
Hi Roberto,
On Fri, 2020-08-21 at 14:30 -0400, Mimi Zohar wrote:
> Sorry for the delay in reviewing these patches. Missing from this
> patch set is a cover letter with an explanation for grouping these
> patches into a patch set, other than for convenience. In this case, it
> would be along
par->vgapass is a u8, so if we are assuming that buf is at least
PAGE_SIZE then the extra checking is pointless.
Signed-off-by: Alex Dewar
---
drivers/video/fbdev/sstfb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/sstfb.c
On Thu, 2020-08-20 at 21:03 +0300, Imre Deak wrote:
> On Thu, Aug 20, 2020 at 12:27:03PM +1000, Sam McNally wrote:
> > > > [...]
> > > > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > > > index 1ac874e4e7a1..73a2299c2faa 100644
> > > > ---
From: Greg KH Sent: Monday, August 24, 2020 10:35
AM
>
> On Mon, Aug 24, 2020 at 09:46:22AM -0700, Michael Kelley wrote:
> > The Hyper-V frame buffer driver may be built as a module, and
> > it needs access to screen_info. So export screen_info.
> >
> > Signed-off-by: Michael Kelley
> > ---
>
On Mon, 24 Aug 2020 14:17:10 +0530, Vinod Koul wrote:
> Add devicetree binding documentation for GPI DMA controller
> implemented on Qualcomm SoCs
>
> Signed-off-by: Vinod Koul
> ---
> .../devicetree/bindings/dma/qcom-gpi.yaml | 87 +++
> 1 file changed, 87 insertions(+)
>
From: Bartosz Golaszewski
Implement the managed variant of krealloc(). This function works with
all memory allocated by devm_kmalloc() (or devres functions using it
implicitly like devm_kmemdup(), devm_kstrdup() etc.).
Managed realloc'ed chunks can be manually released with devm_kfree().
From: Bartosz Golaszewski
Regular krealloc() obviously can't work with managed memory. This series
implements devm_krealloc() and adds two first users with hope that this
helper will be adopted by other drivers currently using non-managed
krealloc().
v1 -> v2:
- remove leftover call to
From: Bartosz Golaszewski
Shrink pmbus code by using devm_hwmon_device_register_with_groups()
and devm_krealloc() instead of their non-managed variants.
Signed-off-by: Bartosz Golaszewski
Acked-by: Guenter Roeck
---
drivers/hwmon/pmbus/pmbus_core.c | 28 +---
1 file
From: Bartosz Golaszewski
Use the managed variant of krealloc() and shrink the code a bit.
Signed-off-by: Bartosz Golaszewski
Acked-by: Jonathan Cameron
---
drivers/iio/adc/xilinx-xadc-core.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
601 - 700 of 2231 matches
Mail list logo
