There is a need to know when a remote processor has been attached
to rather than booted by the remoteproc core. In order to avoid
manipulating two variables, i.e rproc::autonomous and
rproc::state, get rid of the former and simply use the newly
introduced RPROC_ATTACHED state.
Signed-off-by:
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
---
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
---
drivers/remoteproc/remoteproc_core.c | 19 ++-
include/linux/remoteproc.h | 2 +-
2 files changed,
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
Whether started at probe() time or thereafter from the command
line, a remote processor needs to be shutdown before the final
cleanup phases can happen. Otherwise the system may be left in
an unpredictable state where the remote processor is expecting
the remoteproc core to be providing services
This patch adds a binding to guide the remoteproc core on how to deal with
remote processors in two cases:
1) When an application holding a reference to a remote processor character
device interface crashes.
2) when the platform driver for a remote processor is removed.
In both cases if
On Thu, Nov 26, 2020 at 03:30:01PM -0500, Andrea Arcangeli wrote:
> On Thu, Nov 26, 2020 at 09:44:26PM +0200, Mike Rapoport wrote:
> > TBH, the whole interaction between e820 and memblock keeps me puzzled
> > and I can only make educated guesses why some ranges here are
> > memblock_reserve()'d
Am 2020-11-25 19:52, schrieb Michael Walle:
Am 2020-11-25 13:21, schrieb tudor.amba...@microchip.com:
[..]
diff --git a/drivers/mtd/spi-nor/esmt.c b/drivers/mtd/spi-nor/esmt.c
index c93170008118..c2ebf29d95f2 100644
--- a/drivers/mtd/spi-nor/esmt.c
+++ b/drivers/mtd/spi-nor/esmt.c
@@ -11,9
Hi Christophe,
On 11/24/20 6:53 AM, Christophe Leroy wrote:
>
>
> Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :
>> v2 Changes:
>> - Rename user_landing to vdso_base as it tracks vDSO VMA start address,
>> rather than the explicit address to land (Andy)
>> - Reword and don't use
On Thu, Nov 26, 2020 at 07:24:41PM +0100, Rafael J. Wysocki wrote:
> On Thu, Nov 26, 2020 at 6:25 PM Mel Gorman
> wrote:
> > It was noted that a few workloads that idle rapidly regressed when commit
> > 36fcb4292473 ("cpuidle: use first valid target residency as poll time")
> > was merged. The
On Thu, Nov 26, 2020 at 09:44:26PM +0200, Mike Rapoport wrote:
> TBH, the whole interaction between e820 and memblock keeps me puzzled
> and I can only make educated guesses why some ranges here are
> memblock_reserve()'d and some memblock_add()ed.
The mixed usage in that interaction between
This is considered bad for the following reasons:
(1) We only support the block protection with BPn bits for write
protection. Not all Atmel parts support this.
(2) Newly added flash chip will automatically inherit the "has
locking" support and thus needs to explicitly tested. Better
On Wed, Nov 25, 2020 at 10:43:49AM -0800, mgr...@linux.intel.com wrote:
> From: Seamus Kelly
>
> Refactor the too large IOCTL function to call helper functions.
>
> Cc: Arnd Bergmann
> Cc: Greg Kroah-Hartman
> Reviewed-by: Mark Gross
> Signed-off-by: Seamus Kelly
What are these random
These flashes have some weird BP bits mapping which aren't supported in
the current locking code. Just add a simple unlock op to unprotect the
entire flash array which is needed for legacy behavior.
Signed-off-by: Michael Walle
---
changes since v5
- new patch
drivers/mtd/spi-nor/atmel.c | 53
Traditionally, linux unlocks the whole flash because there are legacy
devices which has the write protections bits set by default at startup.
If you actually want to use the flash protection bits, eg. because there
is a read-only part for a bootloader, this automatic unlocking is
harmful. If there
This is considered bad for the following reasons:
(1) We only support the block protection with BPn bits for write
protection. Not all SST parts support this.
(2) Newly added flash chip will automatically inherit the "has
locking" support and thus needs to explicitly tested. Better
I bundled this as a series, because otherwise there will be conflicts
because the "remove global protection flag" patches modify the same lines
as the main patch.
See invdividual patches for the version history.
Michael Walle (5):
mtd: spi-nor: atmel: remove global protection flag
mtd:
For the Atmel and SST parts this flag was already moved to individual
flash parts because it is considered bad esp. because newer flash chips
will automatically inherit the "has locking" support. While this won't
likely be the case for the Intel parts, we do it for consistency
reasons.
On Thu, 2020-11-26 at 20:42 +0100, Vlastimil Babka wrote:
> On 11/26/20 7:14 PM, Rik van Riel wrote:
> > On Thu, 2020-11-26 at 18:18 +0100, Vlastimil Babka wrote:
> > >
> > This patch makes khugepaged treat the mount options
> > and/or
> > sysfs flag as enabling collapsing of huge pages in case
>
On Wed, Nov 25, 2020 at 2:11 AM Oleksandr Natalenko
wrote:
>
> Hello.
>
> On 25.11.2020 09:32, Greg Kroah-Hartman wrote:
> > On Tue, Nov 24, 2020 at 10:24:27PM +0100, Oleksandr Natalenko wrote:
> >> Hi.
> >>
> >> On 24.11.2020 15:23, Ard Biesheuvel wrote:
> >> > Surely caused by
> >> >
> >> >
On Thu, Nov 26, 2020 at 11:24:59AM -0800, Hugh Dickins wrote:
> On Thu, 26 Nov 2020, Matthew Wilcox wrote:
> > On Wed, Nov 25, 2020 at 04:11:57PM -0800, Hugh Dickins wrote:
> > > > + index =
> > > > truncate_inode_partial_page(mapping,
> > > > +
On Thu, 26 Nov 2020 15:00:17 +0530, Vinod Koul wrote:
> Add PMX55 compatibles for PMIC found in SDX55 platform
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
for-next
Thanks!
[1/2] regulator: dt-bindings: Add PMX55 compatibles
commit:
On Wed, 25 Nov 2020 19:25:47 +0200, Claudiu Beznea wrote:
> Selectors lower than linear_min_sel should not be considered invalid.
> Thus return zero in case _regulator_list_voltage(),
> regulator_list_hardware_vsel() or regulator_list_voltage_table()
> receives such selectors as argument.
Applied
On Wed, 25 Nov 2020 21:01:28 +0800, Bard Liao wrote:
> Explicitly add header files used by regmap SoundWire support.
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[1/1] regmap: sdw: add required header files
commit:
On Wed, 4 Nov 2020 01:22:21 +0800, Bard Liao wrote:
> The MIPI SoundWire Device Class standard will define audio functionality
> beyond the scope of the existing SoundWire 1.2 standard, which is limited
> to the bus and interface.
>
> The description is inspired by the USB Audio Class, with
On Thu, 26 Nov 2020 14:36:48 +0800, Shengjiu Wang wrote:
> HDMI interface can also be used as receiver, this patch is to
> add such support. The most difference compare with TX is that RX
> don't need to get edid information.
Applied to
On Thu, 26 Nov 2020 14:14:53 +0800, Shengjiu Wang wrote:
> CONFIG_ARCH_MXC should be ARCH_MXC
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next
Thanks!
[1/1] ASoC: fsl: Fix config name of CONFIG_ARCH_MXC
commit:
On Wed, 25 Nov 2020 17:44:13 +0100, Krzysztof Kozlowski wrote:
> Changes since v1:
> 1. New patch 2/39: ASoC: bd28623: mark OF related data as maybe unused,
> 2. Patches 1-13: add maybe_unused after discussions with Mark,
> 3. Add Sylwester's review to two patches (one changed so please review
>
On 11/24/20 11:43 PM, Andy Lutomirski wrote:
> On Mon, Nov 23, 2020 at 4:29 PM Dmitry Safonov wrote:
>>
>> Provide current_has_vdso_image_32() helper and check it apriory landing
>> attempt on vdso vma.
>> The helper is a macro, not a static inline funciton to avoid
>> linux/sched/task_stack.h
On 11/24/20 6:22 AM, Christophe Leroy wrote:
>
>
> Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :
>> Not used any more.
>
> But what about mremap() ? Maybe you should explain why you can remove it ?
Yep, it was only to keep track of context->vdso position.
I'll add it to the description.
On 11/26/20 7:14 PM, Rik van Riel wrote:
> On Thu, 2020-11-26 at 18:18 +0100, Vlastimil Babka wrote:
>> On 11/24/20 8:49 PM, Rik van Riel wrote:
>>> Currently if thp enabled=[madvise], mounting a tmpfs filesystem
>>> with huge=always and mmapping files from that tmpfs does not
>>> result in
On 11/24/20 6:13 AM, Christophe Leroy wrote:
>
>
> Le 24/11/2020 à 01:29, Dmitry Safonov a écrit :
>> Now that all users rely on detecting bitness of new-born task checking
>> personality, remove compat_arch_setup_additional_pages() macro,
>> simplifying the code.
>
> I understand from cover
On 11/24/20 6:18 AM, Christophe Leroy wrote:
> "Reuse arch_setup_additional_pages() parameters"
>
> Did you mean "remove" ? Or "Revise" ?
>
> Maybe could be:
>
> "Modify arch_setup_additional_pages() parameters"
Sure.
Thanks,
Dmitry
On Thu, Nov 26, 2020 at 01:29:30PM -0500, Andrea Arcangeli wrote:
> On Thu, Nov 26, 2020 at 11:36:02AM +0200, Mike Rapoport wrote:
> > memory.reserved cannot be calculated automatically. It represents all
> > the memory allocations made before page allocator is up. And as
> > memblock_reserve() is
On 11/24/20 6:12 AM, Christophe Leroy wrote:
[..]
>> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
>> index 6fd7d38a60c8..4221f171d1a9 100644
>> --- a/arch/powerpc/Kconfig
>> +++ b/arch/powerpc/Kconfig
>> @@ -134,6 +134,7 @@ config PPC
>> select ARCH_HAS_PTE_SPECIAL
>>
On Fri, 2020-11-20 at 13:04 -0800, Brian Norris wrote:
> On Fri, Oct 30, 2020 at 1:04 AM Tsuchiya Yuto wrote:
> > On Thu, 2020-10-29 at 11:25 -0700, Brian Norris wrote:
> > > For the record, Chrome OS supports plenty of mwifiex systems with 8897
> > > (SDIO only) and 8997 (PCIe), with PS enabled,
On 11/26/20 10:11 PM, Lad Prabhakar wrote:
> This patch series fixes trivial issues in RPC-IF driver.
>
> Changes for v2:
> * Balanced PM in rpcif_disable_rpm
> * Fixed typo in patch 4/5
> * Dropped C++ style fixes patch
The part that fixed the comment style wasd good, you should\ve kept
On 11/26/20 10:11 PM, Lad Prabhakar wrote:
> rpcif_enable_rpm calls pm_runtime_enable, so rpcif_disable_rpm needs to
> call pm_runtime_disable and not pm_runtime_put_sync.
>
> Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
> Reported-by: Reported-by: Geert Uytterhoeven
Reported
On Thu, 26 Nov 2020, Matthew Wilcox wrote:
> On Wed, Nov 25, 2020 at 04:11:57PM -0800, Hugh Dickins wrote:
> > > + index =
> > > truncate_inode_partial_page(mapping,
> > > + page, lstart, lend);
> > > +
On Thu, Nov 26, 2020 at 11:36:02AM +0200, Mike Rapoport wrote:
> I think it's inveneted by your BIOS vendor :)
BTW, all systems I use on a daily basis have that type 20... Only two
of them are reproducing the VM_BUG_ON on a weekly basis on v5.9.
If you search 'E820 "type 20"' you'll get plenty
The pull request you sent on Thu, 26 Nov 2020 19:57:27 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git pm-5.10-rc6
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/85a2c56cb4454c73f56d3099d96942e7919b292f
Thank you!
--
Deet-doot-dot, I am a
On Thu, Nov 26, 2020 at 11:07 AM Lukas Bulwahn wrote:
>
> On Thu, Nov 26, 2020 at 6:16 PM Andrew Cooper
> wrote:
> >
> > On 26/11/2020 11:54, Lukas Bulwahn wrote:
> > > Commit 1e5de18278e6 ("x86: Introduce GDT_ENTRY_INIT()") unintentionally
> > > transformed a few 0x values to 0xf
In the error path of rpcif_manual_xfer() the value of ret is overwritten
by value returned by reset_control_reset() function and thus returning
incorrect value to the caller.
This patch makes sure the correct value is returned to the caller of
rpcif_manual_xfer() by dropping the overwrite of ret
Quoting from commit 7527810573436f ("Drivers: hv: vmbus: Introduce
the CHANNELMSG_MODIFYCHANNEL message type"),
"[...] Hyper-V can *not* currently ACK CHANNELMSG_MODIFYCHANNEL
messages with the promise that (after the ACK is sent) the
channel won't send any more interrupts to the "old"
Renesas RPC-IF driver is licensed under GPL2.0, to be in sync export the
symbols as GPL.
Suggested-by: Pavel Machek
Signed-off-by: Lad Prabhakar
Reviewed-by: Sergei Shtylyov
---
drivers/memory/renesas-rpc-if.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Release the node reference by calling of_node_put(flash) in the probe.
Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
Reported-by: Pavel Machek
Signed-off-by: Lad Prabhakar
Cc: sta...@vger.kernel.org
Reviewed-by: Sergei Shtylyov
---
drivers/memory/renesas-rpc-if.c | 2 ++
1 file
Define rpcif_enable_rpm() and rpcif_disable_rpm() as static
inline in the header instead of exporting them.
Suggested-by: Pavel Machek
Signed-off-by: Lad Prabhakar
---
drivers/memory/renesas-rpc-if.c | 13 -
include/memory/renesas-rpc-if.h | 13 +++--
2 files changed, 11
rpcif_enable_rpm calls pm_runtime_enable, so rpcif_disable_rpm needs to
call pm_runtime_disable and not pm_runtime_put_sync.
Fixes: ca7d8b980b67f ("memory: add Renesas RPC-IF driver")
Reported-by: Reported-by: Geert Uytterhoeven
Signed-off-by: Lad Prabhakar
Cc: sta...@vger.kernel.org
---
Hi All,
This patch series fixes trivial issues in RPC-IF driver.
Changes for v2:
* Balanced PM in rpcif_disable_rpm
* Fixed typo in patch 4/5
* Dropped C++ style fixes patch
* Included RB tags from Sergei
Cheers,
Prabhakar
Lad Prabhakar (5):
memory: renesas-rpc-if: Return correct value to
On Thu, Nov 26, 2020 at 6:16 PM Andrew Cooper wrote:
>
> On 26/11/2020 11:54, Lukas Bulwahn wrote:
> > Commit 1e5de18278e6 ("x86: Introduce GDT_ENTRY_INIT()") unintentionally
> > transformed a few 0x values to 0xf (note: five times "f" instead of
> > four) as part of the refactoring.
>
>
Acked-by: Xie He
Hi Linus,
Please pull from the tag
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
pm-5.10-rc6
with top-most commit 05b8955f43536c3e1e73edc39639aac9ae32edd8
Merge branch 'cpufreq/arm/fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/vireshk/pm
on top of commit
This commit introduces a new driver, based on the one for cpr v1,
to enable support for the newer Qualcomm Core Power Reduction
hardware, known downstream as CPR3, CPR4 and CPRh.
In these new versions of the hardware, support for various new
features was introduced, including voltage reduction
On new SoCs (SDM845 onwards) the Operating State Manager (OSM) is
being programmed in the bootloader and write-protected by the
hypervisor, leaving to the OS read-only access to some of its
registers (in order to read the Lookup Tables and also some
status registers) and write access to the
e.
Signed-off-by: Lukas Bulwahn
---
applies cleanly on current master and next-20201126
Thomas, Ingo, Boris, please pick this minor non-urgent clean-up patch.
arch/x86/lib/usercopy_32.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/lib/usercopy_32.c b/ar
Convert the qcom-cpufreq-hw documentation to YAML binding as
qcom,cpufreq-hw.yaml.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/cpufreq/cpufreq-qcom-hw.txt | 173 +---
.../bindings/cpufreq/qcom,cpufreq-hw.yaml | 196 ++
2 files changed, 197
Add maintainers entry for the Qualcomm CPR3/CPR4/CPRh driver.
Signed-off-by: AngeloGioacchino Del Regno
---
MAINTAINERS | 6 ++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index c8c006f08dcc..a37c3ae91f2f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14461,6
The CPR driver's common functions were split and put in another
file in order to support newer CPR revisions: to simplify the
commonization, the expected names of the fuses had to be changed
in order for both new and old support to use the same fuse name
retrieval function and keeping the naming
The MSM8998 SoC happens to use the same configuration, for both
clusters, as SDM660 Gold L2: add a compatible for it and point
it to the 660 Gold configuration.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/soc/qcom/spm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
Implement the support for SAW v4.1, used in at least MSM8998,
SDM630, SDM660 and APQ variants and, while at it, also add the
configuration for the SDM630/660 Silver and Gold cluster L2
Adaptive Voltage Scaler: this is also one of the prerequisites
to allow the OSM controller to perform DCVS.
Add the bindings for the CPR3 driver to the documentation.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/soc/qcom/qcom,cpr3.yaml | 226 ++
1 file changed, 226 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,cpr3.yaml
diff
The OSM programming addition has been done under the
qcom,cpufreq-hw-8998 compatible name: specify the requirement
of two additional register spaces for this functionality.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/cpufreq/qcom,cpufreq-hw.yaml | 31 ---
1
In commit a871be6b8eee the SPM driver has been converted to a
generic CPUidle driver: that was mainly made to simplify the
driver and that was a great accomplishment;
Though, it was ignored that the SPM driver is not used only
on the ARM architecture.
In preparation for the enablement of SPM
This patch series is definitely big.
Yup. But it all goes together... here's why:
This series implements full support for CPU scaling on *many* Qualcomm
SoCs and partial support for the others on which the Operating State
Manager is not present.
Since this is a bit tangled, let's go step by step.
Convert the qcom,cpr.txt document to YAML schema and place it in the
appropriate directory, since commit a7305e684fc moves this driver
from power/avs to soc/qcom, but forgets to move the documentation.
Signed-off-by: AngeloGioacchino Del Regno
---
.../bindings/power/avs/qcom,cpr.txt
In preparation for implementing a new driver that will be handling
CPRv3, CPRv4 and CPR-Hardened, format out common functions to a new
file.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/cpr-common.c | 382 +
Add the SDM630, SDM636 and SDM660 to the blacklist since the CPU
scaling is handled out of this.
Signed-off-by: AngeloGioacchino Del Regno
---
drivers/cpufreq/cpufreq-dt-platdev.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
On Tue, Nov 10, 2020 at 08:21:49AM -0800, Yu-cheng Yu wrote:
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index e19df6cde35d..6c21c1e92605 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -598,6 +598,65 @@
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: fa02fcd94b0c8dff6cc65714510cf25ad194b90d
commit: 3744741adab6d9195551ce30e65e726c7a408421 random32: add noise from
network and scheduling activity
date: 5 weeks ago
config: csky-randconfig-r011-20201127
Update the kerneldoc function headers to fix build warnings:
drivers/dma/qcom/qcom_adm.c:180: warning: Function parameter or member 'chan'
not described in 'adm_free_chan'
drivers/dma/qcom/qcom_adm.c:190: warning: Function parameter or member 'burst'
not described in 'adm_get_blksize'
Am 2020-11-26 17:42, schrieb tudor.amba...@microchip.com:
On 11/25/20 8:17 PM, Michael Walle wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know
the content is safe
Am 2020-11-24 20:09, schrieb tudor.amba...@microchip.com:
On 10/3/20 6:32 PM, Michael Walle wrote:
The current Linux kernel only provides a definition of 'spu_create()'.
It has 4 parameters, the last being 'int neighbor_fd'.
Before Linux 2.6.23, there was an older prototype,
which didn't have this last parameter.
Move that old prototype to VERSIONS,
and keep the current one in SYNOPSIS.
Tested-by: Annika Wickert
On 26.11.20, 13:53, "Sven Eckelmann" wrote:
It was observed that sending data via batadv over vxlan (on top of
wireguard) reduced the performance massively compared to raw ethernet or
batadv on raw ethernet. A check of perf data showed that the
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 9a3c425cfdfee169622f1cb1a974b2f287e5560c
Gitweb:
https://git.kernel.org/tip/9a3c425cfdfee169622f1cb1a974b2f287e5560c
Author:Justin Ernst
AuthorDate:Wed, 25 Nov 2020 11:54:41 -06:00
Hi Marc,
On 24/11/20 14:14, Marc Zyngier wrote:
> @@ -680,14 +679,22 @@ int __handle_domain_irq(struct irq_domain *domain,
> unsigned int hwirq,
>* Some hardware gives randomly wrong interrupts. Rather
>* than crashing, do something sensible.
>*/
> - if
On Fri, 2020-11-20 at 12:53 -0800, Brian Norris wrote:
> (Sorry if anything's a bit slow here. I don't really have time to
> write out full proposals myself.)
Don’t worry, I (and other owners) am already glad to hear from upstream
devs, including you :)
(and I'm also sorry for the late reply
On Thu, Nov 26, 2020 at 11:36:02AM +0200, Mike Rapoport wrote:
> memory.reserved cannot be calculated automatically. It represents all
> the memory allocations made before page allocator is up. And as
> memblock_reserve() is the most basic to allocate memory early at boot we
> cannot really delete
On Thu, Nov 26, 2020 at 11:05:14AM +0100, David Hildenbrand wrote:
> On 26.11.20 10:36, Mike Rapoport wrote:
> > On Wed, Nov 25, 2020 at 04:38:16PM -0500, Andrea Arcangeli wrote:
> >
> >> At best memory.reserved should be calculated automatically by the
> >> page_alloc.c based on the
On Thu, 26 Nov 2020 06:52:45 +0100
Greg KH wrote:
> On Tue, Nov 24, 2020 at 10:39:17PM +, J. Avila wrote:
> > Hello,
> >
> > In the ftrace logs we've collected internally, we have found that there are
> > situations where time seems to go backwards; this breaks userspace tools
> > which
>
Le 26/11/2020 à 13:04, Giovanni Cabiddu a écrit :
Hi Christophe,
On Sat, Nov 21, 2020 at 07:13:59AM +, Christophe JAILLET wrote:
'pci_set_dma_mask()' + 'pci_set_consistent_dma_mask()' can be replaced by
an equivalent 'dma_set_mask_and_coherent()' which is much less verbose.
While at it,
On Thu, Nov 26, 2020 at 6:25 PM Mel Gorman wrote:
>
> It was noted that a few workloads that idle rapidly regressed when commit
> 36fcb4292473 ("cpuidle: use first valid target residency as poll time")
> was merged. The workloads in question were heavy communicators that idle
> rapidly and were
On 11/26/2020 7:12 PM, Ard Biesheuvel wrote:
On Thu, 26 Nov 2020 at 17:00, Iuliana Prodan wrote:
On 11/26/2020 9:09 AM, Ard Biesheuvel wrote:
On Wed, 25 Nov 2020 at 22:39, Iuliana Prodan wrote:
On 11/25/2020 11:16 PM, Ard Biesheuvel wrote:
On Wed, 25 Nov 2020 at 22:14, Iuliana Prodan
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 4fc2cf1f2daf8303000efb7c9dc0307ea638a8f3
Gitweb:
https://git.kernel.org/tip/4fc2cf1f2daf8303000efb7c9dc0307ea638a8f3
Author:Justin Ernst
AuthorDate:Wed, 25 Nov 2020 11:54:42 -06:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: caf371103ea17de58251714131b06682d86b0df8
Gitweb:
https://git.kernel.org/tip/caf371103ea17de58251714131b06682d86b0df8
Author:Justin Ernst
AuthorDate:Wed, 25 Nov 2020 11:54:44 -06:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 7ac2f1017115ece5288465da2906ad23b8b07a65
Gitweb:
https://git.kernel.org/tip/7ac2f1017115ece5288465da2906ad23b8b07a65
Author:Justin Ernst
AuthorDate:Wed, 25 Nov 2020 11:54:43 -06:00
The following commit has been merged into the x86/platform branch of tip:
Commit-ID: 8f061abbf543355d77fac5c23521b6b452da6310
Gitweb:
https://git.kernel.org/tip/8f061abbf543355d77fac5c23521b6b452da6310
Author:Justin Ernst
AuthorDate:Wed, 25 Nov 2020 11:54:40 -06:00
Hi Marc,
On 24/11/20 14:14, Marc Zyngier wrote:
> IRQ_HIDDEN was probably the wrong name, so let's rename it to IRQ_IPI,
> which more accurately describe an IPI with special arch code handling.
>
>From the (new) name I would expect this to be set for IRQs requested via
irq_reserve_ipi(), but
On 20-11-26 01:05:56, Jon Masters wrote:
> On 11/11/20 12:43 AM, Ben Widawsky wrote:
>
> > + case CXL_CAPABILITIES_CAP_ID_SECONDARY_MAILBOX:
> > + dev_dbg(>pdev->dev,
> > + "found UNSUPPORTED Secondary Mailbox
> > capability\n");
>
> Per
On Thu, Nov 26, 2020 at 11:05:14AM +0100, David Hildenbrand wrote:
> I agree that this is sub-optimal, as such pages are impossible to detect
> (PageReserved is just not clear as discussed with Andrea). The basic
> question is how we want to proceed:
>
> a) Make sure any online struct page has a
From: "taehyun.cho"
Setup the SuperSpeed Plus descriptors for f_acm. This allows the gadget
to work properly without crashing at SuperSpeed rates.
Cc: Felipe Balbi
Cc: stable
Signed-off-by: taehyun.cho
Signed-off-by: Will McVicker
Signed-off-by: Greg Kroah-Hartman
---
On Thu, Nov 26, 2020 at 06:45:51PM +0100, Krzysztof Kozlowski wrote:
> On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski wrote:
> >
> > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote:
> > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote:
> > > > Each memory client
This series adds audio graph based sound card support for Tegra210
platforms like Jetson-TX1 an Jetson-Nano. The following preparatory
audio graph enhancement series is already merged.
* https://patchwork.kernel.org/project/alsa-devel/list/?series=375629=*
Following are the summary of changes:
On Thu, 2020-11-26 at 18:18 +0100, Vlastimil Babka wrote:
> On 11/24/20 8:49 PM, Rik van Riel wrote:
> > Currently if thp enabled=[madvise], mounting a tmpfs filesystem
> > with huge=always and mmapping files from that tmpfs does not
> > result in khugepaged collapsing those mappings, despite the
Hi Gene,
On 11/26/20 12:37 PM, Gene Chen wrote:
From: Gene Chen
Fix multicolor registration no-ops by return 0
Signed-off-by: Gene Chen
---
include/linux/led-class-multicolor.h | 42 +---
1 file changed, 15 insertions(+), 27 deletions(-)
diff --git
Hi Gene,
Thank you for addressing my remarks.
On 11/26/20 12:37 PM, Gene Chen wrote:
From: Gene Chen
Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH
Signed-off-by: Gene Chen
---
include/linux/led-class-flash.h | 42 -
1 file changed,
In preparation for having to deal with large number of ftrace stubs in
support of ftrace direct calls, convert existing stubs to use a hash
table. The hash table is key'ed off the target address for the stubs
since there could be multiple stubs for the same target to cover the
full kernel text.
On Thu, Nov 26, 2020 at 07:02:32PM +0100, Greg Kroah-Hartman wrote:
> From: Will McVicker
>
> Align the SuperSpeed Plus bitrate for f_rndis to match f_ncm's ncm_bitrate
> defined by commit 1650113888fe ("usb: gadget: f_ncm: add SuperSpeed
> descriptors
> for CDC NCM").
>
> Cc: Felipe Balbi
>
Use SAVE_8GPRS(), REST_8GPRS() and _NIP(), along with using the standard
SWITCH_FRAME_SIZE for the stack frame in ftrace_graph_caller() to
simplify code. This increases the stack frame size, but it is unlikely
to be an issue since ftrace_[regs_]caller() have just used a similar
stack frame size,
From: Borislav Petkov
Fix this build warning on 32-bit:
drivers/staging/media/atomisp/pci/hmm/hmm.c: In function ‘hmm_alloc’:
drivers/staging/media/atomisp/pci/hmm/hmm.c:272:3: warning: format ‘%ld’ \
expects argument of type ‘long int’, but argument 6 has type ‘size_t {aka
unsigned
Add a simple powerpc trampoline to demonstrate use of ftrace direct on
powerpc.
Signed-off-by: Naveen N. Rao
---
samples/Kconfig | 2 +-
samples/ftrace/ftrace-direct-modify.c | 58 +++
samples/ftrace/ftrace-direct-too.c| 48
201 - 300 of 1010 matches
Mail list logo
