On Tue, Oct 13, 2015 at 11:32:31AM +0800, Liao Tonglang wrote:
> Cleanup for checkpatch.pl warn below:
> CHECK: Alignment should match open parenthesis
> #836: FILE: drivers/staging/android/ashmem.c:836:
> by split three lines to four.
>
> Signed-off-by: Liao Tonglang
> ---
>
On 12-10-15 14:38, Michal Simek wrote:
Hi Mike,
On 10/12/2015 02:22 PM, Mike Looijmans wrote:
On 12-10-15 13:16, Michal Simek wrote:
+static int zynq_fpga_ops_write(struct fpga_manager *mgr,
+const char *buf, size_t count)
+{
+ struct zynq_fpga_priv *priv;
+
Of this, secure content (including PPA) uses initial
portion of the SRAM. This chunk is not (and shouldn't
be) accessible from the public code.
The minimum size of this chunk (0x350) is used in this
patch. Available size is rounded off to 63K.
Both values would require a change if size of secure
On Tue, Oct 13, 2015 at 11:38:38AM +0900, Minchan Kim wrote:
> Use is_zero_pfn on pteval only after pte_present check on pteval
> (It might be better idea to introduce is_zero_pte where checks
> pte_present first). Otherwise, it could work with swap or
> migration entry and if pte_pfn's result is
On Sat, Oct 10, 2015 at 03:41:54PM +0300, Stanislav Kholmanskikh wrote:
> The config option in the subject may be removed, because,
> indeed, it only serves as the 'n' value for
> CONFIG_WILC1000_PREALLOCATE_AT_LOADING_DRIVER
>
> Signed-off-by: Stanislav Kholmanskikh
> ---
>
On 10/12/2015 05:10 PM, Arnd Bergmann wrote:
> The advansys drvier uses the request_dma function that is used on ISA
> machines for the internal DMA controller, which causes build errors
> on platforms that have ISA slots but do not provide the ISA DMA API:
>
> drivers/scsi/advansys.c: In
On 12 October 2015 18:59:57 BST, Daniel Baluta wrote:
>
>
>>> +static unsigned instances = 1;
>>> +module_param(instances, uint, 0);
>
>One concern about this. We will still create a default number of
>'instances'
>when using configuration via configfs?
>
>I'm not sure we can remove this
On Mon, Oct 12, 2015 at 10:06 PM, Meelis Roos wrote:
>> >> > sparc64 machines:
>> >>
>> >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
>> >> for-pci-v4.4-next
>> >>
>> >> It should fix some "no compatible bridge window"
>> >
>> > Blade 100: still has 2 address
On Sat, Oct 10, 2015 at 01:27:00PM +0700, Ivan Safonov wrote:
> Correct channels range is 1..14 (numbering from 1) but not 0..13.
Why? Have you tested this?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
On Sun, Oct 04, 2015 at 06:55:57PM -0400, Raphaël Beamonte wrote:
> Add some temporary variables to reduce line length under the maximum
> of 80 characters, as per the kernel code style.
>
> Signed-off-by: Raphaël Beamonte
> ---
> drivers/staging/rtl8192u/r8192U_core.c | 130
>
On Sat, Oct 10, 2015 at 01:23:13PM +0700, Ivan Safonov wrote:
> Unnecessary channel groups for 5 GHz removed from Hal_GetChnlGroup88E
> and it transformed to pretty get_channel_group(const u8 channel).
>
> Also removed code for 5 GHz frequency in Hal_ReadPowerValueFromPROM_8188E.
Why did you do
On Sat, Oct 10, 2015 at 01:28:34PM +0700, Ivan Safonov wrote:
> This patch replace BITn macro to BIT(n).
Why? Have you deleted the BITn macros?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On Tue, Oct 13, 2015 at 12:19:12AM +0530, punit vara wrote:
> On Tue, Oct 13, 2015 at 12:16 AM, Punit Vara wrote:
> > This patch is to the rtl871x_ioctl_linux.c file that fixes up following
> > warning reported by checkpatch.pl :
> >
> > -Prefer ether_addr_equal() or ether_addr_equal_unaligned()
On 10/12/2015 10:28 PM, James Morse wrote:
On 29/05/15 06:38, AKASHI Takahiro wrote:
The current kvm implementation on arm64 does cpu-specific initialization
at system boot, and has no way to gracefully shutdown a core in terms of
kvm. This prevents, especially, kexec from rebooting the system
On embedded devices, often there is a combination of
removable mmc devices (e.g. MMC/SD cards) and hard
wired ones (e.g. eMMC). Depending on the hardware
configuration, the 'mmcblkN' node might change if
the removable device is available or not at boot time.
E.g. if the removable device is
We just made sure policy->cpu is online and this check will always fail
as the policy is active. Drop it.
Signed-off-by: Viresh Kumar
Acked-by: Saravana Kannan
---
Resending as a separate patch.
drivers/cpufreq/cpufreq.c | 7 ---
1 file changed, 7 deletions(-)
diff --git
In nr_hw_queues >1 cases when certain number of cpus are onlined/or
offlined, that results change in request_queue map in block-mq layer,
we see the kernel dumping like:
BUG: unable to handle kernel NULL pointer dereference at 0080
IP: [] cpumask_set_cpu+0x6/0xd
PGD 6d957067 PUD
On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote:
> +int get_correlated_timestamp(struct correlated_ts *crt,
> + struct correlated_cs *crs)
> +{
> + struct timekeeper *tk = _core.timekeeper;
> + unsigned long seq;
> + cycles_t cycles,
On Tue, Oct 6, 2015 at 3:06 AM, Grant Likely wrote:
> [Resending because I messed up the first one]
>
> The elections for five of the ten members of the Linux Foundation
> Technical Advisory Board (TAB) are held every year[1]. This year the
> election will be at the 2015 Kernel Summit in Seoul,
Hi!
On 10/13/2015 12:35 AM, Dan Williams wrote:
> Per commit 2e586a7e017a "drm/vmwgfx: Map the fifo as cached" the driver
> expects the fifo registers to be cacheable. In preparation for
> deprecating ioremap_cache() convert its usage in vmwgfx to memremap().
>
> Cc: David Airlie
> Cc: Thomas
add a shutdown function for setting the gpio-leds
into off state when shuting down.
Signed-off-by: Heiko Schocher
---
drivers/leds/leds-gpio.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index af1876a..5db4515 100644
On 10/12/15 9:34 PM, Wangnan (F) wrote:
On 2015/10/13 12:16, Alexei Starovoitov wrote:
On 10/12/15 8:51 PM, Wangnan (F) wrote:
why 'set disable' is needed ?
the example given in cover letter shows the use case where you want
to receive samples only within sys_write() syscall.
The example
On some boards the energy enable detect mode leads in
trouble with some switches, so make the enabling of
this mode configurable through DT.
Signed-off-by: Heiko Schocher
---
.../devicetree/bindings/net/smsc-lan87xx.txt | 19 +
drivers/net/phy/smsc.c
Hi Philipp,
FYI, the error/warning still remains.
tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
master
head: 25cb62b76430a91cc6195f902e61c2cb84ade622
commit: 2091f5181c66b3617a977e79843aba10e087be6c [media] videobuf2: add trace
events
date: 3 months ago
config:
Disable the CLKOUT of the RTC after power-up.
After power-up/reset of the RTC, CLKOUT is enabled by default,
with CLKOUT enabled the RTC chip has 2-3 times higher power
consumption. If you do not need CLKOUT, you can disable the
CLKOUT with setting "disable-clkout" property.
Signed-off-by: Heiko
> >> > sparc64 machines:
> >>
> >> git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
> >> for-pci-v4.4-next
> >>
> >> It should fix some "no compatible bridge window"
> >
> > Blade 100: still has 2 address conflicts:
> > http://kodu.ut.ee/~mroos/dm/dm.sb100+patch
> >
> >
On Mon, Oct 12, 2015 at 11:45:19AM -0700, Christopher S. Hall wrote:
> Another representative use case of time sync and the correlated
> clocksource (in addition to PTP noted above) is PTP synchronized
> audio.
The added explanations of the audio use case do help. However, you
did not address my
On Mon, Oct 05, 2015 at 06:03:35PM -0300, Arnaldo Carvalho de Melo wrote:
> From: Arnaldo Carvalho de Melo
>
> Which is the most common default found in other similar tools.
I think it's more useful to change the default only when --children is
used. And there's a related issue too - please
On 2015/10/13 12:16, Alexei Starovoitov wrote:
On 10/12/15 8:51 PM, Wangnan (F) wrote:
why 'set disable' is needed ?
the example given in cover letter shows the use case where you want
to receive samples only within sys_write() syscall.
The example makes sense, but sys_write() is running on
On Tue, Oct 13, 2015 at 06:08:34AM +0200, Mike Galbraith wrote:
> It sounded like you wanted me to run the below alone. If so, it's a nogo.
Yes, thanks.
Then it is the sad fact that after migrate and removed_load_avg is added
in migrate_task_rq_fair(), we don't get a chance to update the tg
On Mon, Oct 12, 2015 at 7:46 PM, Theodore Ts'o wrote:
On Mon, Oct 12, 2015 at 04:30:59PM -0400, George Spelvin wrote:
> Segregating abusers solves both problems. If we do this then we
don't
> need to drop the locks from the nonblocking pool, which solves the
> security problem.
Er,
On Mon, Oct 12, 2015 at 05:49:52PM -0700, Bjorn Andersson wrote:
> The set_load() op deals with uA while the SMD packets used mA, so
> convert as we're building the packet.
>
> Signed-off-by: Bjorn Andersson
> ---
Looks fine to me. Thanks for the fix.
--
Qualcomm Innovation Center, Inc.
The
On Monday 12 October 2015 10:59 PM, Tony Lindgren wrote:
* Tony Lindgren [151012 10:17]:
* Keerthy [150901 17:24]:
On Tuesday 01 September 2015 11:33 PM, Tony Lindgren wrote:
* Keerthy [150901 10:22]:
On Wednesday 26 August 2015 09:29 AM, Keerthy wrote:
Currently apart from dra7,
Dear Arnd,
I would like to have your feedback on this patch.
If it is good now, can you accept it?
Lijun
On 10/1/15, 4:14 PM, "Lijun Pan" wrote:
>Need to include sched.h to fix the following compilation error
>if FSL_IFC is enabled on ARM64 machine.
>
>In file included from
On 10/12/15 8:51 PM, Wangnan (F) wrote:
why 'set disable' is needed ?
the example given in cover letter shows the use case where you want
to receive samples only within sys_write() syscall.
The example makes sense, but sys_write() is running on this cpu, so just
disabling it on the current one
On Tue, 2015-10-13 at 03:55 +0800, Yuyang Du wrote:
> On Mon, Oct 12, 2015 at 12:23:31PM +0200, Mike Galbraith wrote:
> > On Mon, 2015-10-12 at 10:12 +0800, Yuyang Du wrote:
> >
> > > I am guessing it is in calc_tg_weight(), and naughty boys do make them
> > > more
> > > favored, what a
Hi Jaehoon,
On 13 October 2015 at 07:36, Jaehoon Chung wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
Anand,
You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
pad correctly
On 10/12/2015 01:52 PM, Al Stone wrote:
On 10/11/2015 09:58 PM, Pat Erley wrote:
On 10/11/2015 08:49 PM, Hanjun Guo wrote:
On 10/12/2015 11:08 AM, Pat Erley wrote:
On 10/05/2015 10:12 AM, Al Stone wrote:
On 10/05/2015 07:39 AM, Rafael J. Wysocki wrote:
On Wednesday, September 30, 2015
On 2015/10/13 11:39, Alexei Starovoitov wrote:
On 10/12/15 8:27 PM, Wangnan (F) wrote:
Then how to avoid racing? For example, when one core disabling all
events
in a map, another core is enabling all of them. This racing may causes
sereval
perf events in a map dump samples while other events
Hi Krzysztof,
On 13 October 2015 at 09:13, Krzysztof Kozlowski
wrote:
> On 13.10.2015 12:08, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 13 October 2015 at 05:44, Krzysztof Kozlowski
>> wrote:
>>> On 13.10.2015 00:32, Anand Moon wrote:
Hi Krzysztof,
On 12 October 2015 at 11:14,
On 12-10-15, 18:09, Stephen Boyd wrote:
> There aren't any read-only or write-only bool file ops, but there
> is a caller of debugfs_create_bool() that calls it with mode
> equal to 0400. This leads to the possibility of userspace
> modifying the file, so let's use the newly created
>
On 12-10-15, 18:09, Stephen Boyd wrote:
> There aren't any read-only or write-only size_t file ops, but there
> is a caller of debugfs_create_size_t() that calls it with mode
> equal to 0400. This leads to the possibility of userspace
> modifying the file, so let's use the newly created
>
On 13.10.2015 12:08, Anand Moon wrote:
> Hi Krzysztof,
>
> On 13 October 2015 at 05:44, Krzysztof Kozlowski
> wrote:
>> On 13.10.2015 00:32, Anand Moon wrote:
>>> Hi Krzysztof,
>>>
>>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>>> wrote:
On 12.10.2015 00:46, Anand Moon wrote:
>
On 12-10-15, 18:09, Stephen Boyd wrote:
> There aren't any read-only or write-only x64 file ops, but there
> is a caller of debugfs_create_x64() that calls it with mode equal
> to S_IRUGO. This leads to the possibility of userspace modifying
> the file, so let's use the newly created
On 12-10-15, 18:09, Stephen Boyd wrote:
> The code that creates debugfs file with different file ops based
> on the file mode is duplicated in each debugfs_create_*() API.
> Consolidate that code into debugfs_create_mode(), that takes
> three file ops structures so that we don't have to keep
>
On Mon, Oct 12, 2015 at 12:23:31PM +0200, Mike Galbraith wrote:
> On Mon, 2015-10-12 at 10:12 +0800, Yuyang Du wrote:
>
> > I am guessing it is in calc_tg_weight(), and naughty boys do make them more
> > favored, what a reality...
> >
> > Mike, beg you test the following?
>
> Wow, that was
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Julia Lawall
> Sent: Sunday, October 11, 2015 4:48 AM
> To: Dept-GE Linux NIC Dev
> Cc: kernel-janit...@vger.kernel.org; netdev ; linux-
> kernel
> Subject: [PATCH] qlcnic: constify
On 12-10-15, 12:31, Saravana Kannan wrote:
> Can we use the first CPU in the related CPUs mask? Instead of the
> first CPU that the policy got created on? The policyX numbering
> would be a bit more consistent that way.
Okay..
> Suggested-by: ?
Will add. Though me/Rafael thought about it long
On 10/12/15 8:27 PM, Wangnan (F) wrote:
Then how to avoid racing? For example, when one core disabling all events
in a map, another core is enabling all of them. This racing may causes
sereval
perf events in a map dump samples while other events not. To avoid such
racing
I think some locking
Hi Stefan,
Sorry! for the delay.
On 10/08/2015 11:46 AM, Stefan Agner wrote:
Hi Bhuvan,
On 2015-09-23 06:43, Bhuvanchandra DV wrote:
There is an observed temperature difference of ~20°C with the
internal temperature reading and the temperature measured on
SoC package. Existing calculations
Cleanup for checkpatch.pl warn below:
CHECK: Alignment should match open parenthesis
#836: FILE: drivers/staging/android/ashmem.c:836:
by split three lines to four.
Signed-off-by: Liao Tonglang
---
drivers/staging/android/ashmem.c | 7 ---
1 file changed, 4 insertions(+), 3
> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, October 13, 2015 4:37 AM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: add
On 2015/10/13 3:29, Alexei Starovoitov wrote:
On 10/12/15 2:02 AM, Kaixu Xia wrote:
+extern const struct bpf_func_proto bpf_perf_event_sample_enable_proto;
+extern const struct bpf_func_proto bpf_perf_event_sample_disable_proto;
externs are unnecessary. Just make them static.
Also I prefer
On 12-10-15, 12:12, Saravana Kannan wrote:
> > if (new_policy) {
> > /* related_cpus should at least include policy->cpus. */
> >-cpumask_or(policy->related_cpus, policy->related_cpus,
> >policy->cpus);
> >+cpumask_copy(policy->related_cpus, policy->cpus);
Hi Jaehoon Chung,
On 13 October 2015 at 07:36, Jaehoon Chung wrote:
> Dear, Anand.
>
>
> On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
>> On 12.10.2015 23:47, Anand Moon wrote:
Anand,
You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
pad
On Mon, Oct 12, 2015 at 01:47:23PM +0200, Peter Zijlstra wrote:
>
> Also, should we do the below? At this point se->on_rq is still 0 so
> reweight_entity() will not update (dequeue/enqueue) the accounting, but
> we'll have just accounted the 'old' load.weight.
>
> Doing it this way around we'll
On Mon, 12 Oct 2015, Bueso wrote:
On Mon, 12 Oct 2015, Kirill A. Shutemov wrote:
On Mon, Oct 12, 2015 at 10:49:45AM -0700, Davidlohr Bueso wrote:
diff --git a/ipc/shm.c b/ipc/shm.c
index 4178727..9615f19 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -385,9 +385,25 @@ static struct mempolicy
On 10/12/15 7:30 PM, xiakaixu wrote:
The proper perf_event_enable/disable are so heavy that another
>mechanism needed? cpu_function_call is probably too much to do
>from bpf program, but that can be simplified?
>Based on the use case from cover letter, sounds like you want
>something like
Hi Krzysztof,
On 13 October 2015 at 05:44, Krzysztof Kozlowski
wrote:
> On 13.10.2015 00:32, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 11:14, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 00:46, Anand Moon wrote:
Added support for UHS-I bus speed 50MB/s (SDR50,
Hi Mark,
On 2015년 10월 05일 20:13, Mark Rutland wrote:
> On Mon, Oct 05, 2015 at 03:58:19PM +0900, Chanwoo Choi wrote:
>> This patch adds the support for Device tree bindings of extcon-gpio driver.
>> The extcon-gpio device tree node must include the both 'extcon-id' and
>> 'extcon-gpio' property.
Hi Jacek,
Thanks for your kind comments
I also append reply below
On 2015년 10월 13일 00:10, Jacek Anaszewski wrote:
> Hi Ingi,
>
> Thanks for the update. Few comments below.
>
> On 10/12/2015 03:12 PM, Ingi Kim wrote:
>> This patch adds device driver of Richtek RT5033 PMIC.
>> The driver
Use is_zero_pfn on pteval only after pte_present check on pteval
(It might be better idea to introduce is_zero_pte where checks
pte_present first). Otherwise, it could work with swap or
migration entry and if pte_pfn's result is equal to zero_pfn
by chance, we lose user's data in
On Mon, Oct 12, 2015 at 04:30:59PM -0400, George Spelvin wrote:
> > Segregating abusers solves both problems. If we do this then we don't
> > need to drop the locks from the nonblocking pool, which solves the
> > security problem.
>
> Er, sort of. I still think my points were valid, but they're
Hi Jaehoon Chung,
On 13 October 2015 at 08:09, Jaehoon Chung wrote:
> On 10/13/2015 11:29 AM, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 13 October 2015 at 05:40, Krzysztof Kozlowski
>> wrote:
>>> On 12.10.2015 23:33, Anand Moon wrote:
Hi Krzysztof,
On 12 October 2015 at 17:43,
Hi Krzysztof,
On 13 October 2015 at 05:42, Krzysztof Kozlowski
wrote:
> On 12.10.2015 23:47, Anand Moon wrote:
>>>
>>> Anand,
>>>
>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>> the commit
From: Tillmann Heidsieck
Date: Sat, 10 Oct 2015 21:47:18 +0200
> Smatch complains about returning hard coded error codes, silence this
> warning.
>
> drivers/atm/iphase.c:115 ia_enque_rtn_q() warn: returning -1 instead of
> -ENOMEM is sloppy
>
> Signed-off-by: Tillmann Heidsieck
Applied to
From: Tillmann Heidsieck
Date: Sat, 10 Oct 2015 21:47:19 +0200
> Fix a smatch warning:
> drivers/atm/iphase.c:1178 rx_pkt() warn: curly braces intended?
>
> The code is correct, the indention is misleading. In case the allocation
> of skb fails, we want to skip to the end.
>
> Signed-off-by:
On 10/13/2015 11:29 AM, Anand Moon wrote:
> Hi Krzysztof,
>
> On 13 October 2015 at 05:40, Krzysztof Kozlowski
> wrote:
>> On 12.10.2015 23:33, Anand Moon wrote:
>>> Hi Krzysztof,
>>>
>>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>>> wrote:
W dniu 12.10.2015 o 20:08, Anand Moon
From: huangdaode
Date: Sat, 10 Oct 2015 17:20:38 +0800
> This patch fix the building error reported by Jiri Pirko
>
> drivers/net/ethernet/hisilicon/hns/hnae.h:465:2: error: unknown type
> name 'phy_interface_t'
> phy_interface_t phy_if;
> ^
> the full build log is on
Em Tue, Oct 13, 2015 at 09:02:01AM +0900, Namhyung Kim escreveu:
> With horizontal scrolling, the left/right arrow keys are used to
> scroll columns and ENTER/ESC keys are used to enter/exit menu.
> However if callchain is recorded, the ENTER key is used to toggle
> callchain expansion so there's
于 2015/10/13 3:20, Alexei Starovoitov 写道:
> On 10/12/15 2:02 AM, Kaixu Xia wrote:
>> diff --git a/include/linux/bpf.h b/include/linux/bpf.h
>> index f57d7fe..25e073d 100644
>> --- a/include/linux/bpf.h
>> +++ b/include/linux/bpf.h
>> @@ -39,6 +39,7 @@ struct bpf_map {
>> u32 max_entries;
>>
Hi Krzysztof,
On 13 October 2015 at 05:40, Krzysztof Kozlowski
wrote:
> On 12.10.2015 23:33, Anand Moon wrote:
>> Hi Krzysztof,
>>
>> On 12 October 2015 at 17:43, Krzysztof Kozlowski
>> wrote:
>>> W dniu 12.10.2015 o 20:08, Anand Moon pisze:
Hi Krzysztof,
On 12 October 2015 at
On 10/12/2015 10:16 PM, Krzysztof Kozlowski wrote:
> W dniu 12.10.2015 o 22:04, Jaehoon Chung pisze:
>> On 10/12/2015 09:42 PM, Krzysztof Kozlowski wrote:
>>> W dniu 12.10.2015 o 19:46, Anand Moon pisze:
Hi Krzysztof,
On 12 October 2015 at 11:14, Krzysztof Kozlowski
wrote:
On Mon, 2015-10-12 at 13:47 +0200, Peter Zijlstra wrote:
> Also, should we do the below?
Ew. Box said "Either you quilt pop/burn, or I boot windows." ;-)
-Mike
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Tue, Oct 13, 2015 at 1:10 AM, Mark Rutland wrote:
> On Tue, Oct 13, 2015 at 01:04:17AM +0800, Chen-Yu Tsai wrote:
>> The physical display tied to the framebuffer may have regulators
>> providing power to it, such as power for LCDs or interface conversion
>> chips.
>>
>> The number of
Hi Matthias,
On Mon, 2015-10-12 at 18:32 +0200, Matthias Brugger wrote:
>
> On 07/10/15 11:14, James Liao wrote:
> > This patch is based on v4.3-rc4, to fix system hanging up issue
> > while disabling unused clocks.
> >
> > There is nothing different in mtk-scpsys.c and mt8173.dtsi from v1 [1].
debugfs_remove is used to remove a file or an empty directory from
the debugfs filesystem, but mci->debugfs is not empty.
This is not easily discovered, because debugfs_remove return nothing
when failed.
Reported-by: Yun Wu (Abel)
Signed-off-by: Tan Xiaojun
---
drivers/edac/edac_mc_sysfs.c |
From: "Christopher S. Hall"
Date: Mon, 12 Oct 2015 11:45:22 -0700
> @@ -25,6 +25,8 @@
> */
>
> #include "e1000.h"
> +#include
You cannot include an architecture specific header file in a driver
that's compiled on several architectures.
--
To unsubscribe from this list: send the line
On Mon, Oct 12, 2015 at 1:04 AM, Jim Davis wrote:
> On Sun, Oct 11, 2015 at 7:58 PM, Pranith Kumar
> wrote:
>>
>>
>> ../linux-firmware-image-4.3.0-rc4_4.3.0-rc4-7_powerpc.deb: No such
>> file or directory
>> scripts/package/Makefile:97: recipe for target 'bindeb-pkg' failed
>> make[1]: ***
Hi Christopher,
[auto build test ERROR on net/master -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
On Mon, Oct 12, 2015 at 05:00:47PM -0700, Rohit Vaswani wrote:
> This was found during userspace fuzzing test when a large size
> dma cma allocation is made by driver(like ion) through userspace.
>
> show_stack+0x10/0x1c
> dump_stack+0x74/0xc8
> kasan_report_error+0x2b0/0x408
>
Hi Christopher,
[auto build test ERROR on net/master -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
Hi all,
Today's linux-next merge of the tip tree got a conflict in:
arch/arm64/include/asm/atomic.h
between commit:
305d454aaa29 ("arm64: atomics: implement native {relaxed, acquire, release}
atomics")
from the arm64 tree and commit:
62e8a3258bda ("atomic, arch: Audit
On 10/12/2015 06:27 PM, Arnd Bergmann wrote:
> How about changing the zcomp code to pass the page pointer instead of the
> kernel space pointer? That would avoid having to do the kmap_atomic, which
> can itself be expensive on 32-bit machines and should not be needed here if
> you have a HW DMA
Dear, Anand.
On 10/13/2015 09:12 AM, Krzysztof Kozlowski wrote:
> On 12.10.2015 23:47, Anand Moon wrote:
>>>
>>> Anand,
>>>
>>> You essentially reverted here af6ad88acbd6 ("ARM: dts: Mux XMMCnDATA[0]
>>> pad correctly for Exynos5420 boards"). Why? There is no explanation in
>>> the commit
From: Alexei Starovoitov
Date: Wed, 7 Oct 2015 22:23:20 -0700
> v1-v2:
> - this set logically depends on cb patch
> "bpf: fix cb access in socket filter programs":
> http://patchwork.ozlabs.org/patch/527391/
> which is must have to allow unprivileged programs.
> Thanks Daniel for
Hi Christopher,
[auto build test ERROR on net/master -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
2015-10-09 22:00 GMT+09:00 Luis de Bethencourt :
> Since hid_connect() only cares about hiddev_connect() succeeding or
> failing, there is no need for this function to return an int and it can
> return a bool instead.
It can return bool but it would not be in line with kernel coding
style. The
From: Thomas Gleixner
Modern Intel hardware provides the so called Always Running Timer
(ART). The TSC which is usually used for timekeeping is derived from
ART and runs with a fixed frequency ratio to it. ART is routed to
devices and allows to take atomic timestamp samples from the device
clock
On modern Intel systems TSC is derived from the new Always Running Timer
(ART). In addition, ART can be captured simultaneous to the capture of
audio and network device clocks, allowing a correlation between timebases
to be constructed. Upon capture, the driver converts the captured ART
value to
Currently, network /system cross-timestamping is performed in the
PTP_SYS_OFFSET ioctl. The PTP clock driver reads gettimeofday() and the
gettime64() callback provided by the driver. The cross-timestamp is best
effort where the latency between the capture of system time
(getnstimeofday()) and the
Modern Intel systems supports cross timestamping of the network device
clock and Always Running Timer (ART) in hardware. This allows the device
time and system time to be precisely correlated. The timestamp pair is
exposed through the *_get_ts callback used by get_correlated_timestamp().
The
Modern Intel hardware adds an Always Running Timer (ART) that allows the
network and audio device clocks to precisely cross timestamp the device
clock with the system clock. This allows a precise correlation of the
device time and system time.
v4 adds a history which enables the audio DSP (a
> On Oct 12, 2015, at 21:52, Mel Gorman wrote:
>
> There is a redundant check and a memory leak introduced by a patch in
> mmotm. This patch removes an unlikely(order) check as we are sure order
> is not zero at the time. It also checks if a page is already allocated
> to avoid a memory leak.
>
There is a redundant check and a memory leak introduced by a patch in
mmotm. This patch removes an unlikely(order) check as we are sure order
is not zero at the time. It also checks if a page is already allocated
to avoid a memory leak.
This is a fix to the mmotm patch
On 2015/10/12 20:58, Jan Kara wrote:
What
gcc version are you using?
It is the last line of my gcc -v command.
gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
And it warn like this:
mm/page-writeback.c: In function ‘balance_dirty_pages.isra.26’:
mm/page-writeback.c:1537:26: warning:
The prefetch engine sends a dma request once a FIFO threshold has
been met. No other requests are received until the previous request
is handled.
Starting an edma transfer (dma_async_issue_pending) results in any
previous event for the dma channel to be cleared. Therefore, starting
the prefetch
Switch from dma_request_channel to allow passing dma channel
information from DT rather than hardcoding a value.
Signed-off-by: Franklin S Cooper Jr
---
drivers/mtd/nand/omap2.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/omap2.c
NAND dma prefetch has been broken for awhile and seems to have only
worked for sdma based devices.
This patchset fixes DMA prefetch to work on both edma and sdma devices
Tested on:
am335x general purpose evm
am437x general purpose evm
am37x general purpose evm
This patchset depends on Roger
Based on DMA documentation and testing using high memory buffer when
doing dma transfers can lead to various issues including kernel
panics.
To workaround this simply use cpu copy. The amount of high memory
buffers used are very uncommon so no noticeable performance hit should
be seen.
1 - 100 of 1976 matches
Mail list logo
