Policy notifiers are called before a frequency change and may adjust the
frequency, similar to CPUFREQ_ADJUST. The purpose of policy notifiers is
to support non-thermal throttling of devfreq devices.
As of now notifiers may only select a lower frequency, but not increase it.
The reason for this
GCC considers the number of statements in inlined assembly blocks,
according to new-lines and semicolons, as an indication to the cost of
the block in time and space. This data is distorted by the kernel code,
which puts information in alternative sections. As a result, the
compiler may perform
Dan,
Thanks for the update. Please refer to my comments below.
On 05/15/2018 05:43 PM, Dan Murphy wrote:
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is
Dan,
Thanks for the update. Please refer to my comments below.
On 05/15/2018 05:43 PM, Dan Murphy wrote:
Introduce the family of LED devices that can
drive a torch, strobe or IR LED.
The LED driver can be configured with a strobe
timer to execute a strobe flash. The IR LED
brightness is
+Cc: Rafael
On Wed, May 16, 2018 at 12:18 AM, wrote:
> Seeing this at boot with linux-next 20180415. ACPI gets disabled, hilarity
> and hijinks
> result - everything from a lot of stuff can't find an IRQ to the dual-core w/
> HT CPU
> coming up as just 1 core no HT.
+Cc: Rafael
On Wed, May 16, 2018 at 12:18 AM, wrote:
> Seeing this at boot with linux-next 20180415. ACPI gets disabled, hilarity
> and hijinks
> result - everything from a lot of stuff can't find an IRQ to the dual-core w/
> HT CPU
> coming up as just 1 core no HT. 20180430 works just
On Tue, May 15, 2018 at 02:11:48PM -0700, Joe Perches wrote:
> On Tue, 2018-05-15 at 12:28 -0700, Paul E. McKenney wrote:
> > On Mon, May 14, 2018 at 05:32:05PM -0700, Paul E. McKenney wrote:
> > > On Mon, May 14, 2018 at 05:23:59PM -0700, Joe Perches wrote:
> > > > On Mon, 2018-05-14 at 16:58
On Tue, May 15, 2018 at 02:11:48PM -0700, Joe Perches wrote:
> On Tue, 2018-05-15 at 12:28 -0700, Paul E. McKenney wrote:
> > On Mon, May 14, 2018 at 05:32:05PM -0700, Paul E. McKenney wrote:
> > > On Mon, May 14, 2018 at 05:23:59PM -0700, Joe Perches wrote:
> > > > On Mon, 2018-05-14 at 16:58
On Tue 15 May 2018 at 18:25, Jamal Hadi Salim wrote:
> On 14/05/18 04:46 PM, Vlad Buslov wrote:
>>
>> On Mon 14 May 2018 at 18:03, Jamal Hadi Salim wrote:
>>> On 14/05/18 10:27 AM, Vlad Buslov wrote:
>
>
>> Hello Jamal,
>>
>> I'm trying to run tdc, but
On Tue, May 15, 2018 at 02:45:12PM -0400, Waiman Long wrote:
> On 05/15/2018 02:02 PM, Matthew Wilcox wrote:
> > On Tue, May 15, 2018 at 07:58:05PM +0200, Peter Zijlstra wrote:
> >> On Tue, May 15, 2018 at 01:38:04PM -0400, Waiman Long wrote:
> >>> +/*
> >>> + * Owner value to indicate the rwsem's
On Tue, May 15, 2018 at 02:45:12PM -0400, Waiman Long wrote:
> On 05/15/2018 02:02 PM, Matthew Wilcox wrote:
> > On Tue, May 15, 2018 at 07:58:05PM +0200, Peter Zijlstra wrote:
> >> On Tue, May 15, 2018 at 01:38:04PM -0400, Waiman Long wrote:
> >>> +/*
> >>> + * Owner value to indicate the rwsem's
On Tue 15 May 2018 at 18:25, Jamal Hadi Salim wrote:
> On 14/05/18 04:46 PM, Vlad Buslov wrote:
>>
>> On Mon 14 May 2018 at 18:03, Jamal Hadi Salim wrote:
>>> On 14/05/18 10:27 AM, Vlad Buslov wrote:
>
>
>> Hello Jamal,
>>
>> I'm trying to run tdc, but keep getting following error even on
On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray
wrote:
> Initial patch for JTAG driver
> JTAG class driver provide infrastructure to support hardware/software
> JTAG platform drivers. It provide user layer API interface for flashing
> and debugging external devices
On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray
wrote:
> Initial patch for JTAG driver
> JTAG class driver provide infrastructure to support hardware/software
> JTAG platform drivers. It provide user layer API interface for flashing
> and debugging external devices which equipped with JTAG
On 15.05.2018 16:41, Krzysztof Kozlowski wrote:
> Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
> (with 1024 MB NAND) flavors. Both of them will use the same DTSI
> expecting the bootloader to do the fixup of /memory node. However in
> case it does not happen, let's stay on
On 15.05.2018 16:41, Krzysztof Kozlowski wrote:
> Colibri-T20 can come in 256 MB RAM (with 512 MB NAND) or 512 MB RAM
> (with 1024 MB NAND) flavors. Both of them will use the same DTSI
> expecting the bootloader to do the fixup of /memory node. However in
> case it does not happen, let's stay on
Seeing this at boot with linux-next 20180415. ACPI gets disabled, hilarity and
hijinks
result - everything from a lot of stuff can't find an IRQ to the dual-core w/
HT CPU
coming up as just 1 core no HT. 20180430 works just fine...
[0.00] ACPI: Early table checksum verification
Seeing this at boot with linux-next 20180415. ACPI gets disabled, hilarity and
hijinks
result - everything from a lot of stuff can't find an IRQ to the dual-core w/
HT CPU
coming up as just 1 core no HT. 20180430 works just fine...
[0.00] ACPI: Early table checksum verification
Hi Jiri,
Commit
f82719790751 ("HID: steam: add battery device.")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpTy9qvel1ku.pgp
Description: OpenPGP digital signature
Hi Jiri,
Commit
f82719790751 ("HID: steam: add battery device.")
is missing a Signed-off-by from its author.
--
Cheers,
Stephen Rothwell
pgpTy9qvel1ku.pgp
Description: OpenPGP digital signature
In commit ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on
Qcom chips") you can see a call like:
devm_nvmem_cell_get(dev, NULL);
Note that the cell ID passed to the function is NULL. This is because
the qcom-qusb2 driver is expected to work only on systems where the
PHY node is
Quoting Katsuhiro Suzuki (2018-05-14 19:14:16)
> Add clock for MPEG2 transport stream I/O and demux system (HSC) on
> UniPhier LD11/LD20 SoCs.
>
> Signed-off-by: Katsuhiro Suzuki
> Acked-by: Masahiro Yamada
> ---
Applied to
In commit ca04d9d3e1b1 ("phy: qcom-qusb2: New driver for QUSB2 PHY on
Qcom chips") you can see a call like:
devm_nvmem_cell_get(dev, NULL);
Note that the cell ID passed to the function is NULL. This is because
the qcom-qusb2 driver is expected to work only on systems where the
PHY node is
Quoting Katsuhiro Suzuki (2018-05-14 19:14:16)
> Add clock for MPEG2 transport stream I/O and demux system (HSC) on
> UniPhier LD11/LD20 SoCs.
>
> Signed-off-by: Katsuhiro Suzuki
> Acked-by: Masahiro Yamada
> ---
Applied to clk-next
On Tue, May 15, 2018 at 09:37:05AM -0400, Steven Rostedt wrote:
> On Tue, 15 May 2018 13:06:25 +1000
> "Tobin C. Harding" wrote:
>
> > Currently the function get_random_bytes_arch() has return value 'void'.
> > If the hw RNG fails we currently fall back to using
On Tue, May 15, 2018 at 09:37:05AM -0400, Steven Rostedt wrote:
> On Tue, 15 May 2018 13:06:25 +1000
> "Tobin C. Harding" wrote:
>
> > Currently the function get_random_bytes_arch() has return value 'void'.
> > If the hw RNG fails we currently fall back to using get_random_bytes().
> > This
Hi Dan,
Thanks for the update.
On 05/15/2018 05:43 PM, Dan Murphy wrote:
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan Murphy
---
v6 - Removed multiple led child nodes, fixed example to display micro ranges
Hi Dan,
Thanks for the update.
On 05/15/2018 05:43 PM, Dan Murphy wrote:
Introduce the device tree bindings for the lm3601x
family of LED torch, flash and IR drivers.
Signed-off-by: Dan Murphy
---
v6 - Removed multiple led child nodes, fixed example to display micro ranges
for corresponding
Quoting Agrawal, Akshu (2018-05-15 02:39:08)
>
>
> On 5/15/2018 3:02 PM, Rafael J. Wysocki wrote:
> > On Wednesday, May 9, 2018 11:59:00 AM CEST Akshu Agrawal wrote:
> >> Stoney SoC provides oscout clock. This clock can support 25Mhz and
> >> 48Mhz of frequency.
> >> The clock is available for
Quoting Agrawal, Akshu (2018-05-15 02:39:08)
>
>
> On 5/15/2018 3:02 PM, Rafael J. Wysocki wrote:
> > On Wednesday, May 9, 2018 11:59:00 AM CEST Akshu Agrawal wrote:
> >> Stoney SoC provides oscout clock. This clock can support 25Mhz and
> >> 48Mhz of frequency.
> >> The clock is available for
On Tue, 15 May 2018 13:51:24 -0400 Pavel Tatashin
wrote:
> It is unsafe to do virtual to physical translations before mm_init() is
> called if struct page is needed in order to determine the memory section
> number (see SECTION_IN_PAGE_FLAGS). This is because only in
On Tue, 15 May 2018 13:51:24 -0400 Pavel Tatashin
wrote:
> It is unsafe to do virtual to physical translations before mm_init() is
> called if struct page is needed in order to determine the memory section
> number (see SECTION_IN_PAGE_FLAGS). This is because only in mm_init() we
> initialize
On Tue, 2018-05-15 at 12:28 -0700, Paul E. McKenney wrote:
> On Mon, May 14, 2018 at 05:32:05PM -0700, Paul E. McKenney wrote:
> > On Mon, May 14, 2018 at 05:23:59PM -0700, Joe Perches wrote:
> > > On Mon, 2018-05-14 at 16:58 -0700, Paul E. McKenney wrote:
> > > > OK, so if I define pr_fmt as
On Tue, 2018-05-15 at 12:28 -0700, Paul E. McKenney wrote:
> On Mon, May 14, 2018 at 05:32:05PM -0700, Paul E. McKenney wrote:
> > On Mon, May 14, 2018 at 05:23:59PM -0700, Joe Perches wrote:
> > > On Mon, 2018-05-14 at 16:58 -0700, Paul E. McKenney wrote:
> > > > OK, so if I define pr_fmt as
Quoting Akshu Agrawal (2018-05-09 02:59:00)
> Stoney SoC provides oscout clock. This clock can support 25Mhz and
> 48Mhz of frequency.
> The clock is available for general system use.
>
> Signed-off-by: Akshu Agrawal
> ---
Reviewed-by: Stephen Boyd
Quoting Akshu Agrawal (2018-05-09 02:59:00)
> Stoney SoC provides oscout clock. This clock can support 25Mhz and
> 48Mhz of frequency.
> The clock is available for general system use.
>
> Signed-off-by: Akshu Agrawal
> ---
Reviewed-by: Stephen Boyd
On Tue, May 15, 2018 at 09:47:44AM -0400, Steven Rostedt wrote:
> On Tue, 15 May 2018 13:06:26 +1000
> "Tobin C. Harding" wrote:
>
> > Currently we must wait for enough entropy to become available before
> > hashed pointers can be printed. We can remove this wait by using the
> >
On Tue, May 15, 2018 at 09:47:44AM -0400, Steven Rostedt wrote:
> On Tue, 15 May 2018 13:06:26 +1000
> "Tobin C. Harding" wrote:
>
> > Currently we must wait for enough entropy to become available before
> > hashed pointers can be printed. We can remove this wait by using the
> > hw RNG if
On Tue, May 15, 2018 at 04:00:33PM +0800, kernel test robot wrote:
> [ 11.182501] Code: 00 00 00 eb e6 cc cc cc cc cc cc cc cc cc cc cc cc cc fa
> 8d b6 00 00 00 00 e8 5d e8 8f ff 8b 44 24 34 83 e0 03 83 f8 03 72 28 cc
> cc cc cc cc cc cc fa 8d b6 00 00 00 00 e8 3d e8 8f ff 89 e0
> [
On Tue, May 15, 2018 at 04:00:33PM +0800, kernel test robot wrote:
> [ 11.182501] Code: 00 00 00 eb e6 cc cc cc cc cc cc cc cc cc cc cc cc cc fa
> 8d b6 00 00 00 00 e8 5d e8 8f ff 8b 44 24 34 83 e0 03 83 f8 03 72 28 cc
> cc cc cc cc cc cc fa 8d b6 00 00 00 00 e8 3d e8 8f ff 89 e0
> [
Hello,
On Mon, May 14, 2018 at 10:43:08AM +0200, Thierry Reding wrote:
> On Mon, Mar 26, 2018 at 04:44:14PM +0200, Emil Goode wrote:
> > The compiler is complaining with the following errors:
> >
> > drivers/gpu/host1x/cdma.c:94:48: error:
> > passing argument 3 of ‘dma_alloc_wc’ from
Hello,
On Mon, May 14, 2018 at 10:43:08AM +0200, Thierry Reding wrote:
> On Mon, Mar 26, 2018 at 04:44:14PM +0200, Emil Goode wrote:
> > The compiler is complaining with the following errors:
> >
> > drivers/gpu/host1x/cdma.c:94:48: error:
> > passing argument 3 of ‘dma_alloc_wc’ from
Quoting Wolfram Sang (2018-04-19 07:05:35)
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
Applied to clk-next
Quoting Wolfram Sang (2018-04-19 07:05:35)
> We should get drvdata from struct device directly. Going via
> platform_device is an unneeded step back and forth.
>
> Signed-off-by: Wolfram Sang
> ---
Applied to clk-next
Quoting Sylwester Nawrocki (2018-05-15 02:32:12)
> On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> > We should get drvdata from struct device directly. Going via
> > platform_device is an unneeded step back and forth.
> >
> > Signed-off-by: Wolfram Sang
>
>
Quoting Sylwester Nawrocki (2018-05-15 02:32:12)
> On 04/19/2018 04:05 PM, Wolfram Sang wrote:
> > We should get drvdata from struct device directly. Going via
> > platform_device is an unneeded step back and forth.
> >
> > Signed-off-by: Wolfram Sang
>
> Acked-by: Sylwester Nawrocki
>
> It
On Tue, May 15, 2018 at 11:35 PM, Boris Brezillon
wrote:
> On Tue, 15 May 2018 23:23:02 +0300
> Andy Shevchenko wrote:
> I made a mistake in my code sample, it's
>
> if (srcbuf[i] & BIT(j))
>
> If you look
On Tue, May 15, 2018 at 11:35 PM, Boris Brezillon
wrote:
> On Tue, 15 May 2018 23:23:02 +0300
> Andy Shevchenko wrote:
> I made a mistake in my code sample, it's
>
> if (srcbuf[i] & BIT(j))
>
> If you look at v6, you'll see it's been fixed by Jane.
In this case,
On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray
wrote:
> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
>
> Driver implements the following jtag ops:
> - freq_get;
> - freq_set;
> - status_get;
> - idle;
> - xfer;
>
> It has been tested on
On Tue, May 15, 2018 at 5:21 PM, Oleksandr Shamray
wrote:
> Driver adds support of Aspeed 2500/2400 series SOC JTAG master controller.
>
> Driver implements the following jtag ops:
> - freq_get;
> - freq_set;
> - status_get;
> - idle;
> - xfer;
>
> It has been tested on Mellanox system with BMC
On Mon, May 14, 2018 at 03:56:08PM +, Patrice CHOTARD wrote:
> Hi Arnd, Kevin, Olof
>
> PLease consider this first round of STi dts update for v4.18
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
>Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are
On Mon, May 14, 2018 at 03:56:08PM +, Patrice CHOTARD wrote:
> Hi Arnd, Kevin, Olof
>
> PLease consider this first round of STi dts update for v4.18
>
> The following changes since commit 60cc43fc888428bb2f18f08997432d426a243338:
>
>Linux 4.17-rc1 (2018-04-15 18:24:20 -0700)
>
> are
From: Bjorn Andersson
"start" and "stop" are more suitable names for how these two operations
are used, and they fit better with the upcoming introduction of two
additional operations in the struct.
[el...@linaro.org: minor comment edits]
Signed-off-by: Bjorn
From: Bjorn Andersson
"start" and "stop" are more suitable names for how these two operations
are used, and they fit better with the upcoming introduction of two
additional operations in the struct.
[el...@linaro.org: minor comment edits]
Signed-off-by: Bjorn Andersson
Acked-by: Alex Elder
Rename functions used when subdevices are started and stopped to
reflect the new naming scheme.
Signed-off-by: Alex Elder
---
drivers/remoteproc/qcom_common.c | 16
drivers/remoteproc/remoteproc_core.c | 8
2 files changed, 12 insertions(+), 12
Rename functions used when subdevices are started and stopped to
reflect the new naming scheme.
Signed-off-by: Alex Elder
---
drivers/remoteproc/qcom_common.c | 16
drivers/remoteproc/remoteproc_core.c | 8
2 files changed, 12 insertions(+), 12 deletions(-)
diff
From: Bjorn Andersson
On rare occasions a subdevice might need to prepare some hardware
resources before a remote processor is booted, and clean up some
state after it has been shut down.
One such example is the IP Accelerator found in various Qualcomm
platforms,
From: Bjorn Andersson
On rare occasions a subdevice might need to prepare some hardware
resources before a remote processor is booted, and clean up some
state after it has been shut down.
One such example is the IP Accelerator found in various Qualcomm
platforms, which is accessed directly from
From: Bjorn Andersson
Some subdevices, such as glink ssr only care about the stop operation,
so make the operations optional to reduce client code.
Signed-off-by: Bjorn Andersson
Acked-by: Alex Elder
---
From: Bjorn Andersson
Some subdevices, such as glink ssr only care about the stop operation,
so make the operations optional to reduce client code.
Signed-off-by: Bjorn Andersson
Acked-by: Alex Elder
---
drivers/remoteproc/remoteproc_core.c | 20 +---
1 file changed, 13
From: Bjorn Andersson
In preparation of adding the additional prepare and unprepare operations
make the client responsible for filling out the function pointers of the
rproc_subdev. This makes the arguments to rproc_add_subdev() more
manageable, in particular when
From: Bjorn Andersson
In preparation of adding the additional prepare and unprepare operations
make the client responsible for filling out the function pointers of the
rproc_subdev. This makes the arguments to rproc_add_subdev() more
manageable, in particular when some of the functions are left
This series changes the prototype for rproc_add_subdev(). The
caller is now responsible for populating the function pointers
recorded in the rproc_subdev structure, rather than having them be
passed as arguments. These two existing function pointers have been
renamed ("probe" is now "start" and
This series changes the prototype for rproc_add_subdev(). The
caller is now responsible for populating the function pointers
recorded in the rproc_subdev structure, rather than having them be
passed as arguments. These two existing function pointers have been
renamed ("probe" is now "start" and
> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next
> (next-20180511). Here's a simplified reproducer:
Thanks! That's a fantastic test case.
The issue is a race where rdma_listen() sees invalid state in the
middle of an rdma_bind_addr() call that will ultimately fail.
> Still reproducible on Linus' tree (commit 66e1c94db3cd4e) and on linux-next
> (next-20180511). Here's a simplified reproducer:
Thanks! That's a fantastic test case.
The issue is a race where rdma_listen() sees invalid state in the
middle of an rdma_bind_addr() call that will ultimately fail.
Commit-ID: 5596fe34495cf0f645f417eb928ef224df3e3cb4
Gitweb: https://git.kernel.org/tip/5596fe34495cf0f645f417eb928ef224df3e3cb4
Author: Dexuan Cui
AuthorDate: Tue, 15 May 2018 19:52:50 +
Committer: Thomas Gleixner
CommitDate: Tue, 15 May
Commit-ID: 5596fe34495cf0f645f417eb928ef224df3e3cb4
Gitweb: https://git.kernel.org/tip/5596fe34495cf0f645f417eb928ef224df3e3cb4
Author: Dexuan Cui
AuthorDate: Tue, 15 May 2018 19:52:50 +
Committer: Thomas Gleixner
CommitDate: Tue, 15 May 2018 22:45:54 +0200
tick/broadcast: Use
From: Alexandre Belloni
Date: Mon, 14 May 2018 22:04:53 +0200
> The ocelot dts changes are here for reference and should probably go
> through the MIPS tree once the bindings are accepted.
Ok, series applied to net-next minus patches #5 and #6.
Thank you.
From: Alexandre Belloni
Date: Mon, 14 May 2018 22:04:53 +0200
> The ocelot dts changes are here for reference and should probably go
> through the MIPS tree once the bindings are accepted.
Ok, series applied to net-next minus patches #5 and #6.
Thank you.
On Tue 15-05-18 13:51:24, Pavel Tatashin wrote:
> It is unsafe to do virtual to physical translations before mm_init() is
> called if struct page is needed in order to determine the memory section
> number (see SECTION_IN_PAGE_FLAGS). This is because only in mm_init() we
> initialize struct pages
On Tue 15-05-18 13:51:24, Pavel Tatashin wrote:
> It is unsafe to do virtual to physical translations before mm_init() is
> called if struct page is needed in order to determine the memory section
> number (see SECTION_IN_PAGE_FLAGS). This is because only in mm_init() we
> initialize struct pages
Hi Colin,
On 05/15/18 02:02, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in FAIL message.
>
> Signed-off-by: Colin Ian King
> ---
> scripts/dtc/checks.c | 2 +-
> 1 file changed, 1 insertion(+), 1
Hi Colin,
On 05/15/18 02:02, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in FAIL message.
>
> Signed-off-by: Colin Ian King
> ---
> scripts/dtc/checks.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/scripts/dtc/checks.c
On Mon, May 14, 2018 at 09:58:03AM -0400, Vivek Goyal wrote:
[..]
> Talked to Dan and he mentioned that he was trying to test entrypoint
> failure (and not exec failure) and that's whey he might have allowed exec
> to mounter.
>
> I think that current entrypoint test's expectations are wrong.
>
On Mon, May 14, 2018 at 09:58:03AM -0400, Vivek Goyal wrote:
[..]
> Talked to Dan and he mentioned that he was trying to test entrypoint
> failure (and not exec failure) and that's whey he might have allowed exec
> to mounter.
>
> I think that current entrypoint test's expectations are wrong.
>
Quoting Enric Balletbo i Serra (2018-05-14 14:16:07)
> From: Derek Basehore
>
> This adds the flag to the clk-ddr in rockchip to not use the cached
> rate for get_rate. This is to handle timeout error conditions in SMC
> for the set rate function.
We need some more
Quoting Enric Balletbo i Serra (2018-05-14 14:16:07)
> From: Derek Basehore
>
> This adds the flag to the clk-ddr in rockchip to not use the cached
> rate for get_rate. This is to handle timeout error conditions in SMC
> for the set rate function.
We need some more information here. Why does
Minor fixes detected with "scripts/checkpatch.pl --strict"
Signed-off-by: Philippe Cornu
---
Detected when merging "drm: clarify adjusted_mode documentation for bridges"
include/drm/drm_bridge.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
Minor fixes detected with "scripts/checkpatch.pl --strict"
Signed-off-by: Philippe Cornu
---
Detected when merging "drm: clarify adjusted_mode documentation for bridges"
include/drm/drm_bridge.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git
On Tue 15-05-18 11:59:25, Pavel Tatashin wrote:
> > This will always be a maze as the early boot tends to be. Sad but true.
> > That is why I am not really convinced we should use a large hammer and
> > disallow deferred page initialization just because UP implementation of
> > pcp does something
On Tue 15-05-18 11:59:25, Pavel Tatashin wrote:
> > This will always be a maze as the early boot tends to be. Sad but true.
> > That is why I am not really convinced we should use a large hammer and
> > disallow deferred page initialization just because UP implementation of
> > pcp does something
Quoting Christophe JAILLET (2018-05-13 04:17:04)
> We allocate some memory which is neither used, nor referenced by anything.
> So axe it.
>
> Signed-off-by: Christophe JAILLET
> ---
Applied to clk-next
Quoting Christophe JAILLET (2018-05-13 04:17:04)
> We allocate some memory which is neither used, nor referenced by anything.
> So axe it.
>
> Signed-off-by: Christophe JAILLET
> ---
Applied to clk-next
On Tue, 15 May 2018 23:23:02 +0300
Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 11:03 AM, Boris Brezillon
> wrote:
> > On Tue, 15 May 2018 10:46:00 +0300
> > Andy Shevchenko wrote:
> >
> >> On Tue, May 15,
On Tue, 15 May 2018 23:23:02 +0300
Andy Shevchenko wrote:
> On Tue, May 15, 2018 at 11:03 AM, Boris Brezillon
> wrote:
> > On Tue, 15 May 2018 10:46:00 +0300
> > Andy Shevchenko wrote:
> >
> >> On Tue, May 15, 2018 at 10:35 AM, Boris Brezillon
> >> wrote:
> >> > On Mon, 14 May 2018
Hi Sudeep,
> -Original Message-
> From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
> Sent: Tuesday, May 15, 2018 2:34 AM
> To: Jolly Shah ; ard.biesheu...@linaro.org;
> mi...@kernel.org; gre...@linuxfoundation.org; m...@codeblueprint.co.uk;
> hkallwe...@gmail.com;
Hi Sudeep,
> -Original Message-
> From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
> Sent: Tuesday, May 15, 2018 2:34 AM
> To: Jolly Shah ; ard.biesheu...@linaro.org;
> mi...@kernel.org; gre...@linuxfoundation.org; m...@codeblueprint.co.uk;
> hkallwe...@gmail.com; keesc...@chromium.org;
>
On 05/14/2018 04:01 PM, Jeffrin Jose T wrote:
> Fix for aperf.c to produce the path of the file which is in mention
> during error report.CONFIG_X86_MSR=m support requirement is also mentioned.
>
> Signed-off-by: Jeffrin Jose T
> ---
>
On 05/14/2018 04:01 PM, Jeffrin Jose T wrote:
> Fix for aperf.c to produce the path of the file which is in mention
> during error report.CONFIG_X86_MSR=m support requirement is also mentioned.
>
> Signed-off-by: Jeffrin Jose T
> ---
> tools/testing/selftests/intel_pstate/aperf.c | 4 +++-
> 1
On Tue, May 15, 2018 at 11:03 AM, Boris Brezillon
wrote:
> On Tue, 15 May 2018 10:46:00 +0300
> Andy Shevchenko wrote:
>
>> On Tue, May 15, 2018 at 10:35 AM, Boris Brezillon
>> wrote:
>> > On Mon, 14 May 2018
On Tue, May 15, 2018 at 11:03 AM, Boris Brezillon
wrote:
> On Tue, 15 May 2018 10:46:00 +0300
> Andy Shevchenko wrote:
>
>> On Tue, May 15, 2018 at 10:35 AM, Boris Brezillon
>> wrote:
>> > On Mon, 14 May 2018 20:54:36 +0300
>> > Andy Shevchenko wrote:
>> >> > for (k =
Am Dienstag, 15. Mai 2018, 21:58:01 CEST schrieb David Oberhollenzer:
> On 05/14/2018 01:25 PM, Richard Weinberger wrote:
> > @@ -229,6 +234,12 @@ int ubigen_write_volume(const struct ubigen_info *ui,
> > memset(outbuf + ui->data_offs + len, 0xFF,
> >ui->peb_size -
Am Dienstag, 15. Mai 2018, 21:58:01 CEST schrieb David Oberhollenzer:
> On 05/14/2018 01:25 PM, Richard Weinberger wrote:
> > @@ -229,6 +234,12 @@ int ubigen_write_volume(const struct ubigen_info *ui,
> > memset(outbuf + ui->data_offs + len, 0xFF,
> >ui->peb_size -
On Tue, 15 May 2018, Rick Warner wrote:
> > I've discovered that some new Supermicro skylake systems will hang/stall
> > while booting the 4.15 kernel when extended APIC (x2apic) is enabled in
> > the BIOS. The issue happens on specific CPUs only and follows the CPUs.
> >
> > We had (4) quad
On Tue, 15 May 2018, Rick Warner wrote:
> > I've discovered that some new Supermicro skylake systems will hang/stall
> > while booting the 4.15 kernel when extended APIC (x2apic) is enabled in
> > the BIOS. The issue happens on specific CPUs only and follows the CPUs.
> >
> > We had (4) quad
On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
> When sme enabled on AMD server, we also need to support kdump. Because
> the memory is encrypted in the first kernel, we will remap the old memory
> encrypted to the second kernel(crash kernel), and sme is also enabled in
> the second kernel, otherwise
On 5/14/2018 8:51 PM, Lianbo Jiang wrote:
> When sme enabled on AMD server, we also need to support kdump. Because
> the memory is encrypted in the first kernel, we will remap the old memory
> encrypted to the second kernel(crash kernel), and sme is also enabled in
> the second kernel, otherwise
On Mon, May 14, 2018 at 11:16 PM, Richard Guy Briggs wrote:
> On 2018-05-15 13:06, Stephen Rothwell wrote:
>> Hi Paul,
>>
>> Today's linux-next merge of the audit tree got a conflict in:
>>
>> security/selinux/selinuxfs.c
>>
>> between commit:
>>
>> 4195ed425d3c ("audit:
On Mon, May 14, 2018 at 11:16 PM, Richard Guy Briggs wrote:
> On 2018-05-15 13:06, Stephen Rothwell wrote:
>> Hi Paul,
>>
>> Today's linux-next merge of the audit tree got a conflict in:
>>
>> security/selinux/selinuxfs.c
>>
>> between commit:
>>
>> 4195ed425d3c ("audit: normalize MAC_STATUS
501 - 600 of 2302 matches
Mail list logo