On Thu 2016-09-01 16:55:07, Sergey Senozhatsky wrote:
> On (08/30/16 13:19), Petr Mladek wrote:
> >
> > I see. But then we will need to be more careful because printk_func
> > and printk_func_saved will be manipulated in different contexts:
> > normal, irq, nmi. A solution might be using an atomic
On Wed, 31 Aug 2016, Russell King - ARM Linux wrote:
> On Wed, Aug 31, 2016 at 09:31:14AM +0100, Lee Jones wrote:
> > On Wed, 10 Aug 2016, Mark Brown wrote:
> >
> > > The patch
> > >
> > >mfd: tps65218: add version check to the PMIC probe
> >
> > Why did you take this patch?
>
> I think fo
在 2016/8/31 16:35, Marc Zyngier 写道:
> On 31/08/16 07:35, majun (F) wrote:
[...]
>>>
>>
>> I just checked the status of irq 30 during capture kernel booting.
>>
>> The irq 30 status is: mask, pending after arch_timer_starting_cpu() called.
>> Because irq 30 triggered only 1 time during capture ker
On Wed, Aug 31, 2016 at 02:50:41PM -0700, Alexei Starovoitov wrote:
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 97bfe62f30d7..dcaaaf3ec8e6 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -679,6 +679,8 @@ struct perf_event {
>
On 2016-08-31 09:37:43 [-0700], Eric Dumazet wrote:
> > --- a/net/ipv4/icmp.c
> > +++ b/net/ipv4/icmp.c
> > @@ -216,12 +219,14 @@ static inline struct sock *icmp_xmit_lock(struct net
> > *net)
> >
> > local_bh_disable();
> >
> > + local_lock(icmp_sk_lock);
>
> Deadlock alert ?
> Please
On 1 September 2016 at 06:11, Mike Galbraith wrote:
> On Wed, 2016-08-31 at 17:52 +0200, Vincent Guittot wrote:
>> On 31 August 2016 at 12:36, Mike Galbraith wrote:
>> > On Wed, 2016-08-31 at 12:18 +0200, Mike Galbraith wrote:
>> > > On Wed, 2016-08-31 at 12:01 +0200, Peter Zijlstra wrote:
>> >
>
On Wed, Aug 31, 2016 at 02:50:20PM -0700, John Stultz wrote:
> UBSAN: Undefined behaviour in kernel/time/time.c:783:2
> signed integer overflow:
> 5273 + 9223372036854771711 cannot be represented in type 'long int'
...
> Line 783 is this:
>
> 783 set_normalized_timespec64(&re
This version of the patch produces a compile error for me about
|add_interrupt_randomness
|
|CC [M] drivers/hv/vmbus_drv.o drivers/hv/vmbus_drv.c: In function
‘vmbus_isr’: drivers/hv/vmbus_drv.c:831:2: error: too few arguments to
function ‘add_interrupt_randomness’
add_interrupt_randomness(HY
On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
We have an well-known problem that the device needs to do some power
sequence before it can be recognized by related host, the typical
example like hard-wired mmc devices and usb devices.
This power sequence is hard to be described at device
On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
Add binding doc for generic power sequence library.
Signed-off-by: Peter Chen
Acked-by: Philipp Zabel
Acked-by: Rob Herring
---
.../bindings/power/pwrseq/pwrseq-generic.txt | 48 ++
1 file changed, 48 insertio
On Monday 15 August 2016 02:43 PM, Peter Chen wrote:
Some hard-wired USB devices need to do power sequence to let the
device work normally, the typical power sequence like: enable USB
PHY clock, toggle reset pin, etc. But current Linux USB driver
lacks of such code to do it, it may cause some h
On Thu, Sep 01, 2016 at 09:55:18AM +0200, Johannes Thumshirn wrote:
> On Wed, Aug 31, 2016 at 11:05:44AM -0600, Jens Axboe wrote:
> > This adds a new request flag, REQ_BG, that callers can use to tell
> > the block layer that this is background (non-urgent) IO.
> >
> > Signed-off-by: Jens Axboe
>
On Wed, Aug 31, 2016 at 11:05:44AM -0600, Jens Axboe wrote:
> This adds a new request flag, REQ_BG, that callers can use to tell
> the block layer that this is background (non-urgent) IO.
>
> Signed-off-by: Jens Axboe
> ---
s/WRITE_BG/REQ_BG/ in Subject?
--
Johannes Thumshirn
On (08/30/16 13:19), Petr Mladek wrote:
>
> I see. But then we will need to be more careful because printk_func
> and printk_func_saved will be manipulated in different contexts:
> normal, irq, nmi. A solution might be using an atomic counter
> and selecting the right vprintk_func according to the
> drivers/net/ethernet/qlogic/qed/qed_dcbx.c:1230:13-20: WARNING: kzalloc
> should be used for dcbx_info, instead of kmalloc/memset
> drivers/net/ethernet/qlogic/qed/qed_dcbx.c:1192:13-20: WARNING: kzalloc
> should be used for dcbx_info, instead of kmalloc/memset
>
>
> Use kzalloc rather than km
This patch to add a generic PHY driver for rockchip PCIe PHY.
Access the PHY via registers provided by GRF (general register
files) module.
Signed-off-by: Shawn Lin
---
Changes in v6:
- use dev_* instead of pr_*
Changes in v5:
- add COMPILE_TEST and select MFD_SYSCON on Kconfig
Changes in v4:
This patch adds a binding that describes the Rockchip PCIe PHY found on
Rockchip SoCs PCIe interface.
Signed-off-by: Shawn Lin
Acked-by: Rob Herring
---
Changes in v6: None
Changes in v5:
- add Rob's ack tag
Changes in v4: None
Changes in v3:
- rename the node to pcie_phy: pcie-phy suggested
From: Anshuman Khandual
For partition running on PHYP, there can be a adjunct partition
which shares the virtual address range with the operating system.
Virtual address ranges which can be used by the adjunct partition
are communicated with virtual device node of the device tree with
a property
On Wed, Aug 31, 2016 at 02:50:39PM -0700, Alexei Starovoitov wrote:
> +static u32 pe_prog_convert_ctx_access(enum bpf_access_type type, int dst_reg,
> + int src_reg, int ctx_off,
> + struct bpf_insn *insn_buf,
> +
Also provide some pointers for building IGT as some kernel hackers might
not be that familiar with building stuff on Linux distros.
Signed-off-by: Tomeu Vizoso
Cc: Daniel Vetter
---
Documentation/gpu/drm-uapi.rst | 37 +
1 file changed, 37 insertions(+)
diff
On Thursday, September 1, 2016 10:05:29 AM CEST Dongdong Liu wrote:
>
> 在 2016/8/31 19:45, Arnd Bergmann 写道:
> > On Wednesday, August 31, 2016 7:48:12 PM CEST Dongdong Liu wrote:
> >> +
> >> +/* HipXX PCIe host only supports 32-bit config access */
> >> +int hisi_pcie_common_cfg_read(void __iomem
When calling 'snd_pcm_format_width', SNDRV_PCM_FORMAT_LAST is a
valid value, so don't skip it.
Signed-off-by: Christophe JAILLET
---
Un-tested
---
sound/soc/davinci/davinci-mcasp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/davinci/davinci-mcasp.c
b/sound/soc/
On Thursday, September 1, 2016 2:16:24 PM CEST Baoyou Xie wrote:
> We get a few warnings when building kernel with W=1:
> drivers/isdn/hardware/mISDN/hfcmulti.c:568:1: warning: no previous
> declaration for 'enablepcibridge' [-Wmissing-declarations]
> drivers/isdn/hardware/mISDN/hfcmulti.c:574:1:
In dso__load, it iterates over *interesting" debug images which
have symtab/dynsym/opd section. For example, for loading the
libc-2.23.so on ubuntu 16.04, it will try 2 images in turn.
Try image 1: /lib/x86_64-linux-gnu/libc-2.23.so. Since it doesn't
have ".symtab" section, after symsrc__init retu
On Wed, Aug 31, 2016 at 03:51:13PM -0700, Stephen Boyd wrote:
> On 08/22, Yang Ling wrote:
> > This patch adds clock support to Loongson1C SoC.
> >
> > Signed-off-by: Yang Ling
> >
>
> It would be better to use the new clk_hw_*() and clkdev_hw_*()
> registration APIs. Care to make that change?
From: Ke Wang
sunrpc uses workqueue to clean cache regulary. There is no real dependency
of executing work on the cpu which queueing it.
On a idle system, especially for a heterogeneous systems like big.LITTLE,
it is observed that the big idle cpu was woke up many times just to service
this work
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4412-odroid-common.dtsi | 14 +-
arch/arm/boot/dts/exynos4412-od
On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
> It's a perennial request from hardware folks to be able to
> see the raw values of the pmu registers. Partly it's so that
> they can verify perf is doing what they want, and some
> of it is that they're interested in some of the
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4210-pinctrl.dtsi | 454
arch/arm/
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5260-pinctrl.dtsi | 184 ++---
arch/arm/
On 09/01/2016 07:25 AM, Rafał Miłecki wrote:
On 31 August 2016 at 21:00, Rafał Miłecki wrote:
On 31 August 2016 at 20:23, Alan Stern wrote:
On Tue, 30 Aug 2016, Rafał Miłecki wrote:
Not really as it won't cover some pretty common use cases. Many home
routers have few USB ports (2-5) and only
Hard-coded pinctrl configuration values are scattered through DTS files.
The numbers are difficult to decode by human, especially without the
datasheet. Additionally the drive strength differs between Exynos SoC
families increasing the confusion.
The header will help making this more readable and
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos4415-pinctrl.dtsi | 286 +++---
1 file ch
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5420-arndale-octa.dts | 6 +-
arch/arm/boot/dts/exynos5420
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5410-odroidxu.dts | 30 ++---
arch/arm/boot/dts/exynos5410-pinct
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos3250-pinctrl.dtsi | 270 +++---
1 file ch
Hi Santosh,
The following changes since commit 29b4817d4018df78086157ea3a55c1d9424a7cfc:
Linux 4.8-rc1 (2016-08-07 18:18:00 -0700)
are available in the git repository at:
https://github.com/t-kristo/linux-pm.git 4.8-rc1-ti-sci-fw
for you to fetch changes up to 7a2c510cdfa6a4b2f4200c122a37
Usage of DTS macros instead of hard-coded numbers makes code easier to
read. One does not have to remember which value means pull-up/down or
specific driver strength.
Signed-off-by: Krzysztof Kozlowski
---
arch/arm/boot/dts/exynos5250-pinctrl.dtsi | 402 +-
arch/arm/
Hi,
Merging
===
Patch #1 should probably go through pinctrl tree. In that case I would
appreciate a stable branch/tag so DTS could base on top of it.
Changes since v1
1. Follow Arnd's suggestion about moving the macros to common place.
2. Subjects: replace "GPIO" with "pinct
Replace duplicated macros in each DTSI file with a common macro coming
from header. Include the header in each pinctrl DTSI so further changes
could use it.
Although PIN_FUNC_SPC_2 does not bring much information about the
function itself, it still is more descriptive then hard-coded
number <2>.
> > Given this dependency I'm assuming the best route for these is via
> > the MFD tree...
> >
> > Lee, shout if you want them to go a different route.
>
> IIO looks like a more suitable route. Please provide me with a
> pull-request base off of an immutable tag.
> >
On Wed, 31 Aug 2016, Loic Pallardy wrote:
> With new rproc_request_resource API, rproc driver has now the
> capability to provide resources to remoteproc in order to modify
> firmware resource table.
> But in some cases, other operations are needed like compatibility
> check between resources defi
On 15/08/2016 23:35, Jonathan Cameron wrote:
>
>
> On 15 August 2016 18:07:30 BST, Guenter Roeck wrote:
>> On Mon, Aug 15, 2016 at 04:40:21PM +0100, Jonathan Cameron wrote:
>>> On 26/07/16 17:04, Guenter Roeck wrote:
On Tue, Jul 26, 2016 at 12:00:33PM +0200, Alexander Stein wrote:
> On
Hi David,
On Wed, Aug 31, 2016 at 04:14:14PM -0700, David Rientjes wrote:
> On Tue, 30 Aug 2016, wei.guo.si...@gmail.com wrote:
>
> > From: Simon Guo
> >
> > This patch adds mlock() test for multiple invocation on
> > the same address area, and verify it doesn't mess the
> > rlimit mlock limitat
On Wed, Aug 31, 2016 at 06:00:02PM +0100, Juri Lelli wrote:
> On 31/08/16 18:40, Peter Zijlstra wrote:
> > Another problem is that we have many semi related knobs; we have the
> > global RT runtime limit knob, but that doesn't affect cpufreq (maybe it
> > should)
>
> Maybe we could create this sor
On Wed, 31 Aug 2016, Loic Pallardy wrote:
> In rproc_fw_boot, add error message if kmemdump failed
> as done for other errors.
>
> Signed-off-by: Loic Pallardy
> ---
> drivers/remoteproc/remoteproc_core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/remot
On Fri, Aug 19, 2016 at 11:04:24AM -0500, ttha...@opensource.altera.com wrote:
> From: Thor Thayer
>
> Rename the EDAC debug trigger names to "altr_trigger"
> for consistency.
>
> Thor Thayer (2):
> EDAC, altera: Rename device trigger to common name
> EDAC, altera: Rename MC trigger to commo
On 08/31/2016 07:55 PM, ayaka wrote:
>
> On 08/31/2016 08:30 PM, Andrzej Hajda wrote:
>> Hi,
>>
>>
>> On 08/30/2016 12:50 AM, Randy Li wrote:
>>> It is actually a lvds panel connected through a rga-lvds bridge.
>>> But I really have no idea about what does a port mean in fimd node.
>>>
>>> Also how
This information will be printed in the subfunction numa_add_memblk.
They are not the same, but very similar.
Signed-off-by: Zhen Lei
Acked-by: Rob Herring
---
drivers/of/of_numa.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index ed5a097..
For a normal memory@ devicetree node, its reg property can contains more
memory blocks.
Because we don't known how many memory blocks maybe contained, so we try
from index=0, increase 1 until error returned(the end).
Signed-off-by: Zhen Lei
Acked-by: Rob Herring
---
drivers/of/of_numa.c | 29 +
On 09/01/16 09:52, Christophe JAILLET wrote:
> When calling 'snd_pcm_format_physical_width', SNDRV_PCM_FORMAT_LAST is a
> valid value, so don't skip it.
Acked-by: Peter Ujfalusi
> Signed-off-by: Christophe JAILLET
> ---
> Un-tested
> ---
> sound/soc/omap/omap-pcm.c | 2 +-
> 1 file changed, 1
If the numa-id which was configured in memory@ devicetree node is greater
than MAX_NUMNODES, we should report a warning. We have done this for cpus
and distance-map dt nodes, this patch help them to be consistent.
Signed-off-by: Zhen Lei
---
drivers/of/of_numa.c | 5 +
1 file changed, 5 inse
From: Kefeng Wang
Use pr_fmt to prefix kernel output.
Signed-off-by: Kefeng Wang
Acked-by: Rob Herring
---
drivers/of/of_numa.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 0d7459b..f63d4b0d 10064
If HAVE_MEMORYLESS_NODES is selected, and some memoryless numa nodes are
actually exist. The percpu variable areas and numa control blocks of that
memoryless numa nodes must be allocated from the nearest available node
to improve performance.
Signed-off-by: Zhen Lei
---
include/linux/memblock.h
Some numa nodes may have no memory. For example:
1. cpu0 on node0
2. cpu1 on node1
3. device0 access the momory from node0 and node1 take the same time.
So, we can not simply classify device0 to node0 or node1, but we can
define a node2 which distances to node0 and node1 are the same.
Signed-off-
v7 -> v8:
Updated patches according to Will Deacon's review comments, thanks.
The changed patches is: 3, 5, 8, 9, 10, 11, 12, 13, 15
Patch 3 requires an ack from Rob Herring.
Patch 10 requires an ack from linux-mm.
Hi, Will:
Something should still be clarified:
Patch 5, I modified it according to
From: Kefeng Wang
Use pr_fmt to prefix kernel output, and remove duplicated msg
of NUMA turned off.
Signed-off-by: Kefeng Wang
---
arch/arm64/mm/numa.c | 37 ++---
1 file changed, 18 insertions(+), 19 deletions(-)
diff --git a/arch/arm64/mm/numa.c b/arch/arm64/
From: Kefeng Wang
Use of_get_next_parent() instead of open-code.
Signed-off-by: Kefeng Wang
Acked-by: Rob Herring
---
drivers/of/of_numa.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/of/of_numa.c b/drivers/of/of_numa.c
index 625b057..0d7459b 100644
--- a/d
> I didn't explain well, There is a CFE command 'show devtree' here's the
> relevant bits (I Hope)
This is much simple than I expected.
> [CFE ]CFE> show devtree
> [/]
> | #interrupt-cells val 0x0002
> | #address-cells val 0x0002
> | #size-cells
When the deleted code is executed, only the bit of cpu0 was set on
cpu_possible_mask. So that, only set_cpu_numa_node(0, NUMA_NO_NODE); will
be executed. And map_cpu_to_node(0, 0) will soon be called. So these code
can be safely removed.
Signed-off-by: Zhen Lei
---
arch/arm64/mm/numa.c | 4
At present, the distances must equal in both direction for each node
pairs. For example: the distance of node B->A must the same to A->B.
But we really don't have to do this.
End up fill default distances as below:
1. If both direction specified, keep no change.
2. If only one direction specified,
numa_init may return error because of numa configuration error. So "No
NUMA configuration found" is inaccurate. In fact, specific configuration
error information should be immediately printed by the testing branch.
Signed-off-by: Zhen Lei
---
arch/arm64/kernel/acpi_numa.c | 4 +++-
arch/arm64/mm
801 - 862 of 862 matches
Mail list logo
