On 2/11/21 1:30 PM, Christoph Hellwig wrote:
>> -if (HPAGE_SHIFT > PAGE_SHIFT)
>> +if ((HPAGE_SHIFT > PAGE_SHIFT) && (HUGETLB_PAGE_ORDER < MAX_ORDER))
>
> No need for the braces.
Will drop them.
On 2/11/21 1:31 PM, Christoph Hellwig wrote:
> On Thu, Feb 11, 2021 at 11:52:10AM +0530, Anshuman Khandual wrote:
>> MAX_ORDER which invariably depends on FORCE_MAX_ZONEORDER can be a variable
>> for a given page size, depending on whether TRANSPARENT_HUGEPAGE is enabled
>> or not. In certain
On Fri, Feb 12, 2021 at 12:17 PM Guenter Roeck wrote:
>
> On Fri, Feb 05, 2021 at 11:34:11AM +0800, Kyle Tso wrote:
> > PD Spec Revision 3.0 Version 2.0 + ECNs 2020-12-10
> > 6.4.4.2.3 Structured VDM Version
> > "The Structured VDM Version field of the Discover Identity Command
> > sent and
> I'm actually renaming this as I2C_DRV_ACPI_WAIVE_D0_PROBE, with similar
> changes to the function names. I opportunistically assume the ack holds
> still. :-)
Rightfully so :)
signature.asc
Description: PGP signature
On 2/11/21 1:34 PM, Christoph Hellwig wrote:
> On Thu, Feb 11, 2021 at 11:52:11AM +0530, Anshuman Khandual wrote:
>> Type cast MAX_ORDER as unsigned int to fix the following build warning.
>>
>> In file included from ./include/linux/kernel.h:14,
>> from
On Fri, Feb 12, 2021 at 3:10 PM Kyle Tso wrote:
>
> On Fri, Feb 12, 2021 at 12:17 PM Guenter Roeck wrote:
> >
> > On Fri, Feb 05, 2021 at 11:34:11AM +0800, Kyle Tso wrote:
> > > PD Spec Revision 3.0 Version 2.0 + ECNs 2020-12-10
> > > 6.4.4.2.3 Structured VDM Version
> > > "The Structured
On Fri, Feb 12, 2021 at 12:21 PM Guenter Roeck wrote:
>
> On Fri, Feb 05, 2021 at 11:34:14AM +0800, Kyle Tso wrote:
> > Add bindings of VDO properties of USB PD SVDM so that they can be
> > used in device tree.
> >
> > Signed-off-by: Kyle Tso
>
> Reviewed-by: Guenter Roeck
>
> Would it be
On 2/11/21 10:59 PM, Aneesh Kumar K.V wrote:
> A read syscall do fail with EFAULT. But we allow read via io_uring
> syscalls. Is that ok?
In short, yes.
As much as I'd like to apply pkey permissions to all accesses, when we
don't have the CPU registers around, we don't have a choice: we have to
On Thu, 2021-02-11 at 14:35 +0200, Matti Vaittinen wrote:
> Add DT property parsing code and setting callback for regulator
> over/under
> voltage, over-current and temperature error limits.
>
> Signed-off-by: Matti Vaittinen
> ---
> drivers/regulator/core.c | 122
>
Document the SC7280 SoC and the IDP board bindings
Signed-off-by: Rajendra Nayak
---
Documentation/devicetree/bindings/arm/qcom.yaml | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml
b/Documentation/devicetree/bindings/arm/qcom.yaml
index
Add compatible for SC7280 SoC
Signed-off-by: Rajendra Nayak
---
Documentation/devicetree/bindings/firmware/qcom,scm.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/firmware/qcom,scm.txt
b/Documentation/devicetree/bindings/firmware/qcom,scm.txt
index
Add initial device tree support for the SC7280 SoC and the IDP
boards based on this SoC
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/sc7280-idp.dts | 47 +
arch/arm64/boot/dts/qcom/sc7280.dtsi| 294
This series includes a few minor binding updates and base device tree
files (to boot to shell) for SC7280 SoC and the IDP board using this SoC.
The series is dependent on a few driver patches to merge first, for
gcc, rpmhcc and pinctrl
From: Maulik Shah
Add PDC interrupt controller along with apps RSC device.
Also add reserved memory for command_db.
Signed-off-by: Maulik Shah
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 44
1 file changed, 44 insertions(+)
From: Sai Prakash Ranjan
Add the SoC specific compatible for SC7280 implementing
arm,mmu-500.
Signed-off-by: Sai Prakash Ranjan
Signed-off-by: Rajendra Nayak
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
From: Maulik Shah
Add fw reserved memory area for CPUCP and AOP.
Signed-off-by: Maulik Shah
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
From: satya priya
Add SPMI PMIC arbiter device to communicate with PMICs
attached to SPMI bus.
Signed-off-by: satya priya
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git
From: Sai Prakash Ranjan
Adding device node for APPS SMMU available on SC7280 chipset.
This is shared among the multiple client devices such as
display, video, usb, mmc and others.
Signed-off-by: Sai Prakash Ranjan
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 89
Add rpmhcc clock controller node for SC7280. Also add the 'fixed
clock' nodes which can now be referenced in gcc.
Signed-off-by: Taniya Das
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 55
1 file changed, 55 insertions(+)
diff
Add the compatible string for sc7180 SoC from Qualcomm
Signed-off-by: Rajendra Nayak
---
Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/qcom,pdc.txt
From: Sai Prakash Ranjan
Add APSS (Application Processor Subsystem) watchdog
DT node for SC7280 SoC.
Signed-off-by: Sai Prakash Ranjan
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git
From: Sai Prakash Ranjan
Add compatible for watchdog timer on SC7280 SoC.
Signed-off-by: Sai Prakash Ranjan
Signed-off-by: Rajendra Nayak
---
Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
On Thu, Feb 11, 2021 at 05:27:43PM -0600, Rob Herring wrote:
> This is a couple of cleanups for of_device.h. They fell out from my
> attempt at decoupling of_device.h and of_platform.h which is a mess
> and I haven't finished, but there's no reason to wait on these.
Reviewed-by: Greg
Fix for the below coding style warning.
Warning: Move const after static - use 'static const int'
Signed-off-by: Fatih Yildirim
---
drivers/staging/nvec/nvec_power.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/nvec/nvec_power.c
From: Maulik Shah
Add cpuidle states for little and big cpus.
Signed-off-by: Maulik Shah
Signed-off-by: Rajendra Nayak
---
arch/arm64/boot/dts/qcom/sc7280.dtsi | 78
1 file changed, 78 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi
On 2/11/2021 9:32 PM, Jordan Crouse wrote:
On Thu, Feb 11, 2021 at 06:50:28PM +0530, Akhil P Oommen wrote:
On 2/10/2021 6:22 AM, Jordan Crouse wrote:
Most a6xx targets have security issues that were fixed with new versions
of the microcode(s). Make sure that we are booting with a safe version
Remove the acronym "VDM" and replace it with the full name "Vendor
Defined Message".
Signed-off-by: Kyle Tso
---
.../devicetree/bindings/connector/usb-connector.yaml | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git
On Thu, Feb 11, 2021 at 08:16:15PM -0500, min.li...@renesas.com wrote:
> +static int
> +rsmu_open(struct inode *iptr, struct file *fptr)
> +{
> + struct rsmu_cdev *rsmu;
> +
> + rsmu = container_of(iptr->i_cdev, struct rsmu_cdev, rsmu_cdev);
> + if (!rsmu)
> + return
On Fri, Feb 12, 2021 at 10:16:11AM +0530, Naresh Kamboju wrote:
> On Thu, 11 Feb 2021 at 20:36, Greg Kroah-Hartman
> wrote:
> >
> > This is the start of the stable review cycle for the 4.19.176 release.
> > There are 24 patches in this series, all will be posted as a response
> > to this one. If
Hello.
On Thu, Feb 11, 2021 at 10:43:18AM +, Song Bao Hua (Barry Song) wrote:
> Are you using zsmalloc? There is a known bug on the combination
> of zsmalloc and zswap, fixed by patches of tiantao:
>
> mm: set the sleep_mapped to true for zbud and z3fold
> mm/zswap: fix variable 'entry' is
On Thu, Feb 11, 2021 at 08:16:15PM -0500, min.li...@renesas.com wrote:
> From: Min Li
>
> This driver supports 1588 related functions of ClockMatrix(TM)
> and 82P33xxx families of timing and synchronization devices.
>
> The driver is developed to be only used by Renesas PTP Clock
> Manager for
Cc: Hou Zhiqiang
I found that this patch would cause null pointer dereference exception
when removing the function link.
If once linking the test function to the controller,
# ln -s functions/pci_epf_test/test controllers/6600.pcie-ep/
and unlinking it immediately,
# rm
Am Donnerstag, 11. Februar 2021, 11:29:33 CET schrieb Rolf Eike Beer:
> I'm just guessing, but your build error looks like you are also
> cross-building the tools, which is wrong. You want them to be host-tools.
> So don't export PKG_CONFIG_SYSROOT_DIR, it would then try to link target
>
On Fri, Feb 12, 2021 at 02:19:37PM +0900, Chanwoo Choi wrote:
> Dear Greg,
>
> This is extcon-next pull request for v5.12. I add detailed description of
> this pull request on below. Please pull extcon with following updates.
>
> Changes from v1:
> - Add missing committer information
>
> Best
On Fri, Feb 5, 2021 at 3:01 PM Vinod Koul wrote:
> This adds binding and driver for TLMM block found in SM8350 SoC
>
> The binding is dependent on TLMM common binding from Bjorn:
>
> https://lore.kernel.org/linux-arm-msm/20210126042650.1725176-1-bjorn.anders...@linaro.org
>
> Changes in v6:
>
On Fri, Feb 12, 2021 at 12:44:00PM +0800, Nicolas Boichat wrote:
> Filesystems such as procfs and sysfs generate their content at
> runtime. This implies the file sizes do not usually match the
> amount of data that can be read from the file, and that seeking
> may not work as intended.
>
> This
On Fri, Feb 12, 2021 at 6:47 AM Nicolas Boichat wrote:
>
> Filesystems such as procfs and sysfs generate their content at
> runtime. This implies the file sizes do not usually match the
> amount of data that can be read from the file, and that seeking
> may not work as intended.
>
> This will be
On Fri, Feb 12, 2021 at 12:57:24PM +0800, shuo.a@intel.com wrote:
> From: Shuo Liu
>
> vCPU removing code depends on CONFIG_HOTPLUG_CPU as it uses remove_cpu()
> and add_cpu(). Make the vCPU removing interface building with
> CONFIG_HOTPLUG_CPU.
>
> ../drivers/virt/acrn/hsm.c: In function
This is the start of the stable review cycle for the 4.19.176 release.
There are 27 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sun, 14 Feb 2021 07:42:29 +.
Anything
On Tue, Jan 26, 2021 at 5:26 AM Bjorn Andersson
wrote:
> Several properties are shared between all TLMM bindings. By providing a
> common binding to define these properties each platform's binding can be
> reduced to just listing which of these properties should be checked for
> - or further
On Thu, Feb 11, 2021 at 02:10:48PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Feb 11, 2021 at 05:45:38PM +0100, Jiri Olsa escreveu:
> > On Thu, Feb 11, 2021 at 03:01:12PM +0900, Namhyung Kim wrote:
> > > Hi Jiri,
> > >
> > > On Tue, Feb 9, 2021 at 5:09 AM Jiri Olsa wrote:
> > > > +static
The device mapper may map over devices that have inline encryption
capabilities, and to make use of those capabilities, the DM device must
itself advertise those inline encryption capabilities. One way to do this
would be to have the DM device set up a keyslot manager with a
"sufficiently large"
This patch series adds support for inline encryption to the device mapper.
Patch 1 introduces the "passthrough" keyslot manager.
The regular keyslot manager is designed for inline encryption hardware that
have only a small fixed number of keyslots. A DM device itself does not
actually have only
Introduce blk_ksm_update_capabilities() to update the capabilities of
a keyslot manager (ksm) in-place. The pointer to a ksm in a device's
request queue may not be easily replaced, because upper layers like
the filesystem might access it (e.g. for programming keys/checking
capabilities) at the
Now that device mapper supports inline encryption, add the ability to
evict keys from all underlying devices. When an upper layer requests
a key eviction, we simply iterate through all underlying devices
and evict that key from each device.
Co-developed-by: Eric Biggers
Signed-off-by: Eric
On Thu, Feb 11, 2021 at 01:30:42PM +0100, Michal Hocko wrote:
> On Thu 11-02-21 13:20:08, Mike Rapoport wrote:
> [...]
> > Sealing is anyway controlled via fcntl() and I don't think
> > MFD_ALLOW_SEALING makes much sense for the secretmem because it is there to
> > prevent rogue file sealing in
On Wed, Feb 10, 2021 at 12:17:30PM -0800, Eric Biggers wrote:
> On Mon, Feb 01, 2021 at 05:10:17AM +, Satya Tangirala wrote:
> > Update the device-mapper core to support exposing the inline crypto
> > support of the underlying device(s) through the device-mapper device.
> >
> > This works by
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Thu, 11 Feb 2021 12:48:47 +0200 you wrote:
> From: Stefan Chulski
>
> Armada hardware has a pause generation mechanism in GOP (MAC).
> The GOP generate flow control frames based on an indication programmed in
>
Hi "Guido,
I love your patch! Yet something to improve:
[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v5.11-rc7 next-20210211]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as docum
On Thu, Feb 11 2021 at 6:01pm -0500,
Satya Tangirala wrote:
> On Wed, Feb 10, 2021 at 12:59:59PM -0700, Jens Axboe wrote:
> > On 2/10/21 12:33 PM, Mike Snitzer wrote:
> > > On Mon, Feb 01 2021 at 12:10am -0500,
> > > Satya Tangirala wrote:
> > >
> > >> This patch series adds support for
Hello:
This series was applied to netdev/net-next.git (refs/heads/master):
On Thu, 11 Feb 2021 21:28:20 +0530 you wrote:
> The current admin function (AF) driver and the netdev driver supports
> OcteonTx2 silicon variants. The same OcteonTx2's
> Resource Virtualization Unit (RVU) is carried
Linus Torvalds wrote:
> Also, honestly, I really *REALLY* want your commit messages to talk
> about who has been cc'd, who has been part of development, and point
> to the PUBLIC MAILING LISTS WHERE THAT DISCUSSION WAS TAKING PLACE, so
> that I can actually see that "yes, other people were
f
> generic memory_model.h for !DISCONTIGMEM
> date: 8 weeks ago
> config: m68k-randconfig-r021-20210211 (attached as .config)
> compiler: m68k-linux-gcc (GCC) 9.3.0
> reproduce (this is a W=1 build):
> wget
> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/
zynqmp_pm_get_eemi_ops() was removed in commit 4db8180ffe7c: "Firmware: xilinx:
Remove eemi ops for fpga related APIs", but not in
IS_REACHABLE(CONFIG_ZYNQMP_FIRMWARE).
Any driver who want to communicate with PMC using EEMI APIs use the functions
provided
for each function.
This removed
On Thu, 2021-02-11 at 17:13 -0500, Stefan Berger wrote:
> On 2/11/21 2:54 PM, Nayna Jain wrote:
> > Certificates being loaded onto the IMA trusted keyring must be signed by
> > a key on either the builtin and secondary trusted keyring.
> >
> > This patch creates and includes in the kernel image an
On Wednesday 10 February 2021 16:09:42 kos...@marvell.com wrote:
> From: Grzegorz Jaszczyk
>
> Adding phy description to pcie, sata and usb will allow appropriate drivers
> to configure marvell comphy-a3700 accordingly.
>
> Signed-off-by: Grzegorz Jaszczyk
> Signed-off-by: Konstantin
On Wed, Feb 10, 2021 at 10:23:58PM -0500, Rodrigo Vivi wrote:
> On Tue, Feb 09, 2021 at 04:28:31PM -0500, Lyude Paul wrote:
> > Apparently the new gen9_bc platforms that Intel has introduced don't
> > provide us with a STRAP config register to read from for initializing DDI
> > B, C, and D
On Fri, Feb 12, 2021 at 01:34:31AM +0200, Jarkko Sakkinen wrote:
> On Mon, Jan 25, 2021 at 02:47:38PM +0530, Sumit Garg wrote:
> > Hi Jarkko,
> >
> > On Fri, 22 Jan 2021 at 23:42, Jarkko Sakkinen wrote:
> > >
> > > On Thu, Jan 21, 2021 at 05:23:45PM +0100, Jerome Forissier wrote:
> > > >
> > > >
Verify that user applications are not using the kernel RPC message
handle to restrict them from directly attaching to guest OS on the
remote subsystem. This is a port of CVE-2019-2308 fix.
Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context Invoke method")
Cc: Srinivas Kandagatla
Cc:
On 2/11/21 12:47 PM, Zi Yan wrote:
> On 28 Jan 2021, at 16:53, Mike Kravetz wrote:
>
>> On 1/28/21 10:26 AM, Joao Martins wrote:
>>> For a given hugepage backing a VA, there's a rather ineficient
>>> loop which is solely responsible for storing subpages in GUP
>>> @pages/@vmas array. For each
Hi Sameer
> diff --git a/sound/soc/generic/simple-card-utils.c
> b/sound/soc/generic/simple-card-utils.c
> index bc0b62e..0754d70 100644
> --- a/sound/soc/generic/simple-card-utils.c
> +++ b/sound/soc/generic/simple-card-utils.c
> @@ -173,16 +173,15 @@ int asoc_simple_parse_clk(struct device
On Thursday 11 February 2021 12:22:52 nnet wrote:
> On Thu, Feb 11, 2021, at 11:55 AM, Pali Rohár wrote:
> > On Wednesday 10 February 2021 11:08:59 nnet wrote:
> > > On Wed, Feb 10, 2021, at 10:03 AM, Pali Rohár wrote:
> > > > > > Hello! Could you please enable userspace governor during kernel
> >
Add a new RPROC_ATTACHED state to take into account scenarios
where the remoteproc core needs to attach to a remote processor
that is booted by another entity.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_sysfs.c | 1 +
Move the setting of the resource table installed by an external
entity to rproc_ops::get_loaded_rsc_table(). This is to support
scenarios where a remote processor has been started by the core
but is detached at a later stage. To re-attach the remote
processor, the address of the resource table
From: Arnaud POULIQUEN
Some actions such as memory resources reallocation are needed when
trying to reattach a co-processor. Use the prepare() operation for
these actions.
Co-developed-by: Mathieu Poirier
Signed-off-by: Mathieu Poirier
Signed-off-by: Arnaud POULIQUEN
---
Add an new detach() operation in order to support scenarios where
the remoteproc core is going away but the remote processor is
kept operating. This could be the case when the system is
rebooted or when the platform driver is removed.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Introduce function __rproc_detach() to perform the same kind of
operation as rproc_stop(), but instead of switching off the
remote processor using rproc->ops->stop(), it uses
rproc->ops->detach(). That way it is possible for the core
to release the resources associated with a remote processor
This patch introduces the capability to detach a remote processor
that has been attached to or booted by the remoteproc core. For
that to happen a rproc::ops::detach() operation need to be
available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
The panic handler operation of registered remote processors
should also be called when remote processors have been
attached to.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 6 +-
1 file changed, 5
If it is possible to detach the remote processor, keep an untouched
copy of the resource table. That way we can start from the same
resource table without having to worry about original values or what
elements the startup code has changed when re-attaching to the remote
processor.
Reported-by:
Introduce function rproc_detach() to enable the remoteproc
core to release the resources associated with a remote processor
without stopping its operation.
Signed-off-by: Mathieu Poirier
---
New for V5:
- Fixed comment about rproc_actuate() that no longer exists.
- Added call to
Add a return value to function rproc_shutdown() in order to
properly deal with error conditions that may occur.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_core.c | 19 ++-
include/linux/remoteproc.h
This patch takes into account scenarios where a remote processor
has been attached to when receiving a "start" command from sysfs.
As with the "running" case, the command can't be carried out if the
remote processor is already in operation.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud
This patch introduces the capability to stop a remote processor
that has been attached to by the remoteproc core. For that to
happen a rproc::ops::stop() operation need to be available.
Signed-off-by: Mathieu Poirier
Reviewed-by: Peng Fan
Reviewed-by: Arnaud Pouliquen
---
Refactor function rproc_del() and rproc_cdev_release() to take
into account the policy specified in the device tree.
Signed-off-by: Mathieu Poirier
Reviewed-by: Arnaud Pouliquen
---
drivers/remoteproc/remoteproc_cdev.c | 18 +++---
drivers/remoteproc/remoteproc_core.c | 36
On Wed, Dec 30, 2020 at 11:36:45AM -0600, David Lechner wrote:
> On 12/25/20 6:15 PM, William Breathitt Gray wrote:
>
> > diff --git a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
> > b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
> > index eac32180c40d..0ecba24d43aa 100644
>
On 2/10/21 1:21 PM, Axel Rasmussen wrote:
> From: Peter Xu
>
> It is a preparation work to be able to behave differently in the per
> architecture huge_pte_alloc() according to different VMA attributes.
>
> Pass it deeper into huge_pmd_share() so that we can avoid the find_vma() call.
>
>
On Thursday, February 11, 2021 7:18:26 PM MSK you wrote:
> From: Sven Van Asbroeck
>
> The buffers in the lan743x driver's receive ring are always 9K,
> even when the largest packet that can be received (the mtu) is
> much smaller. This performs particularly badly on cpu archs
> without dma
From: Todd Sabin
Linux network stack uses an allocation page cache for skbs. The
purpose is to reduce the number of page allocations that it needs to
make, and it works by allocating a group of pages, and then
sub-allocating skb memory from them. When all skbs referencing the
shared pages are
On Tue, 9 Feb 2021 10:26:21 + (UTC), Christophe Leroy wrote:
> get_tbl() is confusing as it returns the content TBL register
> on PPC32 but the concatenation of TBL and TBU on PPC64.
>
> Use mftb() instead.
>
> This will allow the removal of get_tbl() in a following patch.
Applied to
On Tue, 9 Feb 2021 19:29:26 + (UTC), Christophe Leroy wrote:
> This series implements C syscall entry/exit for PPC32. It reuses
> the work already done for PPC64.
>
> This series is based on today's next-test (f538b53fd47a) where main patchs
> from v5 are merged in.
>
> The first patch is
On Mon, 8 Feb 2021 07:17:40 + (UTC), Christophe Leroy wrote:
> THREAD_ALIGN_SHIFT = THREAD_SHIFT + 1 = PAGE_SHIFT + 1
> Maximum PAGE_SHIFT is 18 for 256k pages so
> THREAD_ALIGN_SHIFT is 19 at the maximum.
>
> No need to clobber cr1, it can be preserved when moving r1
> into CR when we check
On Tue, 9 Feb 2021 14:02:12 + (UTC), Christophe Leroy wrote:
> Copied from commit 4b842e4e25b1 ("x86: get rid of small
> constant size cases in raw_copy_{to,from}_user()")
>
> Very few call sites where that would be triggered remain, and none
> of those is anywhere near hot enough to bother.
On Mon, 8 Feb 2021 15:10:19 + (UTC), Christophe Leroy wrote:
> This series implements C syscall entry/exit for PPC32. It reuses
> the work already done for PPC64.
>
> This series is based on today's merge-test
> (b6f72fc05389e3fc694bf5a5fa1bbd33f61879e0)
>
> In terms on performance we have
On Sun, 7 Feb 2021 14:43:12 +0800, Jiapeng Chong wrote:
> Fix the following coccicheck warnings:
>
> ./arch/powerpc/kvm/book3s_xive.c:1856:2-17: WARNING: Assignment of 0/1
> to bool variable.
>
> ./arch/powerpc/kvm/book3s_xive.c:1854:2-17: WARNING: Assignment of 0/1
> to bool variable.
Applied
When a CPU offlined and onlined via device_offline() and device_online()
the userspace gets uevent notification. If, after receiving "online" uevent,
userspace executes sched_setaffinity() on some task trying to move it
to a recently onlined CPU, then it often fails with -EINVAL. Userspace needs
Hi,
Thanks for your comment.
On Thu, Feb 11, 2021 at 02:13:07PM -0800, David Miller wrote:
> From: Nobuhiro Iwamatsu
> Date: Thu, 11 Feb 2021 01:29:52 +0900
>
> > +static int visconti_eth_init_hw(struct platform_device *pdev, struct
> > plat_stmmacenet_data *plat_dat)
> > +{
> > + struct
Intercept INVPCID if it's disabled in the guest, even when using NPT,
as KVM needs to inject #UD in this case.
Fixes: 4407a797e941 ("KVM: SVM: Enable INVPCID feature on AMD")
Cc: Babu Moger
Signed-off-by: Sean Christopherson
---
arch/x86/kvm/svm/svm.c | 8
1 file changed, 4
Remove the restriction that prevents VMX from exposing INVPCID to the
guest without PCID also being exposed to the guest. The justification of
the restriction is that INVPCID will #UD if it's disabled in the VMCS.
While that is a true statement, it's also true that RDTSCP will #UD if
it's
Advertise INVPCID by default (if supported by the host kernel) instead
of having both SVM and VMX opt in. INVPCID was opt in when it was a
VMX only feature so that KVM wouldn't prematurely advertise support
if/when it showed up in the kernel on AMD hardware.
Signed-off-by: Sean Christopherson
Fix an INVPCID bug on SVM where it fails to injected a #UD when INVPCID is
supported but not exposed to the guest. Do a bit of cleanup in patch 02
now that both VMX and SVM support PCID/INVPCID.
Patch 03 address KVM behavior that has long confused the heck out of me.
KVM currently allows
On Thu, Feb 11, 2021 at 06:04:59PM -0500, Mike Snitzer wrote:
> On Thu, Feb 11 2021 at 6:01pm -0500,
> Satya Tangirala wrote:
>
> > On Wed, Feb 10, 2021 at 12:59:59PM -0700, Jens Axboe wrote:
> > > On 2/10/21 12:33 PM, Mike Snitzer wrote:
> > > > On Mon, Feb 01 2021 at 12:10am -0500,
> > > >
Hi,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on clk/clk-next]
[also build test ERROR on linus/master v5.11-rc7 next-20210211]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base
Hi David,
You'll find here a couple of misc improvements to watch_queue
documentation and code.
Gabriel Krisman Bertazi (2):
watch_queue: Fold info_id initialization into init_watch
docs: watch_queue: Fix unit of the notification size field
Documentation/watch_queue.rst | 7 ---
Looking at the code and other documentation, the unit of size is
bytes. Previously, the same documentation says bytes.
Signed-off-by: Gabriel Krisman Bertazi
---
Documentation/watch_queue.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/watch_queue.rst
of_dev_get() and of_dev_put are just wrappers for get_device()/put_device()
on a platform_device. There's also already platform_device_{get,put}()
wrappers for this purpose. Let's update the few users and remove
of_dev_{get,put}().
Cc: Michael Ellerman
Cc: Benjamin Herrenschmidt
Cc: Paul
This is a couple of cleanups for of_device.h. They fell out from my
attempt at decoupling of_device.h and of_platform.h which is a mess
and I haven't finished, but there's no reason to wait on these.
Rob
Rob Herring (2):
of: Remove of_dev_{get,put}()
driver core: platform: Drop
On 2/11/21 11:07 AM, Lukasz Luba wrote:
Hi Chanwoo,
On 2/3/21 10:21 AM, Lukasz Luba wrote:
Hi Chanwoo,
Thank you for looking at this.
On 2/3/21 10:11 AM, Chanwoo Choi wrote:
Hi Lukasz,
When accessing the max_freq and min_freq at devfreq-cooling.c,
even if can access 'user_max_freq' and
of_device_node_put() is just a wrapper for of_node_put(). The platform
driver core is already polluted with of_node pointers and the only 'get'
already uses of_node_get() (though typically the get would happen in
of_device_alloc()).
Cc: Greg Kroah-Hartman
Cc: "Rafael J. Wysocki"
Cc: Frank
Excerpts from Segher Boessenkool's message of February 11, 2021 9:50 pm:
> On Thu, Feb 11, 2021 at 08:04:55PM +1000, Nicholas Piggin wrote:
>> It would be nice if we could have a __builtin_trap_if that gcc would use
>> conditional traps with, (and which never assumes following code is
>>
901 - 1000 of 1369 matches
Mail list logo
