CPUs associated with a pseudo-locked cache region are prevented
from entering C6 and deeper C-states to ensure that the
power savings associated with those C-states cannot impact
the pseudo-locked region by forcing the pseudo-locked memory to
be evicted.
When supporting pseudo-locked regions that
Cache pseudo-locking is a model specific feature and platforms
supporting this feature are added by adding the x86 model data to the
source code after cache pseudo-locking has been validated for the
particular platform.
Indicating support for cache pseudo-locking for an entire platform is
sufficie
Changes since V1:
- Rebase onto v5.3-rc2
Dear Maintainers,
Cache pseudo-locking involves preloading a region of physical memory into a
reserved portion of cache that no task or CPU can subsequently fill into and
from that point on will only serve cache hits. At this time it is only
possible to cr
The properties of a cache pseudo-locked region that are maintained in
its struct pseudo_lock_region include a pointer to the cache domain to
which it belongs. A cache domain is a structure that is associated with
a cache instance and when all CPUs associated with the cache instance go
offline the c
Deterministic cache parameters can be learned from CPUID leaf 04H.
Executing CPUID with a particular index in EAX would return the cache
parameters associated with that index in the EAX, EBX, ECX, and EDX
registers.
At this time, when discovering cache parameters for a particular cache
index, only
On Tue, Jul 30, 2019 at 8:21 PM Stephen Boyd wrote:
> Quoting Andy Shevchenko (2019-07-30 10:17:46)
> > On Tue, Jul 30, 2019 at 8:16 PM Andy Shevchenko
> > wrote:
> > > On Tue, Jul 30, 2019 at 6:36 PM Stephen Boyd wrote:
> > > > Ok. Let me resend just this patch broken up into many pieces.
> >
From: Philippe Schenker
This adds the proper phy-supply to the fec. This supply is actually
switched by a clock that is now properly stated. This adds the
advantage to add a delay for that particular regulator that is needed.
Signed-off-by: Philippe Schenker
---
arch/arm/boot/dts/imx6ull-col
From: Philippe Schenker
This adds the possibility to enable a fixed-regulator with a clock.
Signed-off-by:
Signed-off-by: Philippe Schenker
---
drivers/regulator/core.c | 15 +++
drivers/regulator/fixed.c| 6 ++
include/linux/regulator/driver.h | 3 +++
incl
From: Philippe Schenker
On our Colibri iMX6ULL board there is a circuit for switching the
power supply of the ethernet PHY with the 50MHz RMII clock.
This works quite fine but has one big problem. It is quite slow when
switching the supply, so Linux has to wait there. I think this switch
is at
On Mon, Jul 29 2019 at 14:56 -0600, Stephen Boyd wrote:
Quoting Lina Iyer (2019-07-29 12:01:39)
On Thu, Jul 25 2019 at 09:44 -0600, Doug Anderson wrote:
>On Thu, Jul 25, 2019 at 8:18 AM Lina Iyer wrote:
>>
>> On Wed, Jul 24 2019 at 17:28 -0600, Doug Anderson wrote:
>> >
>> >Jumping in without r
Because of the overlayfs getxattr recursion, the incoming inode fails
to update the selinux sid resulting in avc denials being reported
against a target context of u:object_r:unlabeled:s0.
Solution is to respond to the XATTR_NOSECURITY flag in get xattr
method that calls the __vfs_getxattr handler
Assumption never checked, should fail if the mounter creds are not
sufficient.
Signed-off-by: Mark Salyzyn
Cc: Miklos Szeredi
Cc: Jonathan Corbet
Cc: Vivek Goyal
Cc: Eric W. Biederman
Cc: Amir Goldstein
Cc: Randy Dunlap
Cc: Stephen Smalley
Cc: linux-unio...@vger.kernel.org
Cc: linux-...@vg
From: YueHaibing
Date: Tue, 30 Jul 2019 22:29:59 +0800
> If PHYLIB is not set, build enetc will fails:
>
> drivers/net/ethernet/freescale/enetc/enetc.o: In function `enetc_open':
> enetc.c: undefined reference to `phy_disconnect'
> enetc.c: undefined reference to `phy_start'
> drivers/net/ethern
> On Jul 30, 2019, at 7:59 AM, Kirill A. Shutemov wrote:
>
> On Sun, Jul 28, 2019 at 10:43:34PM -0700, Song Liu wrote:
>> khugepaged needs exclusive mmap_sem to access page table. When it fails
>> to lock mmap_sem, the page will fault in as pte-mapped THP. As the page
>> is already a THP, khug
From: Jose Abreu
Date: Tue, 30 Jul 2019 15:57:16 +0200
> With recent changes that introduced support for Page Pool in stmmac, Jon
> reported that NFS boot was no longer working on an ARM64 based platform
> that had the IP behind an IOMMU.
>
> As Page Pool API does not guarantee DMA syncing becau
On Tue, Jul 30, 2019 at 1:27 AM OGAWA Hirofumi
wrote:
>
> Deepa Dinamani writes:
>
> > diff --git a/fs/fat/misc.c b/fs/fat/misc.c
> > index 1e08bd54c5fb..53bb7c6bf993 100644
> > --- a/fs/fat/misc.c
> > +++ b/fs/fat/misc.c
> > @@ -307,8 +307,9 @@ int fat_truncate_time(struct inode *inode, struct
On 30/07/2019 15:58, Mark Brown wrote:
> On Tue, Jul 30, 2019 at 01:09:36PM +0100, Thomas Preston wrote:
>
>> index ..0f82a88bc1a4
>> --- /dev/null
>> +++ b/sound/soc/codecs/tda7802.c
>> @@ -0,0 +1,509 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +/*
>> + * tda7802.c -- codec driver
Hello,
This small series addresses two suspend-resume bugs: one affects Tegra30+
due to a typo in the code, other fixes CPU hang on Tegra30 specifically.
Changelog:
v2: Reworded comment to the code to make it sound better in the patch
"Use WFE for power-gating on Tegra30".
Dmitry Osipenko (
Turned out that WFI doesn't work reliably on Tegra30 as a trigger for
the power-gating, it causes CPU hang under some circumstances like having
memory controller running of PLLP. The TRM doc states that WFI should be
used for the Big-Little "Cluster Switch", while WFE for the power-gating.
Hence le
There is an unfortunate typo in the code that results in writing to
FLOW_CTLR_HALT instead of FLOW_CTLR_CSR.
Cc:
Acked-by: Peter De Schrijver
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/reset-handler.S | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/ar
On Thu 25-07-19 13:18:19, Qian Cai wrote:
> There are many of those warnings.
>
> In file included from ./arch/powerpc/include/asm/paca.h:15,
> from ./arch/powerpc/include/asm/current.h:13,
> from ./include/linux/thread_info.h:21,
> from ./include
On Wed, Jul 31, 2019 at 1:44 AM Denis Efremov wrote:
>
> On 30.07.2019 19:29, Masahiro Yamada wrote:
> > I prefer this, but why do you need to check type?
> >
> > Doesn't this work?
> >
> > for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
> > unsigned char bind = ELF_ST_BIND
Hello,
On Mon, Jul 29, 2019 at 11:16:45PM +0100, Maciej W. Rozycki wrote:
> On Mon, 29 Jul 2019, Nick Desaulniers wrote:
> > The code in question is modifying a variable declared const through
> > pointer manipulation. Such code is explicitly undefined behavior, and
> > is the lone issue preventi
Quoting Andy Shevchenko (2019-07-30 10:17:46)
> On Tue, Jul 30, 2019 at 8:16 PM Andy Shevchenko
> wrote:
> >
> > On Tue, Jul 30, 2019 at 6:36 PM Stephen Boyd wrote:
> > > Quoting Greg Kroah-Hartman (2019-07-29 23:49:17)
> > > > On Mon, Jul 29, 2019 at 10:38:44PM -0700, Stephen Boyd wrote:
> > > >
From: Colin King
Date: Tue, 30 Jul 2019 12:47:52 +0100
> From: Colin Ian King
>
> Currently are duplicated checks on orig_egr_types which are
> redundant, I believe this is a typo and should actually be
> orig_ing_types || orig_egr_types instead of the expression
> orig_egr_types || orig_egr_ty
On Tue, Jul 30, 2019 at 8:16 PM Andy Shevchenko
wrote:
>
> On Tue, Jul 30, 2019 at 6:36 PM Stephen Boyd wrote:
> > Quoting Greg Kroah-Hartman (2019-07-29 23:49:17)
> > > On Mon, Jul 29, 2019 at 10:38:44PM -0700, Stephen Boyd wrote:
> > > > We don't need dev_err() messages when platform_get_irq()
On Tue, Jul 30, 2019 at 6:36 PM Stephen Boyd wrote:
> Quoting Greg Kroah-Hartman (2019-07-29 23:49:17)
> > On Mon, Jul 29, 2019 at 10:38:44PM -0700, Stephen Boyd wrote:
> > > We don't need dev_err() messages when platform_get_irq() fails now that
> > > platform_get_irq() prints an error message it
> -Original Message-
> From: Keith Busch
> Sent: Tuesday, July 30, 2019 9:42 AM
> To: Rafael J. Wysocki
> Cc: Busch, Keith; Limonciello, Mario; Kai-Heng Feng; Christoph Hellwig; Sagi
> Grimberg; linux-nvme; Linux PM; Linux Kernel Mailing List; Rajat Jain
> Subject: Re: [Regression] Commit
On Tue, 2019-07-30 at 19:11 +0200, Greg KH wrote:
> On Tue, Jul 30, 2019 at 06:49:12PM +0200, Johannes Berg wrote:
> > On Tue, 2019-07-30 at 18:45 +0200, Greg KH wrote:
> >
> > > > I mean, you take patches to devcoredump in general?
> > >
> > > I have no idea, run 'scripts/get_maintainer.pl' to b
On Tue, Jul 30, 2019 at 06:20:00PM +0200, Hubert Feurstein wrote:
> > Please don't re-write this logic. It is written like that for a reason.
> I used the sja1105_ptp.c as a reference. So it is also wrong there.
I'll let that driver's author worry about that.
Thanks,
Richard
On Tue, 30 Jul 2019 at 03:37, Suzuki K Poulose wrote:
>
> We warn the users of obsolete bindings in the DT for coresight replicator
> and funnel drivers. However we use pr_warn_once() which doesn't give a clue
> about which device it is bound to. Let us use dev_warn_once() to give the
> context.
>
On Tue, Jul 30, 2019 at 04:40:32PM +0800, Chuhong Yuan wrote:
> strncpy(dest, src, strlen(src)) leads to unterminated
> dest, which is dangerous.
> Fix it by using strscpy.
>
> Signed-off-by: Chuhong Yuan
> ---
> drivers/gpu/drm/drm_modes.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
On Tue, Jul 30, 2019 at 06:49:12PM +0200, Johannes Berg wrote:
> On Tue, 2019-07-30 at 18:45 +0200, Greg KH wrote:
>
> > > I mean, you take patches to devcoredump in general?
> >
> > I have no idea, run 'scripts/get_maintainer.pl' to be sure :)
>
> That actually points to me :-)
>
> So really I
On 30/07/2019 16.57, Christian Borntraeger wrote:
>
>
> On 30.07.19 12:01, Thomas Huth wrote:
>> To run the dirty_log_test on s390x, we have to make sure that we
>> access the dirty log bitmap with little endian byte ordering and
>> we have to properly align the memslot of the guest.
>> Also all
On Sun, Jul 28, 2019 at 12:58:41AM +0900, Joonwon Kang wrote:
> Before this, there were false negatives in the case where a struct
> contains other structs which contain only function pointers because
> of unreachable code in is_pure_ops_struct().
Ah, very true. Something like:
struct internal {
Hello,
I was spending quite some time recently trying to hunt down CPU-suspend
bug on Tegra30 SoC and in the end it was nailed. During that time I
realized that the CPU Idle drivers could get some polish and gain new
features, thus that's what this series does:
1. Unifies Tegra20/30/114 drivers
The sleep-tegra*.S provides functionality required for suspend/resume
and CPU hotplugging. The new unified CPUIDLE driver will support multiple
hardware generations starting from Terga20 and ending with Tegra124, the
driver will utilize functions that are provided by the assembly and thus
it is cle
Remove the old drivers to replace them cleanly with a new one later on.
Please note that old Tegra20 CPUIDLE driver used pen-locking in order to
block secondary CPU waking-up if IRQ happened to raise during of the
entering into CC6 and primary CPU already crossed point of no return, but
that is unn
The old Tegra30 CPUIDLE driver had intention to check whether primary
CPU was the last CPU that entered LP2 (CC6) idle-state, but that
functionality never got utilized by the old-removed driver because it
never supported the CC6 while secondary CPUs were online. The new driver
will properly support
The new CPUIDLE driver uses the Tegra's CLK API and that driver won't
strictly depend on CONFIG_PM_SLEEP, hence add the required stubs in
order to allow compiling of the new driver with the CONFIG_PM_SLEEP=n.
Signed-off-by: Dmitry Osipenko
---
include/linux/clk/tegra.h | 13 +
1 file
Rename some of the recently exposed PM functions, prefixing them with
"tegra_pm_" and making naming of those functions more meaningful, for
consistency.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/pm.c| 10 +-
arch/arm/mach-tegra/sleep-tegra30.S | 6 +++---
includ
The upcoming unified CPUIDLE driver will be added to the drivers/cpuidle/
directory and it will require all these exposed Tegra PM-core functions.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/irq.c | 2 ++
arch/arm/mach-tegra/pm.h| 3 ---
arch/arm/mach-tegra/sleep.h | 1 -
inc
The cpu_suspend() may fail, it's never good to lose information about
failure because it may become very useful for the caller. The new CPUIDLE
driver will handle all of possible error cases, including the case of
tegra_idle_lp2_last() failure.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-te
The new CPUIDLE driver now is a proper platform driver, hence it needs
a platform device in order to be functional. Register the platform device,
like we do that for the CPUFreq driver. Note that on some Tegra114(124)
devices PSCI may be used for the CPU hotplugging and CPUIDLE driver
doesn't suppo
The new driver is based on the old CPU Idle drivers that are removed now
from arm/arch/mach-tegra/ directory. Those removed drivers were reworked
and squashed into a single unified driver that covers multiple hardware
generations, starting from Tegra20 and ending with Tegra124. The new
driver takes
The Tegra CPU Idle driver was moved out into driver/cpuidle/ directory and
it is now a proper platform driver.
Signed-off-by: Dmitry Osipenko
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
b/arch/arm/configs/multi_
The new CPU Idle driver has all necessary features in order to allow
the deepest idling state on Tegra30 SoC where the whole CPU cluster is
power-gated using the coupled idle state.
Note that outer_disable() now need to be invoked directly since it
produces erroneous warning message about secondar
The Tegra CPU Idle driver was moved out into driver/cpuidle/ directory and
it is now a proper platform driver.
Signed-off-by: Dmitry Osipenko
---
arch/arm/configs/tegra_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconf
This function resembles tegra_cpu_die() of the hotplug code, but
this variant is more suitable to be used for CPU PM because it's made
specifically to be used by cpu_suspend(). In short this function puts
secondary CPU offline, it will be used by the new CPUIDLE driver.
Signed-off-by: Dmitry Osipe
On Mon, Jul 29, 2019 at 08:46:50PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: sparc64):
>
> drivers/watchdog/riowd.c: In function ‘riowd_ioctl’:
> drivers/watchdog/riowd.c:136:3: warning: thi
On Mon, Jul 29, 2019 at 05:31:59PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: arm):
>
> drivers/watchdog/wdt977.c: In function ‘wdt977_ioctl’:
> LD [M] drivers/media/platform/vicodec/vicode
On Wed, Jul 31, 2019 at 12:28:55AM +1000, Michael Ellerman wrote:
> Stephen Rothwell writes:
> > Mark switch cases where we are expecting to fall through.
> >
> > This patch fixes the following warning (Building: powerpc):
> >
> > drivers/macintosh/smu.c: In function 'smu_queue_i2c':
> > drivers/m
On Mon, Jul 29, 2019 at 03:06:02PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: i386):
>
> drivers/watchdog/scx200_wdt.c: In function ‘scx200_wdt_ioctl’:
> drivers/watchdog/scx200_wdt.c:188:3: w
On Tue, Jul 30, 2019 at 11:16:37AM -0500, Segher Boessenkool wrote:
> in_le32 and friends? Yeah, huh. If LLVM copies that to the stack as
> well, its (not byte reversing) read will be atomic just fine, so things
> will still work correctly.
>
> The things defined with DEF_MMIO_IN_D (instead of D
On Tue, Jul 30, 2019 at 10:09:00AM +0200, Uwe Kleine-König wrote:
> Hello Rob and Frank,
>
> Maxime and Jernej on one side and me on the other cannot agree about a
> detail in the change to the bindings here. I'm trying to objectively
> summarize the situation for you to help deciding what is the r
Paolo,
On Tue, Jul 30, 2019 at 10:55:24AM +0200, Paolo Valente wrote:
> Hi Guenter,
> sorry for the delay (Dolomiti's fault).
>
> I didn't consider that rq->elv-icq might have been NULL also
> because of OOM. Thanks for spotting this issue.
>
> As for the other places where the return value of
> On Jul 30, 2019, at 8:01 AM, Kirill A. Shutemov wrote:
>
> On Sun, Jul 28, 2019 at 10:43:35PM -0700, Song Liu wrote:
>> After all uprobes are removed from the huge page (with PTE pgtable), it
>> is possible to collapse the pmd and benefit from THP again. This patch
>> does the collapse by ca
On Mon, Jul 29, 2019 at 02:02:52PM +0530, Anshuman Khandual wrote:
> On 07/27/2019 01:24 AM, Matthew Wilcox wrote:
> > On Fri, Jul 26, 2019 at 10:17:11AM +0530, Anshuman Khandual wrote:
> >>> But 'page' isn't necessarily PMD-aligned. I don't think we can rely on
> >>> architectures doing the right
Hi,
On Tue, Jul 30, 2019 at 1:47 AM Andreas Fenkart wrote:
>
> > * Sometimes while I was testing I saw "Fail WiFi 1" indicating a
> > transitory failure. Usually this was an association failure, but in
> > one case I saw the device do "Firmware wakeup failed" after I
> > triggered the rese
A proper External Memory Controller clock rounding and parent selection
functionality is required by the EMC drivers, it is not available using
the generic clock implementation because only the Memory Controller driver
is aware of what clock rates are actually available for a particular
device. EMC
On 07/29, Song Liu wrote:
>
> This patch allows uprobe to use original page when possible (all uprobes
> on the page are already removed).
Again, the changelog is not 100% accurate. all uprobes removed _and_
the original page is in page cache and uptodate.
Otherwise looks correct...
Oleg.
Now Terga20 and Tegra30 EMC drivers should provide clock-rounding
functionality using the new Tegra-CLK driver API.
Acked-by: Peter De Schrijver
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/tegra20-emc.c | 50 --
1 file changed, 48 insertions(+), 2 deletio
During boot print how many memory timings got the driver and what's the
RAM code. This is a very useful information when something is wrong with
boards memory timing.
Suggested-by: Marc Dietrich
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/tegra20-emc.c | 7 +++
1 file changed, 7
The register polling code was gone, but the included header change was
missed. Fix it up for consistency.
Acked-by: Peter De Schrijver
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/tegra20-emc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/memory/tegra/t
The Tegra30 binding will actually differ from the Tegra124 a tad, in
particular the EMEM configuration description. Hence rename the binding
to Tegra124 during of the conversion to YAML.
Signed-off-by: Dmitry Osipenko
---
.../nvidia,tegra124-mc.yaml | 158 ++
..
On Mon, Jul 29, 2019 at 08:46:50PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: sparc64):
>
> drivers/watchdog/riowd.c: In function ‘riowd_ioctl’:
> drivers/watchdog/riowd.c:136:3: warning: thi
On Mon, Jul 29, 2019 at 07:17:15PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warnings (Building: s390):
>
> drivers/s390/net/ctcm_fsms.c: In function ‘ctcmpc_chx_attnbusy’:
> drivers/s390/net/ctcm_fsms.c:1703:6
The Memory Controller registers definition is sparse and duplicated,
let's consolidate everything into a common place for consistency.
Acked-by: Peter De Schrijver
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/mc.c | 30 ---
drivers/memory/tegra/mc.h | 52 +
Introduce driver for the External Memory Controller (EMC) found on Tegra30
chips, it controls the external DRAM on the board. The purpose of this
driver is to program memory timing for external memory on the EMC clock
rate change.
Acked-by: Peter De Schrijver
Signed-off-by: Dmitry Osipenko
---
Timing control debug features should be disabled at a boot time, but you
never now and hence it's better to disable them explicitly because some of
those features are crucial for the driver to do a proper thing.
Acked-by: Peter De Schrijver
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegr
Add External Memory Controller node to the device-tree.
Acked-by: Peter De Schrijver
Signed-off-by: Dmitry Osipenko
---
arch/arm/boot/dts/tegra30.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index e074258d4518.
Add binding for the NVIDIA Tegra30 SoC Memory Controller.
Signed-off-by: Dmitry Osipenko
---
.../memory-controllers/nvidia,tegra30-mc.yaml | 173 ++
1 file changed, 173 insertions(+)
create mode 100644
Documentation/devicetree/bindings/memory-controllers/nvidia,tegra30-mc.yaml
On Mon, Jul 29, 2019 at 05:52:21PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: arm):
>
> drivers/dma/imx-dma.c: In function ‘imxdma_xfer_desc’:
> drivers/dma/imx-dma.c:542:6: warning: this stat
On Mon, Jul 29, 2019 at 05:45:19PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: arm):
>
> drivers/hsi/clients/ssi_protocol.c: In function ‘ssip_set_rxstate’:
> drivers/hsi/clients/ssi_protocol.c
Add device-tree binding for NVIDIA Tegra30 External Memory Controller.
The binding is based on the Tegra124 EMC binding since hardware is
similar, although there are couple significant differences.
Note that the memory timing description is given in a platform-specific
form because there is no det
Turned out that it could take over a millisecond under some circumstances,
like running on a very low CPU/memory frequency. TRM says that handshake
happens when there is a "safe" moment, but not explains exactly what that
moment is. Apparently at least memory should be idling and thus the low
frequ
Hello,
This series introduces driver for the External Memory Controller (EMC)
found on Tegra30 chips, it controls the external DRAM on the board. The
purpose of this driver is to program memory timing for external memory on
the EMC clock rate change. The driver was tested using the ACTMON devfreq
The "interruptible" variant may error out, the "uninterruptible" not.
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/tegra20-emc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/memory/tegra/tegra20-emc.c
b/drivers/memory/tegra/tegra20-emc.c
index da75
The driver expects certain debug features to be disabled in order to
work properly. Let's disable them explicitly for consistency and to not
rely on a boot state.
Acked-by: Peter De Schrijver
Signed-off-by: Dmitry Osipenko
---
drivers/memory/tegra/tegra20-emc.c | 17 -
1 file ch
The memory frequency scaling will be managed by tegra20-devfreq driver
and PM QoS once all the prerequisite patches will get upstreamed.
The parent clock is now managed by the clock driver and we also should
assume that PLLM rate can't be changed on some devices (Galaxy Tab 10.1
for example). Altog
On Mon, Jul 29, 2019 at 05:31:59PM -0500, Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: arm):
>
> drivers/watchdog/wdt977.c: In function ‘wdt977_ioctl’:
> LD [M] drivers/media/platform/vicodec/vicode
From: Hubert Feurstein
Date: Tue, 30 Jul 2019 12:11:42 +0200
> Using the define here makes the code more expressive.
>
> Signed-off-by: Hubert Feurstein
Applied, thank you.
From: Hubert Feurstein
Date: Tue, 30 Jul 2019 11:46:23 +0200
> It is perfectly ok to not have an gpio attached to the fixed-link node. So
> the driver should not throw an error message when the gpio is missing.
>
> Signed-off-by: Hubert Feurstein
Applied and queued up for -stable, thanks.
On 07/29, Adrian Reber wrote:
>
> @@ -186,12 +187,26 @@ struct pid *alloc_pid(struct pid_namespace *ns)
> if (idr_get_cursor(&tmp->idr) > RESERVED_PIDS)
> pid_min = RESERVED_PIDS;
>
> + if (set_tid) {
> + if ((set_tid >= pid_max)
From: David Miller
Date: Tue, 30 Jul 2019 09:44:36 -0700 (PDT)
> From: Claudiu Manoil
> Date: Tue, 30 Jul 2019 12:45:15 +0300
>
>> First patch fixes a sparse issue and cleans up accessors to avoid
>> casting to __iomem.
>> Second patch just registers the PCIe endpoint device containing
>> the M
On Wed, Jul 31, 2019 at 1:50 AM Nathan Chancellor
wrote:
>
> On Tue, Jul 30, 2019 at 09:48:03AM -0700, Stephen Boyd wrote:
> > If the particular version of clang a user has doesn't enable
> > -Werror=unknown-warning-option by default, even though it is the
> > default[1], then make sure to pass th
Jia-Ju,
> In qla2x00_alloc_fcport(), fcport is assigned to NULL in the error
> handling code on line 4880:
> fcport = NULL;
Applied to 5.3/scsi-fixes. Thanks!
--
Martin K. Petersen Oracle Linux Engineering
On Tue, Jul 30, 2019 at 09:48:03AM -0700, Stephen Boyd wrote:
> If the particular version of clang a user has doesn't enable
> -Werror=unknown-warning-option by default, even though it is the
> default[1], then make sure to pass the option to the Kconfig cc-option
> command so that testing options
On Tue, 2019-07-30 at 18:45 +0200, Greg KH wrote:
> > I mean, you take patches to devcoredump in general?
>
> I have no idea, run 'scripts/get_maintainer.pl' to be sure :)
That actually points to me :-)
So really I guess the question is how I should send these upstream? It's
to drivers/base/dev
If the particular version of clang a user has doesn't enable
-Werror=unknown-warning-option by default, even though it is the
default[1], then make sure to pass the option to the Kconfig cc-option
command so that testing options from Kconfig files works properly.
Otherwise, depending on the default
On Mon, Jul 29, 2019 at 6:16 PM Masahiro Yamada
wrote:
>
> CLANG_FLAGS is initialized by the following line:
>
> CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%))
>
> ..., which is run only when CROSS_COMPILE is set.
>
> Some build targets (bindeb-pkg etc.) recurse to the top Makefile.
On Sat, Jul 27, 2019 at 11:21:22AM +0800, Muchun Song wrote:
> There is a race condition between removing glue directory and adding a new
> device under the glue dir. It can be reproduced in following test:
>
> CPU1: CPU2:
>
> device_add()
> get_device_pa
On Tue, Jul 30, 2019 at 06:37:56PM +0200, Johannes Berg wrote:
> On Tue, 2019-07-30 at 18:23 +0200, Greg KH wrote:
> > On Sat, Jul 27, 2019 at 08:43:21PM +0200, Johannes Berg wrote:
> > > On Sun, 2019-07-28 at 00:59 +0900, Akinobu Mita wrote:
> > > > s/dev_coredumpmsg/dev_coredumpsg/
> > >
> > > O
Hello,
Zhou Yanjie wrote:
> Add X1000 system type for cat /proc/cpuinfo to give out X1000.
>
> Signed-off-by: Zhou Yanjie
Applied to mips-next.
Thanks,
Paul
[ This message was auto-generated; if you believe anything is incorrect
then please email paul.bur...@mips.com to report it. ]
Hello,
Fabian Mewes wrote:
> HAVE_LATENCYTOP_SUPPORT was removed all together in da48d094ce5d7
> ("Kconfig: remove HAVE_LATENCYTOP_SUPPORT"). This commit removes
> a leftover in the MIPS Kconfig.
>
> Signed-off-by: Fabian Mewes
Applied to mips-next.
Thanks,
Paul
[ This message was auto-ge
On 30.07.2019 19:29, Masahiro Yamada wrote:
I prefer this, but why do you need to check type?
Doesn't this work?
for (sym = info.symtab_start; sym < info.symtab_stop; sym++) {
unsigned char bind = ELF_ST_BIND(sym->st_info);
struct symbol *s = find_symbol(remove_dot(info.strta
From: Claudiu Manoil
Date: Tue, 30 Jul 2019 12:45:15 +0300
> First patch fixes a sparse issue and cleans up accessors to avoid
> casting to __iomem.
> Second patch just registers the PCIe endpoint device containing
> the MDIO registers as a standalone MDIO bus driver, to allow
> an alternative wa
Hello,
Gustavo A. R. Silva wrote:
> Mark switch cases where we are expecting to fall through.
>
> This patch fixes the following warning (Building: mips):
>
> arch/mips/oprofile/op_model_mipsxx.c: In function ‘mipsxx_cpu_stop’:
> arch/mips/oprofile/op_model_mipsxx.c:217:3: warning: this statemen
On 7/30/19 11:23 AM, Saravana Kannan wrote:
On Mon, Jul 29, 2019 at 10:28 PM Sibi Sankar wrote:
Hey Viresh,
On 7/30/19 8:16 AM, Viresh Kumar wrote:
On 29-07-19, 13:16, Saravana Kannan wrote:
Sibi might be working on doing that for the SDM845 CPUfreq driver.
Georgi could also change his GPU
On Mon, Jul 29, 2019 at 03:32:38PM -0700, Paul E. McKenney wrote:
> On Wed, Jul 24, 2019 at 06:12:43PM -0700, Paul E. McKenney wrote:
>
> The patch below (which includes your patch) does help considerably.
> However, it does have some shortcomings:
>
> 1.Adds an atomic operation (albeit a cac
601 - 700 of 1300 matches
Mail list logo
