On Wed, Nov 21, 2018 at 08:35:28AM +0800, Yang Shi wrote:
>
>
> On 11/20/18 9:42 PM, Kirill A. Shutemov wrote:
> > On Tue, Nov 20, 2018 at 08:10:51PM +0800, Yang Shi wrote:
> > >
> > > On 11/20/18 4:57 PM, Kirill A. Shutemov wrote:
> > > > On Fri, Nov 16, 2018 at 08:56:04AM -0800, Yang Shi wrote
Arnd, Olof,
A simple DT fix that is necessary to get reliable access to the NAND on
sama5d2 based boards.
The following changes since commit 651022382c7f8da46cb4872a545ee1da6d097d2a:
Linux 4.20-rc1 (2018-11-04 15:37:52 -0800)
are available in the Git repository at:
git://git.kernel.org/pub
On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:
> > This suggests that either 0 or N (the latched value) would result from
> > a read from the counter immediately following an interrupt. Who can
> > say which? Just have to try it. The answer should allow us to avoid
> > the risk of a clocksource
Because the task p is always guaranteed to be non-NULL.
Signed-off-by: Yafang Shao
---
arch/x86/kernel/process.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/process.c b/arch/x86/kernel/process.c
index c93fcfd..3c3ee89 100644
--- a/arch/x86/kernel/process.c
Data port used by Amstrad Delta NAND driver is actually an OMAP MPUIO
device, already under control of gpio-omap driver. The NAND driver
gets access to the port by ioremapping it and performs read/write
operations. That is done without any proteciton from other users
legally manipulating the port
Don't readw()/writew() data directly from/to GPIO port which is under
control of gpio-omap driver, use GPIO consumer API instead.
The driver should now work with any 8-bit bidirectional GPIO port, not
only OMAP.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Linus Walleij
---
drivers/mtd/nand/
Data port used by the driver is actually an OMAP MPUIO device, already
under control of gpio-omap driver. For that reason we used to not
request the memory region of the port as that would fail because the
region is already busy. Despite that, we are still accessing the port
by just ioremapping i
Amstrad Delta NAND driver now uses GPIO API for data I/O so there is no
need to assign memory I/O resource to the device any longer. Drop it.
Signed-off-by: Janusz Krzysztofik
---
arch/arm/mach-omap1/board-ams-delta.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/arch/arm/mach
Finalize implementation of the idea suggested by Artem Bityutskiy and
Tony Lindgren, described in commit b027274d2e3a ("mtd: ams-delta: fix
request_mem_region() failure"). Use pure GPIO consumer API, as reqested
by Boris Brezillon.
Janusz Krzysztofik (4):
ARM: OMAP1: ams-delta: Provide GPI
On 20/11/2018 21:40:49+0100, Alexandre Belloni wrote:
> On 20/11/2018 19:01:32+0100, Romain Izard wrote:
> > Le mar. 20 nov. 2018 à 18:16, Alexandre Belloni
> > a écrit :
> > >
> > > Hello Romain,
> > >
> > > On 20/11/2018 17:57:37+0100, Romain Izard wrote:
> > > > The SAMA5D2 is different from SA
On Wed, Nov 21, 2018 at 11:42:06AM +0100, Marek Szyprowski wrote:
> On 2018-11-21 11:13, Charles Keepax wrote:
> Linus, Mark: Similar issue is probably in the other regulator drivers,
> which use enable GPIO allocated by devm_gpio_get*(). This driver is
> simply the first one, which we observed it.
On Wed, Nov 21, 2018 at 11:11:18AM +0500, Victoria Anosova wrote:
> Glad this come to kernel. We've already applied this patch.
The current version, with the bottom half toggling or the original one
with preempt_disable/enable?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid
On Wed, Nov 21, 2018 at 07:45:28AM +, Song Liu wrote:
> Hi,
>
> I found perf-record --tail-synthesize without --overwrite breaks symbols
> for perf-script, perf-report, etc. For example:
>
> [root@]# ~/perf record -ag --tail-synthesize -- sleep 1
> [ perf record: Woken up 1 times to write dat
Add QCOM cpufreq firmware device bindings for Qualcomm Technology Inc's
SoCs. This is required for managing the cpu frequency transitions which are
controlled by the hardware engine.
Signed-off-by: Taniya Das
---
.../bindings/cpufreq/cpufreq-qcom-hw.txt | 172 +
1 f
The CPUfreq HW present in some QCOM chipsets offloads the steps necessary
for changing the frequency of CPUs. The driver implements the cpufreq
driver interface for this hardware engine.
Signed-off-by: Saravana Kannan
Signed-off-by: Taniya Das
---
drivers/cpufreq/Kconfig.arm | 11 ++
dri
[v10]
* Update Documentation binding for cpufreq node.
* Make the driver 'tristate' instead of 'bool' and update code.
* Update the clock name to reflect the hardware name.
* Remove support for varying offset.
[v9]
* Update the Documentation binding for freq-domain-cells & cpufreq node
Hi Charles,
On 2018-11-21 11:13, Charles Keepax wrote:
> The regulator core takes over managing the lifetime of the enable GPIO
> once the regulator is registered. As such we shouldn't register the
> enable GPIO using devm, or it will be freed twice.
>
> Reported-by: Marek Szyprowski
> Signed-off
On Tue, Nov 20, 2018 at 12:38:29PM -0800, Guenter Roeck wrote:
> On Mon, Nov 19, 2018 at 05:28:42PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 3.18.126 release.
> > There are 90 patches in this series, all will be posted as a response
> > to this one.
diff --git a/Makefile b/Makefile
index 4e3179768eea..9382e7e4e750 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 4
-SUBLEVEL = 163
+SUBLEVEL = 164
EXTRAVERSION =
NAME = Blurry Fish Butt
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termi
I'm announcing the release of the 4.9.138 kernel.
All users of the 4.9 kernel series must upgrade.
The updated 4.9.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.9.y
and can be browsed at the normal kernel.org git web browser:
diff --git a/Makefile b/Makefile
index 41fe3014b712..ccf2602f664d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 4
PATCHLEVEL = 9
-SUBLEVEL = 137
+SUBLEVEL = 138
EXTRAVERSION =
NAME = Roaring Lionus
diff --git a/arch/alpha/include/asm/termios.h b/arch/alpha/include/asm/termios
On Tue, 20 Nov 2018 22:36:38 +0100,
Pierre-Louis Bossart wrote:
>
> This patchset is provided as an RFC and should not be merged as is
> (Turkey break in the USA and more validation needed). This is however
> a good time to gather comments. This work is the result of multiple
> email discussions t
I'm announcing the release of the 4.4.164 kernel.
All users of the 4.4 kernel series must upgrade.
The updated 4.4.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.4.y
and can be browsed at the normal kernel.org git web browser:
I'm announcing the release of the 4.14.82 kernel.
All users of the 4.14 kernel series must upgrade.
The updated 4.14.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.14.y
and can be browsed at the normal kernel.org git web browser:
The sdhci_execute_tuning() function has assignment of
private pointers multiple times. Remove the redundant assignment.
Acked-by: Kishon Vijay Abraham I
Signed-off-by: Faiz Abbas
---
drivers/mmc/host/sdhci-omap.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-omap
diff --git a/Makefile b/Makefile
index 2fe1424d61d2..cac5323bc95d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
# SPDX-License-Identifier: GPL-2.0
VERSION = 4
PATCHLEVEL = 14
-SUBLEVEL = 81
+SUBLEVEL = 82
EXTRAVERSION =
NAME = Petit Gorille
diff --git a/arch/alpha/include/asm/termios.
Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
disabled DCRC interrupts during tuning. This write to the interrupt
enable register gets overwritten in sdhci_prepare_data() and the
interrupt is not in fact disabled. Fix this by disabling the interrupt
in the host->ier variable.
The following patches fix tuning related errors in the
sdhci-omap driver.
v2:
Added Fixes and stable tags for patch 1.
Re-enable DCRC in patch 1 only if it was enabled before
Squashed patches 2 & 3
Faiz Abbas (3):
mmc: sdhci-omap: Fix DCRC error handling during tuning
mmc: sdhci-omap: Add pla
The TRM (SPRUIC2C - January 2017 - Revised May 2018 [1]) forbids
assertion of data reset while tuning is happening. Implement a
platform specific callback that takes care of this condition.
[1] http://www.ti.com/lit/pdf/spruic2 Section 25.5.1.2.4
Acked-by: Kishon Vijay Abraham I
Signed-off-by: F
I'm announcing the release of the 4.18.20 kernel.
All users of the 4.18 kernel series must upgrade.
Note, this is the LAST 4.18.y kernel release. 4.18 is now end-of-life,
please move to 4.19.y at this point in time.
The updated 4.18.y git tree can be found at:
git://git.kernel.org/pub/s
I'm announcing the release of the 4.19.3 kernel.
All users of the 4.19 kernel series must upgrade.
The updated 4.19.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
linux-4.19.y
and can be browsed at the normal kernel.org git web browser:
On Wed, Nov 21, 2018 at 11:11 AM, Kyungtae Kim wrote:
> Thank you for your reply.
> But I think this kind of crash can occur in real PC as well, and I'm
> just thinking of some way to stop it in the first place (if possible).
> because malicious users can use this, so as to make the whole system
>
On 21/11/2018 4:55 PM, Daniel Lezcano wrote:
> On 13/11/2018 11:06, Wei Ni wrote:
>> Don't bail when a sensor fails to register with the
>> thermal zone and allow other sensors to register.
>> This allows other sensors to register with thermal
>> framework even if one sensor fails registration.
ies
CONFIG_ARCH_ZYNQ=y)
Patch is against 4.20-rc3 (localversion-next is next-20181121)
---
drivers/clk/zynq/clkc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/zynq/clkc.c b/drivers/clk/zynq/clkc.c
index d7b53ac..014d4a4 100644
--- a/drivers/clk/zynq/clkc.c
++
Vince reported crash in bts flush code when touching the callchain
data, which was supposed to be initialized as an 'early' callchain,
but intel_pmu_drain_bts_buffer does not do that.
BUG: unable to handle kernel NULL pointer dereference at
...
Call Trace:
intel_pmu_d
Moving branch tracing setup to Intel core object into separate
intel_pmu_bts_config function, because it's Intel specific.
Suggested-by: Peter Zijlstra
Signed-off-by: Jiri Olsa
---
arch/x86/events/core.c | 20 --
arch/x86/events/intel/core.c | 41 ++
Currently we check the branch tracing only by checking for the
PERF_COUNT_HW_BRANCH_INSTRUCTIONS event of PERF_TYPE_HARDWARE
type. But we can define the same event with the PERF_TYPE_RAW
type.
Changing the intel_pmu_has_bts code to check on event's final
hw config value, so both HW types are cover
No major change from v3 really, mostly resending to see if there is any
review reaction. It's rebased but a partial test indicated that the
behaviour is similar to the previous baseline
Changelog since v3
o Rebase to 4.20-rc3
o Remove a stupid warning from the last patch
Changelog since v2
o Drop
This is a preparation patch only, no functional change.
Signed-off-by: Mel Gorman
---
include/linux/mmzone.h | 9 +
mm/compaction.c| 2 +-
mm/page_alloc.c| 12 ++--
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/linux/mmzone.h b/include
The page allocator zone lists are iterated based on the watermarks
of each zone which does not take anti-fragmentation into account. On
x86, node 0 may have multiple zones while other nodes have one zone. A
consequence is that tasks running on node 0 may fragment ZONE_NORMAL even
though ZONE_DMA32
An external fragmentation event was previously described as
When the page allocator fragments memory, it records the event using
the mm_page_alloc_extfrag event. If the fallback_order is smaller
than a pageblock order (order-9 on 64-bit x86) then it's considered
an event that will
An event that potentially causes external fragmentation problems has
already been described but there are degrees of severity. A "serious"
event is defined as one that steals a contiguous range of pages of an order
lower than fragment_stall_order (PAGE_ALLOC_COSTLY_ORDER by default). If a
movable
The regulator core takes over managing the lifetime of the enable GPIO
once the regulator is registered. As such we shouldn't register the
enable GPIO using devm, or it will be freed twice.
Reported-by: Marek Szyprowski
Signed-off-by: Charles Keepax
---
Again only build tested.
Thanks,
Charles
On Wed, 2018-11-21 at 15:58 +1100, NeilBrown wrote:
> On Sun, Nov 18 2018, Joe Perches wrote:
>
> > On Sun, 2018-11-18 at 20:28 +0100, Cristian Sicilia wrote:
> > > Some parameters are aligned with parentheses.
> > > Some parentheses are opened at end of line.
> >
> > Given the very long identifi
Thank you for your reply.
But I think this kind of crash can occur in real PC as well, and I'm
just thinking of some way to stop it in the first place (if possible).
because malicious users can use this, so as to make the whole system
(kernel) work incorrectly.
Thanks,
Kyungtae
Add missing insn suffixes and use rmwcc.h just like was (more or less)
recently done for bitops.h as well.
Signed-off-by: Jan Beulich
---
v2: Re-base over rmwcc.h changes.
---
arch/x86/include/asm/sync_bitops.h | 31 +--
1 file changed, 9 insertions(+), 22 deletions
Hi Sugaya,
On 19/11/2018 02:01, Sugaya Taichi wrote:
> Add Milbeaut M10V timer using 32bit timer in peripheral.
Give a better description of the timer as it is new timer introduced.
> Signed-off-by: Sugaya Taichi
> ---
> drivers/clocksource/Kconfig | 8 +++
> drivers/clocksource/Make
On Wed, Nov 21, 2018 at 10:26:30AM +0100, Marek Szyprowski wrote:
> On 2018-11-20 18:25, Marek Szyprowski wrote:
> > On 2018-11-20 18:01, Charles Keepax wrote:
> > [ cut here ]
> > WARNING: CPU: 0 PID: 1 at drivers/gpio/gpiolib.c:2421
> > regulator_ena_gpio_free+0x70/0xa0
>
Hi Finn,
On Wed, Nov 21, 2018 at 10:47 AM Finn Thain wrote:
> On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:
> > The 8520 CIA is almost identical to the 6526 CIA, as used in the C64...
>
> The 6526 CIA datasheet says, "In continuous mode, the timer will count
> from the latched value to zero, gen
On Wed, Nov 21, 2018 at 09:19:36AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
> > > Also; you were going to shop around with the other architectures to see
> > > what they want/need for this interface. I see nothing on that.
> > >
> > I'm open for yo
On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:
> The 8520 CIA is almost identical to the 6526 CIA, as used in the C64...
>
The 6526 CIA datasheet says, "In continuous mode, the timer will count
from the latched value to zero, generate and interrupt, reload the latched
value and repeat the proc
On 21/11/2018 10:16, Andy Tang wrote:
> Hi Daniel,
>
> Thanks for your explanation. The problem is these two trees are not synced
> well.
> Let's take our driver(qoriq_thermal.c) for example.
>
> Git log on Rui's tree next branch:
> 2dfef65 thermal: qoriq: Switch to SPDX identifier
> 1a893a5 the
From: Bartosz Golaszewski
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the
From: Bartosz Golaszewski
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the
Hi Kishon,
On 20/11/18 10:23 AM, Kishon Vijay Abraham I wrote:
> Hi,
>
> On 19/11/18 4:46 PM, Faiz Abbas wrote:
>> Commit 7d33c3581536 ("mmc: sdhci-omap: Workaround for Errata i802")
>> disabled DCRC interrupts during tuning. This write to the interrupt
>> enable register gets overwritten in sdhc
From: Bartosz Golaszewski
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the
From: Bartosz Golaszewski
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO li
From: Bartosz Golaszewski
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.
We now have the option to specify the GPIO base manually for davinc
From: Bartosz Golaszewski
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO li
From: Bartosz Golaszewski
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO li
From: Bartosz Golaszewski
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the network support in legacy boot
mode for da850-evm since we can no longer request the MDIO clock GPIO.
Other boards may be broken too, which I haven't tested.
The proble
From: Bartosz Golaszewski
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO li
From: Bartosz Golaszewski
Commit 587f7a694f01 ("gpio: davinci: Use dev name for label and
automatic base selection") broke the GPIO support on DaVinci boards
in legacy mode by allowing gpiolib to set the GPIO base automatically.
DaVinci board files use the legacy GPIO API with hard-coded GPIO li
From: Bartosz Golaszewski
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the
From: Bartosz Golaszewski
Since commit eb3744a2dd01 ("gpio: davinci: Do not assume continuous
IRQ numbering") the davinci GPIO driver fails to probe if we boot
in legacy mode from any of the board files. Since the driver now
expects every interrupt to be defined as a separate resource, split
the
From: Bartosz Golaszewski
This is the entire set of changes needed to fix the broken GPIO support
for DaVinci boards in legacy mode after certain changes made to the
GPIO driver in 4.19, namely: commits 587f7a694f01 ("gpio: davinci: Use
dev name for label and automatic base selection") and eb3744
Hi Rob
Thank you for your comments.
> -Original Message-
> From: Rob Herring [mailto:robh...@kernel.org]
> Sent: Tuesday, November 20, 2018 1:24 AM
> To: Sugaya, Taichi
> Cc: linux-clk; devicet...@vger.kernel.org; moderated list:ARM/FREESCALE
> IMX / MXC ARM ARCHITECTURE; linux-kernel@vge
On Wed, 2018-11-21 at 08:21 +, Ardelean, Alexandru wrote:
> On Tue, 2018-11-20 at 22:30 +0530, Shreeya Patel wrote:
> > ADT7316 driver no more uses platform data and hence use device tree
> > data instead of platform data for assigning irq_type field.
> > Switch case figures out the type of irq
Hi,
we have on-board ASPEED Graphics card on PCIe.
kernel version: 4.16
I select following drive to enable ast graphics support.
Symbol: DRM_AST [=y]
On Wed, Nov 21, 2018 at 10:31 AM Daniel Vetter wrote:
>
> On Tue, Nov 13, 2018 at 12:52:14AM -0500, Sasha Levin wrote:
> > From: "Lee, Shawn C"
> >
> > [ Upstream commit 922dceff8dc1fb4dafc9af78139ba65671408103 ]
> >
> > BOE panel (ID: 0x0771) that reports "DFP 1.x compliant TMDS".
> > But it's 6
Hi,
On 2018-11-20 18:25, Marek Szyprowski wrote:
> Hi Charles,
>
> On 2018-11-20 18:01, Charles Keepax wrote:
>> We need to manage the life time of the enable GPIO against the regulator
>> device but the OF node lives on the parent MFD device. As such we can't
>> use the devm functions which assum
On 16/11/18 07:41, Rohit kumar wrote:
Add support to configure bit clock for secondary MI2S
TX interface.
Signed-off-by: Rohit kumar
---
sound/soc/qcom/sdm845.c | 18 ++
Acked-by: Srinivas Kandagatla
On 16/11/18 07:41, Rohit kumar wrote:
Change slot_width for quaternary TDM port to 16 and
update bclk rate for TDM and MI2S interfaces
accordingly.
Signed-off-by: Rohit kumar > ---
sound/soc/qcom/sdm845.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
Acked-by: Srinivas
On Wed, 2018-11-21 at 00:07 -0800, Stephen Boyd wrote:
> Quoting Weiyi Lu (2018-11-19 18:37:34)
> > On Tue, 2018-11-13 at 11:31 -0800, Nicolas Boichat wrote:
> > > On Mon, Nov 5, 2018 at 10:42 PM Weiyi Lu wrote:
>
> > > > @@ -226,6 +397,7 @@ static int scpsys_power_on(struct generic_pm_domain
>
Hi Daniel,
Thanks for your explanation. The problem is these two trees are not synced well.
Let's take our driver(qoriq_thermal.c) for example.
Git log on Rui's tree next branch:
2dfef65 thermal: qoriq: Switch to SPDX identifier
1a893a5 thermal: qoriq: Simplify the 'site' variable assignment
f150
On 21/11/18 9:43 AM, Wen Yang wrote:
> This patch fixes a possible null pointer dereference in
> intel_bts_process_auxtrace_info, detected by the semantic patch
> deref_null.cocci, with the following warning:
>
> ./tools/perf/util/intel-bts.c:921:32-49: ERROR: session -> itrace_synth_opts
> is NU
On 21/11/18 9:40 AM, Wen Yang wrote:
> This patch fixes a possible null pointer dereference in
> intel_pt_process_auxtrace_info, detected by the semantic patch
> deref_null.cocci, with the following warning:
>
> ./tools/perf/util/intel-pt.c:2579:32-49: ERROR: session -> itrace_synth_opts
> is NUL
Quoting Bjorn Andersson (2018-11-05 21:50:13)
> As of v4.20-rc1 probing the GCC driver on a SDM845 device with the
> standard security implementation causes an access violation and an
> immediate system restart. Use the protected-clocks property to mark the
> offending clocks protected for the MTP,
Hi Masahiro,
On Wed, 21 Nov 2018 15:59:49 +0900, Masahiro Yamada wrote:
> On Tue, Nov 20, 2018 at 10:40 PM Jean Delvare wrote:
> > Therefore I am asking, can we change "make install" so that it does NOT
> > create a backup copy of an existing kernel?
>
> I think your suggestion makes sense,
>
Quoting Bjorn Andersson (2018-11-05 21:50:13)
> As of v4.20-rc1 probing the GCC driver on a SDM845 device with the
> standard security implementation causes an access violation and an
> immediate system restart. Use the protected-clocks property to mark the
> offending clocks protected for the MTP,
Quoting Stephen Boyd (2018-11-05 11:40:11)
> Certain firmware configurations "protect" clks and cause the entire
> system to reboot when a non-secure OS such as Linux tries to read or
> write protected clk registers. But other firmware configurations allow
> reading or writing the same registers, a
Quoting Stephen Boyd (2018-11-05 11:40:10)
> Add a generic clk property for clks which are not intended to be used by
> the OS due to security restrictions put in place by firmware. For
> example, on some Qualcomm firmwares reading or writing certain clk
> registers causes the entire system to rebo
Hi Finn,
On Wed, Nov 21, 2018 at 9:41 AM Finn Thain wrote:
> On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:
> > On Wed, Nov 21, 2018 at 12:13 AM Finn Thain
> > wrote:
> > > On atari, the 68901 counts down to 0x01 and raises an interrupt. On
> > > mac, the 6522 counts down to 0x then raises
On 13/11/2018 11:06, Wei Ni wrote:
> Don't bail when a sensor fails to register with the
> thermal zone and allow other sensors to register.
> This allows other sensors to register with thermal
> framework even if one sensor fails registration.
I'm not sure if ignoring the error is really safe. Ca
On Wed, Nov 21, 2018 at 4:38 AM Manivannan Sadhasivam
wrote:
> + aliases {
> + serial0 = &uart0;
> + serial1 = &uart1;
> + serial2 = &uart2;
> + };
>
+
> +&uart2 {
> + status = "okay";
> + clocks = <&uart2_clk>;
> +};
This is clear
śr., 21 lis 2018 o 00:07 Sekhar Nori napisał(a):
>
> On 20/11/18 12:08 PM, J, KEERTHY wrote:
> >
> >
> > On 11/20/2018 2:22 AM, Sekhar Nori wrote:
> >> On 13/11/18 7:20 PM, Bartosz Golaszewski wrote:
> >>> From: Bartosz Golaszewski
> >>>
> >>> Since commit eb3744a2dd01 ("gpio: davinci: Do not ass
On 21/11/2018 02:34, Andy Tang wrote:
> Hi all,
>
> Do you have any comments on this patch?
>
> I found for our thermal driver(qoriq_thermal.c) there are different between
> the following two git trees:
> git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git
> branch: next
> git://gi
Quoting Paul Walmsley (2018-11-08 17:01:54)
> On 10/25/18 12:47 AM, Stephen Boyd wrote:
> > Quoting Paul Walmsley (2018-10-20 06:50:22)
> >> diff --git a/drivers/clk/analogbits/wrpll-cln28hpc.c
> >> b/drivers/clk/analogbits/wrpll-cln28hpc.c
> >> new file mode 100644
> >> index ..ebdef8
On 21/11/2018 03:36, Manivannan Sadhasivam wrote:
> Add interrupt driver for RDA Micro RDA8810PL SoC.
>
> Signed-off-by: Andreas Färber
> Signed-off-by: Manivannan Sadhasivam
> ---
> arch/arm/mach-rda/Kconfig | 1 +
> drivers/irqchip/Kconfig| 4 ++
> drivers/irqchip/Makefile
On Wed, 21 Nov 2018, Geert Uytterhoeven wrote:
> Hi Finn,
>
> On Wed, Nov 21, 2018 at 12:13 AM Finn Thain
> wrote:
> > On atari, the 68901 counts down to 0x01 and raises an interrupt. On
> > mac, the 6522 counts down to 0x then raises an interrupt. No idea
> > about amiga (Geert?) -- this
On Wed, Nov 21, 2018 at 09:18:19AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 20, 2018 at 11:40:22PM +0100, Frederic Weisbecker wrote:
> > On Tue, Nov 20, 2018 at 03:23:06PM +0100, Peter Zijlstra wrote:
> > > On Wed, Nov 14, 2018 at 03:46:04AM +0100, Frederic Weisbecker wrote:
> > >
> > > > +void
On 21/11/2018 06:49, Anson Huang wrote:
> Put return value checks of calling imx_init_from_nvmem_cells()
> into one block to save one condition block for normal case.
>
> Signed-off-by: Anson Huang
Reviewed-by: Daniel Lezcano
> ---
> drivers/thermal/imx_thermal.c | 5 +++--
> 1 file changed,
On 21/11/2018 06:49, Anson Huang wrote:
> The thermal driver is a standalone driver for monitoring SoC temperature
> by enabling thermal sensor, so it can be enabled even when CONFIG_CPU_FREQ
> is NOT set. So remove the dependency with CPU_THERMAL.
>
> Introduce dummy function of legacy cooling re
Op wo 21 nov. 2018 om 00:13 schreef Finn Thain :
>
> On Tue, 20 Nov 2018, Kars de Jong wrote:
>
> > Op ma 19 nov. 2018 om 02:10 schreef Finn Thain :
> > >
> > > hp300_gettimeoffset() never checks the timer interrupt flag and will
> > > fail to notice when the timer counter gets reloaded. That means
On Tue, 2018-11-20 at 22:30 +0530, Shreeya Patel wrote:
> ADT7316 driver no more uses platform data and hence use device tree
> data instead of platform data for assigning irq_type field.
> Switch case figures out the type of irq and if it's the default case
> then assign the default value to the i
On Wed, Nov 21, 2018 at 09:39:00AM +0800, Li, Aubrey wrote:
> > Also; you were going to shop around with the other architectures to see
> > what they want/need for this interface. I see nothing on that.
> >
> I'm open for your suggestion, :)
Well, we have linux-arch and the various maintainers ar
On Wed, Nov 21, 2018 at 09:01:26AM +0800, kernel test robot wrote:
>
> #
> # Block modes
> #
> CONFIG_CRYPTO_CBC=y
> # CONFIG_CRYPTO_CFB is not set
Enabling CFB should make your error go away.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.ap
On Tue, Nov 20, 2018 at 11:40:22PM +0100, Frederic Weisbecker wrote:
> On Tue, Nov 20, 2018 at 03:23:06PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 14, 2018 at 03:46:04AM +0100, Frederic Weisbecker wrote:
> >
> > > +void kcpustat_cputime(struct kernel_cpustat *kcpustat, int cpu,
> > > +
On Tue, Nov 20, 2018 at 02:38:54PM -0800, Andi Kleen wrote:
> > In fact, I'll argue FREEZE_ON_OVERFLOW is unfixably broken for
> > independent counters, because while one counter overflows, we'll stall
> > counting on all others until we've handled the PMI.
> >
> > Even though the PMI might not be
From: John Hubbard
Commit df06b37ffe5a4 ("mm/gup: cache dev_pagemap while pinning pages")
attempted to operate on each page that get_user_pages had retrieved. In
order to do that, it created a common exit point from the routine.
However, one case was missed, which this patch fixes up.
Also, ther
801 - 900 of 909 matches
Mail list logo
