Re: [PATCH v2] phy: marvell: Fix and unify reg-init behavior
On Mon, Feb 15, 2016 at 6:01 PM, Clemens Gruber
wrote:
> +static int marvell_config_init(struct phy_device *phydev)
> +{
> + int err;
> +
> + /* Set registers from marvell,reg-init DT property */
> + err = marvell_of_reg_init(phydev);
> + if (err < 0)
> + return err;
> +
> + return 0;
> }
Couldn't this be replaced by
return marvell_of_reg_init(phydev); ?
Re: [PATCH wq/for-4.5-fixes] workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup
On Mon 15-02-16 13:21:25, Tejun Heo wrote:
> Hello, Michal.
>
> On Mon, Feb 15, 2016 at 06:33:46PM +0100, Michal Hocko wrote:
> > On Wed 10-02-16 10:55:03, Tejun Heo wrote:
> > [...]
> > > --- a/kernel/workqueue.c
> > > +++ b/kernel/workqueue.c
> > > @@ -570,6 +570,16 @@ static struct pool_workqueue
> > > *unbound_pwq_by_node(struct workqueue_struct *wq,
> > > int node)
> > > {
> > > assert_rcu_or_wq_mutex_or_pool_mutex(wq);
> > > +
> > > + /*
> > > + * XXX: @node can be NUMA_NO_NODE if CPU goes offline while a
> > > + * delayed item is pending. The plan is to keep CPU -> NODE
> > > + * mapping valid and stable across CPU on/offlines. Once that
> > > + * happens, this workaround can be removed.
> >
> > I am not sure this is completely true with the code as is currently.
> > Don't wee also need to use cpu_to_mem to handle memoryless CPUs?
>
> I'm not sure. I think we still wan to distinguish workers for a
> memoryless node from its neighboring node with memory. We don't want
> work items for the latter to be randomly distributed to the former
> after all.
I am not sure I understand. Does that mean that a node with no memory
would have its WQ specific pool? I might be missing something but I
thought that cpu_to_node will return NUMA_NO_NODE if the CPU is memory
less. Or do you expect that cpu_to_node will always return a valid node
id even when it doesn't contain any memory?
--
Michal Hocko
SUSE Labs
Re: [PATCH v2 05/10] regulator: axp20x: support AXP809 variant
On Mon, Feb 15, 2016 at 06:31:23PM +0800, Chen-Yu Tsai wrote: > The X-Powers AXP809 PMIC has a similar set of regulators as the AXP221, > though a few LDOs were removed, and a new switch output added. Like the > AXP221, AXP809 also has DC1SW and DC5LDO, which are internally chained > to DCDC1 and DCDC5, respectively. This doesn't apply against current code, please check and resend. signature.asc Description: PGP signature
[PATCH v2 2/4] dmaengine: mmp-pdma: add number of requestors
The DMA chip has a fixed number of requestor lines used for flow
control. This number is platform dependent. The pxa_dma dma driver will
use this value to activate or not the flow control.
There won't be any impact on mmp_pdma driver.
Signed-off-by: Robert Jarzmik
---
include/linux/platform_data/mmp_dma.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/platform_data/mmp_dma.h
b/include/linux/platform_data/mmp_dma.h
index 2a330ec9e2af..d1397c8ed94e 100644
--- a/include/linux/platform_data/mmp_dma.h
+++ b/include/linux/platform_data/mmp_dma.h
@@ -14,6 +14,7 @@
struct mmp_dma_platdata {
int dma_channels;
+ int nb_requestors;
};
#endif /* MMP_DMA_H */
--
2.1.4
[PATCH v2 1/4] dma: mmp_pdma: Add the #dma-requests DT property documentation
For pxa based platforms, the number of requestor lines should be specified, so that the driver can check if the flow control should be activated (when a requestor line is asked for) or not. Signed-off-by: Robert Jarzmik --- Since v1: rename of property to #dma-requests modify default value to 32 as suggested by Vinod --- Documentation/devicetree/bindings/dma/mmp-dma.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/dma/mmp-dma.txt b/Documentation/devicetree/bindings/dma/mmp-dma.txt index 7a802f64e5bd..8f7364a7b349 100644 --- a/Documentation/devicetree/bindings/dma/mmp-dma.txt +++ b/Documentation/devicetree/bindings/dma/mmp-dma.txt @@ -12,6 +12,8 @@ Required properties: Optional properties: - #dma-channels: Number of DMA channels supported by the controller (defaults to 32 when not specified) +- #dma-requests: Number of DMA requestor lines supported by the controller + (defaults to 32 when not specified) "marvell,pdma-1.0" Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688. -- 2.1.4
[PATCH v2 3/4] ARM: pxa: add the number of DMA requestor lines
Declare the number of DMA requestor lines per platform :
- for pxa25x: 40 requestor lines
- for pxa27x: 75 requestor lines
- for pxa3xx: 100 requestor lines
This information will be used to activate the DMA flow control or not.
Signed-off-by: Robert Jarzmik
---
Since v1: rename of property to #dma-requests
---
arch/arm/boot/dts/pxa27x.dtsi| 1 +
arch/arm/boot/dts/pxa3xx.dtsi| 1 +
arch/arm/mach-pxa/devices.c | 3 ++-
arch/arm/mach-pxa/pxa25x.c | 2 +-
arch/arm/mach-pxa/pxa27x.c | 2 +-
arch/arm/mach-pxa/pxa3xx.c | 2 +-
arch/arm/plat-pxa/include/plat/dma.h | 2 +-
7 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/boot/dts/pxa27x.dtsi b/arch/arm/boot/dts/pxa27x.dtsi
index ef366b204c89..aab08a48dbca 100644
--- a/arch/arm/boot/dts/pxa27x.dtsi
+++ b/arch/arm/boot/dts/pxa27x.dtsi
@@ -13,6 +13,7 @@
interrupts = <25>;
#dma-channels = <32>;
#dma-cells = <2>;
+ #dma-requests = <75>;
status = "okay";
};
diff --git a/arch/arm/boot/dts/pxa3xx.dtsi b/arch/arm/boot/dts/pxa3xx.dtsi
index cf6998a0804d..bea454f50ff9 100644
--- a/arch/arm/boot/dts/pxa3xx.dtsi
+++ b/arch/arm/boot/dts/pxa3xx.dtsi
@@ -12,6 +12,7 @@
interrupts = <25>;
#dma-channels = <32>;
#dma-cells = <2>;
+ #dma-requests = <100>;
status = "okay";
};
diff --git a/arch/arm/mach-pxa/devices.c b/arch/arm/mach-pxa/devices.c
index 6e12c162506f..d9ff6e4dd854 100644
--- a/arch/arm/mach-pxa/devices.c
+++ b/arch/arm/mach-pxa/devices.c
@@ -1233,6 +1233,7 @@ void __init pxa2xx_set_spi_info(unsigned id, struct
pxa2xx_spi_master *info)
static struct mmp_dma_platdata pxa_dma_pdata = {
.dma_channels = 0,
+ .nb_requestors = 0,
};
static struct resource pxa_dma_resource[] = {
@@ -1261,7 +1262,7 @@ static struct platform_device pxa2xx_pxa_dma = {
.resource = pxa_dma_resource,
};
-void __init pxa2xx_set_dmac_info(int nb_channels)
+void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors)
{
pxa_dma_pdata.dma_channels = nb_channels;
pxa_register_device(&pxa2xx_pxa_dma, &pxa_dma_pdata);
diff --git a/arch/arm/mach-pxa/pxa25x.c b/arch/arm/mach-pxa/pxa25x.c
index a177bf45feef..823504f48f80 100644
--- a/arch/arm/mach-pxa/pxa25x.c
+++ b/arch/arm/mach-pxa/pxa25x.c
@@ -206,7 +206,7 @@ static int __init pxa25x_init(void)
register_syscore_ops(&pxa_irq_syscore_ops);
register_syscore_ops(&pxa2xx_mfp_syscore_ops);
- pxa2xx_set_dmac_info(16);
+ pxa2xx_set_dmac_info(16, 40);
pxa_register_device(&pxa25x_device_gpio, &pxa25x_gpio_info);
ret = platform_add_devices(pxa25x_devices,
ARRAY_SIZE(pxa25x_devices));
diff --git a/arch/arm/mach-pxa/pxa27x.c b/arch/arm/mach-pxa/pxa27x.c
index 73e96270dc53..d84239c89639 100644
--- a/arch/arm/mach-pxa/pxa27x.c
+++ b/arch/arm/mach-pxa/pxa27x.c
@@ -310,7 +310,7 @@ static int __init pxa27x_init(void)
if (!of_have_populated_dt()) {
pxa_register_device(&pxa27x_device_gpio,
&pxa27x_gpio_info);
- pxa2xx_set_dmac_info(32);
+ pxa2xx_set_dmac_info(32, 75);
ret = platform_add_devices(devices,
ARRAY_SIZE(devices));
}
diff --git a/arch/arm/mach-pxa/pxa3xx.c b/arch/arm/mach-pxa/pxa3xx.c
index a1c4c888f246..fb0adb669124 100644
--- a/arch/arm/mach-pxa/pxa3xx.c
+++ b/arch/arm/mach-pxa/pxa3xx.c
@@ -450,7 +450,7 @@ static int __init pxa3xx_init(void)
if (of_have_populated_dt())
return 0;
- pxa2xx_set_dmac_info(32);
+ pxa2xx_set_dmac_info(32, 100);
ret = platform_add_devices(devices, ARRAY_SIZE(devices));
if (ret)
return ret;
diff --git a/arch/arm/plat-pxa/include/plat/dma.h
b/arch/arm/plat-pxa/include/plat/dma.h
index 28848b344e2d..ceba3e4184fc 100644
--- a/arch/arm/plat-pxa/include/plat/dma.h
+++ b/arch/arm/plat-pxa/include/plat/dma.h
@@ -95,6 +95,6 @@ static inline int pxad_toggle_reserved_channel(int
legacy_channel)
}
#endif
-extern void __init pxa2xx_set_dmac_info(int nb_channels);
+extern void __init pxa2xx_set_dmac_info(int nb_channels, int nb_requestors);
#endif /* __PLAT_DMA_H */
--
2.1.4
[PATCH v2 4/4] dmaengine: pxa_dma: fix the maximum requestor line
The current number of requestor lines is limited to 31. This was an
error of a previous commit, as this number is platform dependent, and is
actually :
- for pxa25x: 40 requestor lines
- for pxa27x: 75 requestor lines
- for pxa3xx: 100 requestor lines
The previous testing did not reveal the faulty constant as on pxa[23]xx
platforms, only camera, MSL and USB are above requestor 32, and in these
only the camera has a driver using dma.
Fixes: e87ffbdf0697 ("dmaengine: pxa_dma: fix the no-requestor case")
Signed-off-by: Robert Jarzmik
---
Since v1: change to #dma-requests the of property name
default to 32 requestors and warn as suggested by Vinod
---
drivers/dma/pxa_dma.c | 39 ---
1 file changed, 28 insertions(+), 11 deletions(-)
diff --git a/drivers/dma/pxa_dma.c b/drivers/dma/pxa_dma.c
index ca6c088edc8a..8b333601687f 100644
--- a/drivers/dma/pxa_dma.c
+++ b/drivers/dma/pxa_dma.c
@@ -122,6 +122,7 @@ struct pxad_chan {
struct pxad_device {
struct dma_device slave;
int nr_chans;
+ int nr_requestors;
void __iomem*base;
struct pxad_phy *phys;
spinlock_t phy_lock; /* Phy association */
@@ -473,7 +474,7 @@ static void pxad_free_phy(struct pxad_chan *chan)
return;
/* clear the channel mapping in DRCMR */
- if (chan->drcmr <= DRCMR_CHLNUM) {
+ if (chan->drcmr <= pdev->nr_requestors) {
reg = pxad_drcmr(chan->drcmr);
writel_relaxed(0, chan->phy->base + reg);
}
@@ -509,6 +510,7 @@ static bool is_running_chan_misaligned(struct pxad_chan
*chan)
static void phy_enable(struct pxad_phy *phy, bool misaligned)
{
+ struct pxad_device *pdev;
u32 reg, dalgn;
if (!phy->vchan)
@@ -518,7 +520,8 @@ static void phy_enable(struct pxad_phy *phy, bool
misaligned)
"%s(); phy=%p(%d) misaligned=%d\n", __func__,
phy, phy->idx, misaligned);
- if (phy->vchan->drcmr <= DRCMR_CHLNUM) {
+ pdev = to_pxad_dev(phy->vchan->vc.chan.device);
+ if (phy->vchan->drcmr <= pdev->nr_requestors) {
reg = pxad_drcmr(phy->vchan->drcmr);
writel_relaxed(DRCMR_MAPVLD | phy->idx, phy->base + reg);
}
@@ -914,6 +917,7 @@ static void pxad_get_config(struct pxad_chan *chan,
{
u32 maxburst = 0, dev_addr = 0;
enum dma_slave_buswidth width = DMA_SLAVE_BUSWIDTH_UNDEFINED;
+ struct pxad_device *pdev = to_pxad_dev(chan->vc.chan.device);
*dcmd = 0;
if (dir == DMA_DEV_TO_MEM) {
@@ -922,7 +926,7 @@ static void pxad_get_config(struct pxad_chan *chan,
dev_addr = chan->cfg.src_addr;
*dev_src = dev_addr;
*dcmd |= PXA_DCMD_INCTRGADDR;
- if (chan->drcmr <= DRCMR_CHLNUM)
+ if (chan->drcmr <= pdev->nr_requestors)
*dcmd |= PXA_DCMD_FLOWSRC;
}
if (dir == DMA_MEM_TO_DEV) {
@@ -931,7 +935,7 @@ static void pxad_get_config(struct pxad_chan *chan,
dev_addr = chan->cfg.dst_addr;
*dev_dst = dev_addr;
*dcmd |= PXA_DCMD_INCSRCADDR;
- if (chan->drcmr <= DRCMR_CHLNUM)
+ if (chan->drcmr <= pdev->nr_requestors)
*dcmd |= PXA_DCMD_FLOWTRG;
}
if (dir == DMA_MEM_TO_MEM)
@@ -1341,13 +1345,15 @@ static struct dma_chan *pxad_dma_xlate(struct
of_phandle_args *dma_spec,
static int pxad_init_dmadev(struct platform_device *op,
struct pxad_device *pdev,
- unsigned int nr_phy_chans)
+ unsigned int nr_phy_chans,
+ unsigned int nr_requestors)
{
int ret;
unsigned int i;
struct pxad_chan *c;
pdev->nr_chans = nr_phy_chans;
+ pdev->nr_requestors = nr_requestors;
INIT_LIST_HEAD(&pdev->slave.channels);
pdev->slave.device_alloc_chan_resources = pxad_alloc_chan_resources;
pdev->slave.device_free_chan_resources = pxad_free_chan_resources;
@@ -1382,7 +1388,7 @@ static int pxad_probe(struct platform_device *op)
const struct of_device_id *of_id;
struct mmp_dma_platdata *pdata = dev_get_platdata(&op->dev);
struct resource *iores;
- int ret, dma_channels = 0;
+ int ret, dma_channels = 0, nb_requestors = 0;
const enum dma_slave_buswidth widths =
DMA_SLAVE_BUSWIDTH_1_BYTE | DMA_SLAVE_BUSWIDTH_2_BYTES |
DMA_SLAVE_BUSWIDTH_4_BYTES;
@@ -1399,13 +1405,23 @@ static int pxad_probe(struct platform_device *op)
return PTR_ERR(pdev->base);
of_id = of_match_device(pxad_dt_ids, &op->dev);
- if (of_id)
+ if (of_id) {
of_property_read_u32(op->dev.o
Re: [PATCH 2/4] Drivers: hv: vmbus: avoid wait_for_completion() on crash
2016-02-12 16:42+0100, Vitaly Kuznetsov:
> wait_for_completion() may sleep, it enables interrupts and this
> is something we really want to avoid on crashes because interrupt
> handlers can cause other crashes. Switch to the recently introduced
> vmbus_wait_for_unload() doing busy wait instead.
(Too bad we fix crashers, so there is nothing to test on. :])
> Reported-by: Radim Krcmar
Reviewed-by: Radim Krčmář
> Signed-off-by: Vitaly Kuznetsov
> ---
> drivers/hv/channel_mgmt.c | 4 ++--
> drivers/hv/connection.c | 2 +-
> drivers/hv/hyperv_vmbus.h | 2 +-
> drivers/hv/vmbus_drv.c| 4 ++--
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/hv/channel_mgmt.c b/drivers/hv/channel_mgmt.c
> index 763d0c1..bd60207 100644
> --- a/drivers/hv/channel_mgmt.c
> +++ b/drivers/hv/channel_mgmt.c
> @@ -556,7 +556,7 @@ static void vmbus_unload_response(struct
> vmbus_channel_message_header *hdr)
> complete(&vmbus_connection.unload_event);
> }
>
> -void vmbus_initiate_unload(void)
> +void vmbus_initiate_unload(bool crash)
> {
> struct vmbus_channel_message_header hdr;
>
> @@ -573,7 +573,7 @@ void vmbus_initiate_unload(void)
>* vmbus_initiate_unload() is also called on crash and the crash can be
>* happening in an interrupt context, where scheduling is impossible.
>*/
> - if (!in_interrupt())
> + if (!crash)
> wait_for_completion(&vmbus_connection.unload_event);
> else
> vmbus_wait_for_unload();
> diff --git a/drivers/hv/connection.c b/drivers/hv/connection.c
> index 3dc5a9c..fb63d30 100644
> --- a/drivers/hv/connection.c
> +++ b/drivers/hv/connection.c
> @@ -236,7 +236,7 @@ void vmbus_disconnect(void)
> /*
>* First send the unload request to the host.
>*/
> - vmbus_initiate_unload();
> + vmbus_initiate_unload(false);
>
> if (vmbus_connection.work_queue) {
> drain_workqueue(vmbus_connection.work_queue);
> diff --git a/drivers/hv/hyperv_vmbus.h b/drivers/hv/hyperv_vmbus.h
> index 4ebc796..e6160a0 100644
> --- a/drivers/hv/hyperv_vmbus.h
> +++ b/drivers/hv/hyperv_vmbus.h
> @@ -665,7 +665,7 @@ void hv_vss_onchannelcallback(void *);
> int hv_fcopy_init(struct hv_util_service *);
> void hv_fcopy_deinit(void);
> void hv_fcopy_onchannelcallback(void *);
> -void vmbus_initiate_unload(void);
> +void vmbus_initiate_unload(bool crash);
>
> static inline void hv_poll_channel(struct vmbus_channel *channel,
> void (*cb)(void *))
> diff --git a/drivers/hv/vmbus_drv.c b/drivers/hv/vmbus_drv.c
> index 895eeed..08f98a1 100644
> --- a/drivers/hv/vmbus_drv.c
> +++ b/drivers/hv/vmbus_drv.c
> @@ -1266,7 +1266,7 @@ static void hv_kexec_handler(void)
> int cpu;
>
> hv_synic_clockevents_cleanup();
> - vmbus_initiate_unload();
> + vmbus_initiate_unload(false);
> for_each_online_cpu(cpu)
> smp_call_function_single(cpu, hv_synic_cleanup, NULL, 1);
> hv_cleanup();
> @@ -1274,7 +1274,7 @@ static void hv_kexec_handler(void)
>
> static void hv_crash_handler(struct pt_regs *regs)
> {
> - vmbus_initiate_unload();
> + vmbus_initiate_unload(true);
> /*
>* In crash handler we can't schedule synic cleanup for all CPUs,
>* doing the cleanup for current CPU only. This should be sufficient
> --
> 2.5.0
>
Re: [PATCH] regulator: vexpress: rename vexpress regulator implementation
On Mon, Feb 15, 2016 at 06:31:29PM +, Sudeep Holla wrote: > Understood. I knew lkml.org is broken if we tried very old links but > expected to work at-least for couple of month old patches. Anyways > hopefully [1] still works. It's not old links in particular AFAICT, just general instability. signature.asc Description: PGP signature
Re: [PATCH 3/4] Drivers: hv: vmbus: remove code duplication in message handling
2016-02-12 16:42+0100, Vitaly Kuznetsov: > We have 3 functions dealing with messages and they all implement > the same logic to finalize reads, move it to vmbus_signal_eom(). > > Suggested-by: Radim Krcmar Reviewed-by: Radim Krčmář
[PATCH 03/13] perf build: Add EXTRA_LDFLAGS option to makefile
From: Zubair Lutfullah Kakakhel To compile for little-endian systems, you need to pass -EL to CC and LD. EXTRA_CFLAGS works to pass -EL to CC. Add EXTRA_LDFLAGS to pass -EL to LD. Signed-off-by: Zubair Lutfullah Kakakhel Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1455024818-15842-1-git-send-email-zubair.kakak...@imgtec.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Makefile.perf | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index d404117810a7..4a4fad4182f5 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -139,6 +139,8 @@ $(call allow-override,CC,$(CROSS_COMPILE)gcc) $(call allow-override,AR,$(CROSS_COMPILE)ar) $(call allow-override,LD,$(CROSS_COMPILE)ld) +LD += $(EXTRA_LDFLAGS) + PKG_CONFIG = $(CROSS_COMPILE)pkg-config RM = rm -f -- 2.5.0
[PATCH 04/13] perf python scripting: Append examples to err msg about audit-libs-python
From: Taeung Song To print syscall names, the audit-libs-python package is required.. If not installed, it prints this error string: # perf script syscall-counts Install the audit-libs-python package to get syscall names. But the package name is different in Ubuntu, mention that in the error message, similar to a error message of util/trace-event-scripting.c: # perf script syscall-counts Install the audit-libs-python package to get syscall names. For example: # apt-get install python-audit (Ubuntu) # yum install audit-libs-python (Fedora) etc. Signed-off-by: Taeung Song Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/1455018790-13425-1-git-send-email-treeze.tae...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py index 15c8400240fd..1d95009592eb 100644 --- a/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py +++ b/tools/perf/scripts/python/Perf-Trace-Util/lib/Perf/Trace/Util.py @@ -71,7 +71,10 @@ try: except: if not audit_package_warned: audit_package_warned = True - print "Install the audit-libs-python package to get syscall names" + print "Install the audit-libs-python package to get syscall names.\n" \ +"For example:\n # apt-get install python-audit (Ubuntu)" \ +"\n # yum install audit-libs-python (Fedora)" \ +"\n etc.\n" def syscall_name(id): try: -- 2.5.0
[PATCH 07/13] perf tools: Unlink entries from terms list
From: Wang Nan
We were just freeing them, better unlink and init its nodes to catch
bugs faster if we keep dangling references to them.
Signed-off-by: Wang Nan
Acked-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: He Kuang
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
[ Spun off from another patch, use list_del_init() instead of list_del() ]
Link:
http://lkml.kernel.org/r/1454680939-24963-2-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 813d9b272c81..133c8d28f36c 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -2072,8 +2072,10 @@ void parse_events__free_terms(struct list_head *terms)
{
struct parse_events_term *term, *h;
- list_for_each_entry_safe(term, h, terms, list)
+ list_for_each_entry_safe(term, h, terms, list) {
+ list_del_init(&term->list);
free(term);
+ }
}
void parse_events_evlist_error(struct parse_events_evlist *data,
--
2.5.0
[PATCH 06/13] perf hists: Do column alignment on the format iterator
From: Arnaldo Carvalho de Melo
We were doing column alignment in the format function for each cell,
returning a string padded with spaces so that when the next column is
printed the cursor is at its column alignment.
This ends up needlessly printing trailing spaces, do it at the format
iterator, that is where we know if it is needed, i.e. if there is more
columns to be printed.
This eliminates the need for triming lines when doing a dump using 'P'
in the TUI browser and also produces far saner results with things like
piping 'perf report' to 'less'.
Right now only the formatters for sym->name and the 'locked' column
(perf mem report), that are the ones that end up at the end of lines
in the default 'perf report', 'perf top' and 'perf mem report' tools,
the others will be done in a subsequent patch.
In the end the 'width' parameter for the formatters now mean, in
'printf' terms, the 'precision', where before it was the field 'width'.
Reported-by: Dave Jones
Cc: Jiri Olsa
Cc: Namhyung Kim
Link: http://lkml.kernel.org/n/tip-s7iwl2gj23w92l6tibnrc...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/ui/browsers/hists.c | 27 ++-
tools/perf/ui/stdio/hist.c | 1 +
tools/perf/util/hist.c | 21 +
tools/perf/util/hist.h | 5 +
tools/perf/util/sort.c | 13 +++--
5 files changed, 48 insertions(+), 19 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index a5a5390476ac..1819771243f9 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -1061,7 +1061,6 @@ static int hist_browser__show_entry(struct hist_browser
*browser,
struct hist_entry *entry,
unsigned short row)
{
- char s[256];
int printed = 0;
int width = browser->b.width;
char folded_sign = ' ';
@@ -1086,16 +1085,18 @@ static int hist_browser__show_entry(struct hist_browser
*browser,
.folded_sign= folded_sign,
.current_entry = current_entry,
};
- struct perf_hpp hpp = {
- .buf= s,
- .size = sizeof(s),
- .ptr= &arg,
- };
int column = 0;
hist_browser__gotorc(browser, row, 0);
hists__for_each_format(browser->hists, fmt) {
+ char s[2048];
+ struct perf_hpp hpp = {
+ .buf= s,
+ .size = sizeof(s),
+ .ptr= &arg,
+ };
+
if (perf_hpp__should_skip(fmt, entry->hists) ||
column++ < browser->b.horiz_scroll)
continue;
@@ -1120,11 +1121,18 @@ static int hist_browser__show_entry(struct hist_browser
*browser,
}
if (fmt->color) {
- width -= fmt->color(fmt, &hpp, entry);
+ int ret = fmt->color(fmt, &hpp, entry);
+ hist_entry__snprintf_alignment(entry, &hpp,
fmt, ret);
+ /*
+* fmt->color() already used ui_browser to
+* print the non alignment bits, skip it (+ret):
+*/
+ ui_browser__printf(&browser->b, "%s", s + ret);
} else {
- width -= fmt->entry(fmt, &hpp, entry);
+ hist_entry__snprintf_alignment(entry, &hpp,
fmt, fmt->entry(fmt, &hpp, entry));
ui_browser__printf(&browser->b, "%s", s);
}
+ width -= hpp.buf - s;
}
/* The scroll bar isn't being used */
@@ -1452,9 +1460,10 @@ static int hist_browser__fprintf_entry(struct
hist_browser *browser,
first = false;
ret = fmt->entry(fmt, &hpp, he);
+ ret = hist_entry__snprintf_alignment(he, &hpp, fmt, ret);
advance_hpp(&hpp, ret);
}
- printed += fprintf(fp, "%s\n", rtrim(s));
+ printed += fprintf(fp, "%s\n", s);
if (folded_sign == '-')
printed += hist_browser__fprintf_callchain(browser, he, fp);
diff --git a/tools/perf/ui/stdio/hist.c b/tools/perf/ui/stdio/hist.c
index 1a6e8f7f38c4..87b022ff03d8 100644
--- a/tools/perf/ui/stdio/hist.c
+++ b/tools/perf/ui/stdio/hist.c
@@ -403,6 +403,7 @@ static int hist_entry__snprintf(struct hist_entry *he,
struct perf_hpp *hpp)
else
ret = fmt->entry(fmt, hpp, he);
+ ret =
Re: [PATCH wq/for-4.5-fixes] workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup
Hello, Michal. On Mon, Feb 15, 2016 at 09:54:38PM +0100, Michal Hocko wrote: > I am not sure I understand. Does that mean that a node with no memory > would have its WQ specific pool? I might be missing something but I Yeah, I think it should. > thought that cpu_to_node will return NUMA_NO_NODE if the CPU is memory > less. Or do you expect that cpu_to_node will always return a valid node > id even when it doesn't contain any memory? Hmmm... that was what I was expecting. It's not really looking for memory node to use but identify affinity there. Thanks. -- tejun
[PATCH 01/13] perf config: Add '--system' and '--user' options to select which config file is used
From: Taeung Song
The '--system' option means $(sysconfdir)/perfconfig and '--user' means
$HOME/.perfconfig. If none is used, both system and user config file are
read. E.g.:
# perf config [] [options]
With an specific config file:
# perf config --user | --system
or both user and system config file:
# perf config
Signed-off-by: Taeung Song
Cc: Jiri Olsa
Cc: Namhyung Kim
Link:
http://lkml.kernel.org/r/1455126685-32367-2-git-send-email-treeze.tae...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Documentation/perf-config.txt | 14 +-
tools/perf/builtin-config.c | 27 ---
tools/perf/util/cache.h | 3 +++
tools/perf/util/config.c | 4 ++--
4 files changed, 42 insertions(+), 6 deletions(-)
diff --git a/tools/perf/Documentation/perf-config.txt
b/tools/perf/Documentation/perf-config.txt
index c7158bfb1649..15949e2a7805 100644
--- a/tools/perf/Documentation/perf-config.txt
+++ b/tools/perf/Documentation/perf-config.txt
@@ -8,7 +8,7 @@ perf-config - Get and set variables in a configuration file.
SYNOPSIS
[verse]
-'perf config' -l | --list
+'perf config' [] -l | --list
DESCRIPTION
---
@@ -21,6 +21,14 @@ OPTIONS
--list::
Show current config variables, name and value, for all sections.
+--user::
+ For writing and reading options: write to user
+ '$HOME/.perfconfig' file or read it.
+
+--system::
+ For writing and reading options: write to system-wide
+ '$(sysconfdir)/perfconfig' or read it.
+
CONFIGURATION FILE
--
@@ -30,6 +38,10 @@ The '$HOME/.perfconfig' file is used to store a per-user
configuration.
The file '$(sysconfdir)/perfconfig' can be used to
store a system-wide default configuration.
+When reading or writing, the values are read from the system and user
+configuration files by default, and options '--system' and '--user'
+can be used to tell the command to read from or write to only that location.
+
Syntax
~~
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
index f04e804a9fad..c42448ed5dfe 100644
--- a/tools/perf/builtin-config.c
+++ b/tools/perf/builtin-config.c
@@ -13,8 +13,10 @@
#include "util/util.h"
#include "util/debug.h"
+static bool use_system_config, use_user_config;
+
static const char * const config_usage[] = {
- "perf config [options]",
+ "perf config [] [options]",
NULL
};
@@ -25,6 +27,8 @@ enum actions {
static struct option config_options[] = {
OPT_SET_UINT('l', "list", &actions,
"show current config variables", ACTION_LIST),
+ OPT_BOOLEAN(0, "system", &use_system_config, "use system config file"),
+ OPT_BOOLEAN(0, "user", &use_user_config, "use user config file"),
OPT_END()
};
@@ -42,10 +46,23 @@ static int show_config(const char *key, const char *value,
int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
{
int ret = 0;
+ char *user_config = mkpath("%s/.perfconfig", getenv("HOME"));
argc = parse_options(argc, argv, config_options, config_usage,
PARSE_OPT_STOP_AT_NON_OPTION);
+ if (use_system_config && use_user_config) {
+ pr_err("Error: only one config file at a time\n");
+ parse_options_usage(config_usage, config_options, "user", 0);
+ parse_options_usage(NULL, config_options, "system", 0);
+ return -1;
+ }
+
+ if (use_system_config)
+ config_exclusive_filename = perf_etc_perfconfig();
+ else if (use_user_config)
+ config_exclusive_filename = user_config;
+
switch (actions) {
case ACTION_LIST:
if (argc) {
@@ -53,9 +70,13 @@ int cmd_config(int argc, const char **argv, const char
*prefix __maybe_unused)
parse_options_usage(config_usage, config_options, "l",
1);
} else {
ret = perf_config(show_config, NULL);
- if (ret < 0)
+ if (ret < 0) {
+ const char * config_filename =
config_exclusive_filename;
+ if (!config_exclusive_filename)
+ config_filename = user_config;
pr_err("Nothing configured, "
- "please check your ~/.perfconfig
file\n");
+ "please check your %s \n",
config_filename);
+ }
}
break;
default:
diff --git a/tools/perf/util/cache.h b/tools/perf/util/cache.h
index 07b5d63947b1..3ca453f0c51f 100644
--- a/tools/perf/util/cache.h
+++ b/tools/perf/util/cache.h
@@ -23,6 +23,8 @@
#define PERF_TRACEFS_ENVIRONMENT "PERF_TRACEFS_DIR"
#define PERF_PAGER_ENVIRONMENT "PERF_P
[PATCH 10/13] perf tools: Free the terms list_head in parse_events__free_terms()
From: Wang Nan
Fixing a leak, since code calling parse_events__free_terms() expect it
to free the list_head too.
Signed-off-by: Wang Nan
Acked-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: He Kuang
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Zefan Li
Cc: pi3or...@163.com
[ Spun off from another patch ]
Link:
http://lkml.kernel.org/r/1454680939-24963-2-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 668afdccfcca..d1b49ec7ae46 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -2081,6 +2081,7 @@ void parse_events_terms__purge(struct list_head *terms)
void parse_events__free_terms(struct list_head *terms)
{
parse_events_terms__purge(terms);
+ free(terms);
}
void parse_events_evlist_error(struct parse_events_evlist *data,
--
2.5.0
[PATCH 02/13] perf symbols: Fix symbols searching for module in buildid-cache
From: Wang Nan
Before this patch, if a sample is triggered inside a module not in
/lib/modules/`uname -r`/, even if the module is in buildid-cache, 'perf
report' will still be unable to find the correct symbol. For example:
# rm -rf ~/.debug/
# perf buildid-cache -a ./mymodule.ko
# perf probe -m ./mymodule.ko -a get_mymodule_val
Added new event:
probe:get_mymodule_val (on get_mymodule_val in mymodule)
You can now use it in all perf tools, such as:
perf record -e probe:get_mymodule_val -aR sleep 1
# perf record -e probe:get_mymodule_val cat /proc/mymodule
mymodule:3
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.011 MB perf.data (1 samples) ]
# perf report --stdio
[SNIP]
#
# Overhead Command Shared Object Symbol
# ... ..
#
100.00% cat [mymodule][k] 0x0001
# perf report - --stdio
dso__load_sym: adjusting symbol: st_value: 0 sh_addr: 0 sh_offset: 0x70
symbol__new: get_mymodule_val 0x70-0x8a
[SNIP]
This is caused by dso__load() -> dso__load_sym(). In dso__load(), kmod
is true only when its file is found in some well know directories. All
files loaded from buildid-cache are treated as user programs. Following
dso__load_sym() set map->pgoff incorrectly.
This patch gives kernel modules in buildid-cache a chance to adjust
value of kmod. After dso__load() get the type of symbols, if it is
buildid, check the last 3 chars of original filename against '.ko', and
adjust the value of kmod if the file is a kernel module.
Signed-off-by: Wang Nan
Cc: Adrian Hunter
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Cody P Schafer
Cc: He Kuang
Cc: Jeremie Galarneau
Cc: Jiri Olsa
Cc: Kirill Smelkov
Cc: Li Zefan
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1454680939-24963-3-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/build-id.c | 44
tools/perf/util/build-id.h | 1 +
tools/perf/util/symbol.c | 4
3 files changed, 49 insertions(+)
diff --git a/tools/perf/util/build-id.c b/tools/perf/util/build-id.c
index b28100ee1732..f1479eeef7da 100644
--- a/tools/perf/util/build-id.c
+++ b/tools/perf/util/build-id.c
@@ -166,6 +166,50 @@ char *dso__build_id_filename(const struct dso *dso, char
*bf, size_t size)
return build_id__filename(build_id_hex, bf, size);
}
+bool dso__build_id_is_kmod(const struct dso *dso, char *bf, size_t size)
+{
+ char *id_name, *ch;
+ struct stat sb;
+
+ id_name = dso__build_id_filename(dso, bf, size);
+ if (!id_name)
+ goto err;
+ if (access(id_name, F_OK))
+ goto err;
+ if (lstat(id_name, &sb) == -1)
+ goto err;
+ if ((size_t)sb.st_size > size - 1)
+ goto err;
+ if (readlink(id_name, bf, size - 1) < 0)
+ goto err;
+
+ bf[sb.st_size] = '\0';
+
+ /*
+* link should be:
+*
../../lib/modules/4.4.0-rc4/kernel/net/ipv4/netfilter/nf_nat_ipv4.ko/a09fe3eb3147dafa4e3b31dbd6257e4d696bdc92
+*/
+ ch = strrchr(bf, '/');
+ if (!ch)
+ goto err;
+ if (ch - 3 < bf)
+ goto err;
+
+ return strncmp(".ko", ch - 3, 3) == 0;
+err:
+ /*
+* If dso__build_id_filename work, get id_name again,
+* because id_name points to bf and is broken.
+*/
+ if (id_name)
+ id_name = dso__build_id_filename(dso, bf, size);
+ pr_err("Invalid build id: %s\n", id_name ? :
+dso->long_name ? :
+dso->short_name ? :
+"[unknown]");
+ return false;
+}
+
#define dsos__for_each_with_build_id(pos, head)\
list_for_each_entry(pos, head, node)\
if (!pos->has_build_id) \
diff --git a/tools/perf/util/build-id.h b/tools/perf/util/build-id.h
index 27a14a8a945b..64af3e20610d 100644
--- a/tools/perf/util/build-id.h
+++ b/tools/perf/util/build-id.h
@@ -16,6 +16,7 @@ int sysfs__sprintf_build_id(const char *root_dir, char
*sbuild_id);
int filename__sprintf_build_id(const char *pathname, char *sbuild_id);
char *dso__build_id_filename(const struct dso *dso, char *bf, size_t size);
+bool dso__build_id_is_kmod(const struct dso *dso, char *bf, size_t size);
int build_id__mark_dso_hit(struct perf_tool *tool, union perf_event *event,
struct perf_sample *sample, struct perf_evsel *evsel,
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 90cedfa30e43..e7588dc91518 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1529,6 +1529,10 @@ int dso__load(struct dso *dso, struct map *map,
symbol_filter_t filter)
[PATCH 13/13] perf tests: Fix build on older systems where 'signal' is reserved
From: Arnaldo Carvalho de Melo
fixing the following problems, for instance, on RHEL6.7:
CC /tmp/build/perf/tests/bp_signal.o
cc1: warnings being treated as errors
tests/bp_signal.c: In function ‘__event’:
tests/bp_signal.c:106: error: declaration of ‘signal’ shadows a global
declaration
/usr/include/signal.h:101: error: shadowed declaration is here
tests/bp_signal.c: In function ‘bp_event’:
tests/bp_signal.c:144: error: declaration of ‘signal’ shadows a global
declaration
/usr/include/signal.h:101: error: shadowed declaration is here
tests/bp_signal.c: In function ‘wp_event’:
tests/bp_signal.c:149: error: declaration of ‘signal’ shadows a global
declaration
/usr/include/signal.h:101: error: shadowed declaration is here
mv: cannot stat `/tmp/build/perf/tests/.bp_signal.o.tmp': No such file or
directory
make[3]: *** [/tmp/build/perf/tests/bp_signal.o] Error 1
make[2]: *** [tests] Error 2
make[1]: *** [/tmp/build/perf/perf-in.o] Error 2
make[1]: *** Waiting for unfinished jobs
Reported-by: Vinson Lee
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Daniel Borkmann
Cc: He Kuang
Cc: Li Zefan
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Cc: Will Deacon
Cc: pi3or...@163.com
Fixes: 8fd34e1cce18 ("perf test: Improve bp_signal")
Link: http://lkml.kernel.org/n/tip-wlpx6tik1b0jirlkw64bv...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/bp_signal.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/tools/perf/tests/bp_signal.c b/tools/perf/tests/bp_signal.c
index 1d1bb489b4e8..e7664fe3bd33 100644
--- a/tools/perf/tests/bp_signal.c
+++ b/tools/perf/tests/bp_signal.c
@@ -103,7 +103,7 @@ static void sig_handler(int signum __maybe_unused,
}
}
-static int __event(bool is_x, void *addr, int signal)
+static int __event(bool is_x, void *addr, int sig)
{
struct perf_event_attr pe;
int fd;
@@ -133,7 +133,7 @@ static int __event(bool is_x, void *addr, int signal)
}
fcntl(fd, F_SETFL, O_RDWR|O_NONBLOCK|O_ASYNC);
- fcntl(fd, F_SETSIG, signal);
+ fcntl(fd, F_SETSIG, sig);
fcntl(fd, F_SETOWN, getpid());
ioctl(fd, PERF_EVENT_IOC_RESET, 0);
@@ -141,14 +141,14 @@ static int __event(bool is_x, void *addr, int signal)
return fd;
}
-static int bp_event(void *addr, int signal)
+static int bp_event(void *addr, int sig)
{
- return __event(true, addr, signal);
+ return __event(true, addr, sig);
}
-static int wp_event(void *addr, int signal)
+static int wp_event(void *addr, int sig)
{
- return __event(false, addr, signal);
+ return __event(false, addr, sig);
}
static long long bp_count(int fd)
--
2.5.0
[PATCH 12/13] perf data: Fix releasing event_class
From: Wang Nan
A new patch in libbabeltrace [1] reveals a object leak problem in
'perf data' CTF support: perf code never releases the event_class
which is allocated in add_event() and stored in evsel's private field.
If libbabeltrace has the above patch applied, leaking event_class
prevents the writer from being destroyed and flushing metadata. For
example:
$ perf record ls
perf.data
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.012 MB perf.data (12 samples) ]
$ perf data convert --to-ctf ./out.ctf
[ perf data convert: Converted 'perf.data' into CTF data './out.ctf' ]
[ perf data convert: Converted and wrote 0.000 MB (12 samples) ]
$ cat ./out.ctf/metadata
$ ls -l ./out.ctf/metadata
-rw-r- 1 w00229757 mm 0 Jan 27 10:49 ./out.ctf/metadata
The correct result should be:
...
$ cat ./out.ctf/metadata
/* CTF 1.8 */
trace {
[SNIP]
$ ls -l ./out.ctf/metadata
-rw-r- 1 w00229757 mm 2446 Jan 27 10:52 ./out.ctf/metadata
The full story is:
Patch [1] of babeltrace redesigns its reference counting scheme. In that
patch:
* writer <- trace (bt_ctf_writer_create)
* trace <- stream_class (bt_ctf_trace_add_stream_class)
* stream_class <- event_class (bt_ctf_stream_class_add_event_class)
('<-' means 'is a parent of')
Holding of event_class causes reference count of corresponding 'writer'
to increase through parent chain. Perf expects that 'writer' is released
(so metadata is flushed) through bt_ctf_writer_put() in
ctf_writer__cleanup(). However, since it never releases event_class, the
reference of 'writer' won't be dropped, so bt_ctf_writer_put() won't
lead to the release of writer.
Before this CTF patch, !(writer <- trace). Even with event_class leaking,
the writer ends up being released.
[1]
https://github.com/efficios/babeltrace/commit/e6a8e8e4744633807083a077ff9f101eb97d9801
Signed-off-by: Wang Nan
Acked-by: Jiri Olsa
Cc: Adrian Hunter
Cc: Alexei Starovoitov
Cc: Brendan Gregg
Cc: Cody P Schafer
Cc: He Kuang
Cc: Jeremie Galarneau
Cc: Kirill Smelkov
Cc: Li Zefan
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Zefan Li
Cc: pi3or...@163.com
Link:
http://lkml.kernel.org/r/1454680939-24963-6-git-send-email-wangn...@huawei.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/data-convert-bt.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/tools/perf/util/data-convert-bt.c
b/tools/perf/util/data-convert-bt.c
index 34cd1e4039d3..b722e57d5a87 100644
--- a/tools/perf/util/data-convert-bt.c
+++ b/tools/perf/util/data-convert-bt.c
@@ -858,6 +858,23 @@ static int setup_events(struct ctf_writer *cw, struct
perf_session *session)
return 0;
}
+static void cleanup_events(struct perf_session *session)
+{
+ struct perf_evlist *evlist = session->evlist;
+ struct perf_evsel *evsel;
+
+ evlist__for_each(evlist, evsel) {
+ struct evsel_priv *priv;
+
+ priv = evsel->priv;
+ bt_ctf_event_class_put(priv->event_class);
+ zfree(&evsel->priv);
+ }
+
+ perf_evlist__delete(evlist);
+ session->evlist = NULL;
+}
+
static int setup_streams(struct ctf_writer *cw, struct perf_session *session)
{
struct ctf_stream **stream;
@@ -1171,6 +1188,7 @@ int bt_convert__perf2ctf(const char *input, const char
*path, bool force)
(double) c.events_size / 1024.0 / 1024.0,
c.events_count);
+ cleanup_events(session);
perf_session__delete(session);
ctf_writer__cleanup(cw);
--
2.5.0
Re: arm qemu test failures due to 'driver-core: platform: probe of-devices only using list of compatibles'
On Mon, Feb 15, 2016 at 06:12:01PM +0100, Uwe Kleine-König wrote:
> Hello Greg,
>
> On Mon, Feb 15, 2016 at 08:49:37AM -0800, Greg Kroah-Hartman wrote:
> > On Mon, Feb 15, 2016 at 05:27:53PM +0100, Uwe Kleine-König wrote:
> > > Greg, can you drop this patch, or do you need a proper changelog for a
> > > revert? On top of that I'd then create a new patch which is more
> > > conservative.
> >
> > A hint as to what the git commit id was would be helpful, I can just
> > revert it based on that.
>
> This is 67d02a1bbb33 ("driver-core: platform: probe of-devices only
> using list of compatibles")
>
> If you need a log, something like:
>
> Reallow binding of of-devices by name
>
> It turned out that there are valid reasons (e.g. step by step
> conversion to device tree probing using auxdata) to bind
> of-instantiated devices to drivers by name. So revert to the
> original logic.
Now reverted, thanks for the text.
greg k-h
[PATCH 11/13] perf tools: Rename parse_events__free_terms() to parse_events_terms__delete()
From: Arnaldo Carvalho de Melo
To follow convention used in other tools/perf/ areas. Also remove the
need to check if it is NULL before calling the destructor, again, to
follow convention that goes back to free().
Cc: Alexei Starovoitov
Cc: He Kuang
cc: Jiri Olsa
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Wang Nan
Cc: Zefan Li
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/n/tip-w6owu7rb8a46gvunlinxa...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/arch/x86/util/intel-pt.c | 2 +-
tools/perf/util/parse-events.c | 7 ---
tools/perf/util/parse-events.h | 2 +-
tools/perf/util/parse-events.y | 8
4 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/tools/perf/arch/x86/util/intel-pt.c
b/tools/perf/arch/x86/util/intel-pt.c
index 6f7d453b0e32..a3395179c9ee 100644
--- a/tools/perf/arch/x86/util/intel-pt.c
+++ b/tools/perf/arch/x86/util/intel-pt.c
@@ -89,7 +89,7 @@ static int intel_pt_parse_terms_with_default(struct list_head
*formats,
*config = attr.config;
out_free:
- parse_events__free_terms(terms);
+ parse_events_terms__delete(terms);
return err;
}
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index d1b49ec7ae46..e5583fd4e7bd 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1386,8 +1386,7 @@ int parse_events_terms(struct list_head *terms, const
char *str)
return 0;
}
- if (data.terms)
- parse_events__free_terms(data.terms);
+ parse_events_terms__delete(data.terms);
return ret;
}
@@ -2078,8 +2077,10 @@ void parse_events_terms__purge(struct list_head *terms)
}
}
-void parse_events__free_terms(struct list_head *terms)
+void parse_events_terms__delete(struct list_head *terms)
{
+ if (!terms)
+ return;
parse_events_terms__purge(terms);
free(terms);
}
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index f90a04ccab39..53628bf3da67 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -115,7 +115,7 @@ int parse_events_term__sym_hw(struct parse_events_term
**term,
char *config, unsigned idx);
int parse_events_term__clone(struct parse_events_term **new,
struct parse_events_term *term);
-void parse_events__free_terms(struct list_head *terms);
+void parse_events_terms__delete(struct list_head *terms);
void parse_events_terms__purge(struct list_head *terms);
int parse_events__modifier_event(struct list_head *list, char *str, bool add);
int parse_events__modifier_group(struct list_head *list, char *event_mod);
diff --git a/tools/perf/util/parse-events.y b/tools/perf/util/parse-events.y
index ad379968d4c1..c0eac88ef474 100644
--- a/tools/perf/util/parse-events.y
+++ b/tools/perf/util/parse-events.y
@@ -218,7 +218,7 @@ PE_NAME '/' event_config '/'
ALLOC_LIST(list);
ABORT_ON(parse_events_add_pmu(data, list, $1, $3));
- parse_events__free_terms($3);
+ parse_events_terms__delete($3);
$$ = list;
}
|
@@ -246,7 +246,7 @@ PE_KERNEL_PMU_EVENT sep_dc
ALLOC_LIST(list);
ABORT_ON(parse_events_add_pmu(data, list, "cpu", head));
- parse_events__free_terms(head);
+ parse_events_terms__delete(head);
$$ = list;
}
|
@@ -266,7 +266,7 @@ PE_PMU_EVENT_PRE '-' PE_PMU_EVENT_SUF sep_dc
ALLOC_LIST(list);
ABORT_ON(parse_events_add_pmu(data, list, "cpu", head));
- parse_events__free_terms(head);
+ parse_events_terms__delete(head);
$$ = list;
}
@@ -285,7 +285,7 @@ value_sym '/' event_config '/'
ALLOC_LIST(list);
ABORT_ON(parse_events_add_numeric(data, list, type, config, $3));
- parse_events__free_terms($3);
+ parse_events_terms__delete($3);
$$ = list;
}
|
--
2.5.0
Applied "regulator: vexpress: rename vexpress regulator implementation" to the regulator tree
The patch
regulator: vexpress: rename vexpress regulator implementation
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 935514c961310558ee0767e73e678b85ac37a68d Mon Sep 17 00:00:00 2001
From: Sudeep Holla
Date: Fri, 29 Jan 2016 17:37:01 +
Subject: [PATCH] regulator: vexpress: rename vexpress regulator implementation
The vexpress regulator implementation is currently just called vexpress.
This is a problem because it clashes with another module with the same
name in hardware monitors.
This patch renames the vexpress regulator implementation to
vexpress-regulator so that there will be no clash in the module namespace.
Cc: Liviu Dudau
Cc: Lorenzo Pieralisi
Cc: Liam Girdwood
Cc: Mark Brown
Reported-by: Rusty Russell
Signed-off-by: Sudeep Holla
Signed-off-by: Mark Brown
---
drivers/regulator/Makefile | 2 +-
drivers/regulator/{vexpress.c => vexpress-regulator.c} | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename drivers/regulator/{vexpress.c => vexpress-regulator.c} (100%)
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index 980b194..755077a 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -98,7 +98,7 @@ obj-$(CONFIG_REGULATOR_TPS65910) += tps65910-regulator.o
obj-$(CONFIG_REGULATOR_TPS65912) += tps65912-regulator.o
obj-$(CONFIG_REGULATOR_TPS80031) += tps80031-regulator.o
obj-$(CONFIG_REGULATOR_TWL4030) += twl-regulator.o
-obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress.o
+obj-$(CONFIG_REGULATOR_VEXPRESS) += vexpress-regulator.o
obj-$(CONFIG_REGULATOR_WM831X) += wm831x-dcdc.o
obj-$(CONFIG_REGULATOR_WM831X) += wm831x-isink.o
obj-$(CONFIG_REGULATOR_WM831X) += wm831x-ldo.o
diff --git a/drivers/regulator/vexpress.c
b/drivers/regulator/vexpress-regulator.c
similarity index 100%
rename from drivers/regulator/vexpress.c
rename to drivers/regulator/vexpress-regulator.c
--
2.7.0
[PATCH 05/13] perf tools: Add comment explaining the repsep_snprintf function
From: Arnaldo Carvalho de Melo
Cc: Adrian Hunter
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Wang Nan
Link: http://lkml.kernel.org/n/tip-4j67nvlfwbnkg85b969ew...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/sort.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index de620f7f40f4..8b54ede7ec1f 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -28,7 +28,15 @@ int sort__has_socket = 0;
intsort__has_thread = 0;
enum sort_mode sort__mode = SORT_MODE__NORMAL;
-
+/*
+ * Replaces all occurrences of a char used with the:
+ *
+ * -t, --field-separator
+ *
+ * option, that uses a special separator character and don't pad with spaces,
+ * replacing all occurances of this separator in symbol names (and other
+ * output) with a '.' character, that thus it's the only non valid separator.
+*/
static int repsep_snprintf(char *bf, size_t size, const char *fmt, ...)
{
int n;
--
2.5.0
[GIT PULL 00/13] perf/core improvements and fixes
From: Arnaldo Carvalho de Melo Hi Ingo, Please consider pulling, - Arnaldo The following changes since commit a7636d9ecfa3ab7800a7c04c1f89378229eff609: kprobes: Optimize hot path by using percpu counter to collect 'nhit' statistics (2016-02-09 11:08:58 +0100) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git tags/perf-core-for-mingo for you to fetch changes up to 1ad826bad5bd0b6ccfb203f78c70302b764df0be: perf tests: Fix build on older systems where 'signal' is reserved (2016-02-15 17:33:26 -0300) perf/core improvements and fixes: User visible: - Do not print trailing spaces in the hists browser (top, report) to avoid line wrapping issues when long C++ demangled functions are sampled (Arnaldo Carvalho de Melo) - Allow 'perf config' to show --system or --user settings (Taeung Song) - Add better warning about the need to install the audit-lib-python package when using perf python scripts (Taeung Song) - Fix symbol resolution when kernel modules files are only in the build id cache (~/.debug) (Wang Nan) Build fixes: - Fix 'perf test' build on older systems where 'signal' is reserved (Arnaldo Carvalho de Melo) Infrastructure: - Free the terms list_head in parse_events__free_terms(), also unlink the entries when deleting them (Wang Nan) - Fix releasing event_class in 'perf data' fixing integration with libbabeltrace (Wang Nan) - Add EXTRA_LDFLAGS option to Makefile (Zubair Lutfullah Kakakhel) Signed-off-by: Arnaldo Carvalho de Melo Arnaldo Carvalho de Melo (6): perf tools: Add comment explaining the repsep_snprintf function perf hists: Do column alignment on the format iterator perf tools: Introduce parse_events_terms__purge() perf tools: Use perf_event_terms__purge() for non-malloced terms perf tools: Rename parse_events__free_terms() to parse_events_terms__delete() perf tests: Fix build on older systems where 'signal' is reserved Taeung Song (2): perf config: Add '--system' and '--user' options to select which config file is used perf python scripting: Append examples to err msg about audit-libs-python Wang Nan (4): perf symbols: Fix symbols searching for module in buildid-cache perf tools: Unlink entries from terms list perf tools: Free the terms list_head in parse_events__free_terms() perf data: Fix releasing event_class Zubair Lutfullah Kakakhel (1): perf build: Add EXTRA_LDFLAGS option to makefile tools/perf/Documentation/perf-config.txt | 14 ++- tools/perf/Makefile.perf | 2 + tools/perf/arch/x86/util/intel-pt.c| 2 +- tools/perf/builtin-config.c| 27 +++-- .../python/Perf-Trace-Util/lib/Perf/Trace/Util.py | 5 ++- tools/perf/tests/bp_signal.c | 12 +++--- tools/perf/tests/parse-events.c| 2 +- tools/perf/ui/browsers/hists.c | 27 - tools/perf/ui/stdio/hist.c | 1 + tools/perf/util/build-id.c | 44 ++ tools/perf/util/build-id.h | 1 + tools/perf/util/cache.h| 3 ++ tools/perf/util/config.c | 4 +- tools/perf/util/data-convert-bt.c | 18 + tools/perf/util/hist.c | 21 +++ tools/perf/util/hist.h | 5 +++ tools/perf/util/parse-events.c | 17 +++-- tools/perf/util/parse-events.h | 3 +- tools/perf/util/parse-events.y | 8 ++-- tools/perf/util/pmu.c | 2 +- tools/perf/util/sort.c | 23 +-- tools/perf/util/symbol.c | 4 ++ 22 files changed, 200 insertions(+), 45 deletions(-)
[PATCH 09/13] perf tools: Use perf_event_terms__purge() for non-malloced terms
From: Arnaldo Carvalho de Melo
In these two cases, a 'perf test' entry and in the PMU code the
list_head is on the stack, so we can't use perf_event__free_terms()
(soon to be renamed to perf_event_terms__delete()), because it will
free the list_head as well.
Acked-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: He Kuang
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Wang Nan
Cc: Zefan Li
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/n/tip-i956ryjhz97gnnqe8iqe7...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/parse-events.c | 2 +-
tools/perf/util/pmu.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/perf/tests/parse-events.c b/tools/perf/tests/parse-events.c
index abe8849d1d70..6648274f4601 100644
--- a/tools/perf/tests/parse-events.c
+++ b/tools/perf/tests/parse-events.c
@@ -1666,7 +1666,7 @@ static int test_term(struct terms_test *t)
}
ret = t->check(&terms);
- parse_events__free_terms(&terms);
+ parse_events_terms__purge(&terms);
return ret;
}
diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
index 41a9c875e492..cf59fbaee491 100644
--- a/tools/perf/util/pmu.c
+++ b/tools/perf/util/pmu.c
@@ -354,7 +354,7 @@ static int pmu_alias_terms(struct perf_pmu_alias *alias,
list_for_each_entry(term, &alias->terms, list) {
ret = parse_events_term__clone(&cloned, term);
if (ret) {
- parse_events__free_terms(&list);
+ parse_events_terms__purge(&list);
return ret;
}
list_add_tail(&cloned->list, &list);
--
2.5.0
[PATCH 08/13] perf tools: Introduce parse_events_terms__purge()
From: Arnaldo Carvalho de Melo
Purges 'struct parse_event_term' entries from a list_head.
Some users need this because they don't allocate space for the list
head, it maybe on the stack or embedded into some other struct.
Next patch will convert users that need just purging and then the
perf_events__free_terms() routine will free the list head as well,
finally being renamed to perf_events_terms__delete().
Acked-by: Jiri Olsa
Cc: Alexei Starovoitov
Cc: He Kuang
Cc: Masami Hiramatsu
Cc: Namhyung Kim
Cc: Wang Nan
Cc: Zefan Li
Cc: pi3or...@163.com
Link: http://lkml.kernel.org/n/tip-4w3zl4ifcl0ed0j4bu3tc...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/parse-events.c | 7 ++-
tools/perf/util/parse-events.h | 1 +
2 files changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 133c8d28f36c..668afdccfcca 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -2068,7 +2068,7 @@ int parse_events_term__clone(struct parse_events_term
**new,
term->err_term, term->err_val);
}
-void parse_events__free_terms(struct list_head *terms)
+void parse_events_terms__purge(struct list_head *terms)
{
struct parse_events_term *term, *h;
@@ -2078,6 +2078,11 @@ void parse_events__free_terms(struct list_head *terms)
}
}
+void parse_events__free_terms(struct list_head *terms)
+{
+ parse_events_terms__purge(terms);
+}
+
void parse_events_evlist_error(struct parse_events_evlist *data,
int idx, const char *str)
{
diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
index f1a6db107241..f90a04ccab39 100644
--- a/tools/perf/util/parse-events.h
+++ b/tools/perf/util/parse-events.h
@@ -116,6 +116,7 @@ int parse_events_term__sym_hw(struct parse_events_term
**term,
int parse_events_term__clone(struct parse_events_term **new,
struct parse_events_term *term);
void parse_events__free_terms(struct list_head *terms);
+void parse_events_terms__purge(struct list_head *terms);
int parse_events__modifier_event(struct list_head *list, char *str, bool add);
int parse_events__modifier_group(struct list_head *list, char *event_mod);
int parse_events_name(struct list_head *list, char *name);
--
2.5.0
Re: [PATCH 4/4] Drivers: hv: vmbus: avoid unneeded compiler optimizations in vmbus_wait_for_unload()
2016-02-12 16:42+0100, Vitaly Kuznetsov: > Message header is modified by the hypervisor and we read it in a loop, > we need to prevent compilers from optimizing accesses. There are no such > optimizations at this moment, this is just a future proof. > > Suggested-by: Radim Krcmar Reviewed-by: Radim Krčmář > Signed-off-by: Vitaly Kuznetsov
Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value
On Mon, Feb 15, 2016 at 9:38 PM, Arnd Bergmann wrote:
> On Monday 15 February 2016 21:56:42 Viresh Kumar wrote:
>> We are currently required to do two checks for regulator pointer:
>> IS_ERR() and IS_NULL().
>>
>> And multiple instances are reported, about both of these not being used
>> consistently and so resulting in crashes.
>>
>> Fix that by initializing regulator pointer with an error value and
>> checking it only against an error.
>>
>> This makes code consistent and efficient.
>
> There is usually something else wrong if you have to check for both.
> Why exactly do you need to check for both IS_ERR and NULL?
>
>> diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
>> index d7cd4e265766..146b6197d598 100644
>> --- a/drivers/base/power/opp/core.c
>> +++ b/drivers/base/power/opp/core.c
>> @@ -257,7 +257,7 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct
>> device *dev)
>> }
>>
>> reg = dev_opp->regulator;
>> - if (IS_ERR_OR_NULL(reg)) {
>> + if (IS_ERR(reg)) {
>> /* Regulator may not be required for device */
>> if (reg)
>> dev_err(dev, "%s: Invalid regulator (%ld)\n", __func__,
>> @@ -798,6 +798,9 @@ static struct device_opp *_add_device_opp(struct device
>> *dev)
>> of_node_put(np);
>> }
>>
>> + /* Set regulator to a non-NULL error value */
>> + dev_opp->regulator = ERR_PTR(-EFAULT);
>> +
>> /* Find clk for the device */
>> dev_opp->clk = clk_get(dev, NULL);
>> if (IS_ERR(dev_opp->clk)) {
>
> -EFAULT has a very specific meaning (accessing an invalid pointer from
> user space), I don't think you want that one.
Yeah, agreed.
That should be something like -ENXIO IMO.
Thanks,
Rafael
Re: [PATCH] arm64: dts: rockchip: fix the incorrect otp-out pin on rk3368
Hi Caesar, Am Montag, 15. Februar 2016, 11:30:58 schrieb Caesar Wang: > This patch fixes the incorrect Over-temperature protection pin. > since the rk3368 io list said the otp pin is gpio0a3. > > Anyway, that should be fixed in here. > > Signed-off-by: Caesar Wang applied to my dts branch for 4.6 Thanks Heiko
Re: [lxc-devel] CGroup Namespaces (v10)
On Fri, Feb 12, 2016 at 05:22:21PM -0600, Serge E. Hallyn wrote:
> On Fri, Feb 12, 2016 at 11:09:06AM -0500, Tejun Heo wrote:
> > Hello,
> >
> > On Fri, Feb 12, 2016 at 12:18:28AM +0100, Alban Crequy wrote:
> > > I just noticed commit c38c4597e4bf ("netfilter: implement xt_cgroup
> > > cgroup2 path match") which, as far as I understand, introduces a new
> > > userland facing API containing the full cgroup path. Does it mean that
> > > the cgroupns patchset should include cgroup path translation in
> > > xt_cgroup?
> >
> > I don't think so. None of netfilter configuration is namespaced in
> > any way. They're system-global by nature.
>
> I assume at some point you'll want the set ported onto for-4.6 or
> linux-next? My 2016-02-03/cgns set still cherrypick cleanly onto
> for-4.6 at the moment, but I haven't tried linux-next, and I haven't
> done build+test since 4.5-rc1 came out.
I'm getting the following on top of the current for-4.6. Can you
please look into it?
[kernel/cgroup.c:219:13: error: ‘cgroupns_operations’ undeclared here (not in a
function)
.ns.ops = &cgroupns_operations,
^
Thanks.
--
tejun
Re: [lxc-devel] CGroup Namespaces (v10)
On Mon, Feb 15, 2016 at 04:17:05PM -0500, Tejun Heo wrote: > I'm getting the following on top of the current for-4.6. Can you > please look into it? > > [kernel/cgroup.c:219:13: error: ‘cgroupns_operations’ undeclared here (not in > a function) > .ns.ops = &cgroupns_operations, >^ Never mind. That was me being stupid with trivial conflict resolution. Thanks. -- tejun
[RFC PATCH] sata_via: Apply WD workaround only when needed
Currently, workaround for broken WD drives is applied always, slowing
down all drives. And it has a bug - it's not applied after resume.
Apply the workaround only if the error really appears
(SErr == 0x1000500). This allows unaffected drives to run at full speed
(provided that no affected drive is connected to the controller).
It also fixes the suspend/resume problem.
The downside is that first error always appears in the log.
Unaffected drive (Hitachi HDS721680PLA380):
Before:
$ hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 160 MB in 3.01 seconds = 53.16 MB/sec
After:
$ hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 200 MB in 3.01 seconds = 66.47 MB/sec
Affected drive (WDC WD5003ABYX-18WERA0):
Before:
$ hdparm -t --direct /dev/sda
/dev/sda:
Timing O_DIRECT disk reads: 180 MB in 3.02 seconds = 59.51 MB/sec
After:
$ hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 156 MB in 3.03 seconds = 51.48 MB/sec
$ hdparm -t --direct /dev/sdb
/dev/sdb:
Timing O_DIRECT disk reads: 180 MB in 3.02 seconds = 59.64 MB/sec
The first hdparm is slower because of the error:
[ 80.964060] ata5.00: exception Emask 0x12 SAct 0x0 SErr 0x1000500 action 0x6
[ 80.964095] ata5.00: BMDMA stat 0x5
[ 80.964108] ata5: SError: { UnrecovData Proto TrStaTrns }
[ 80.964125] ata5.00: failed command: READ DMA EXT
[ 80.964143] ata5.00: cmd 25/00:90:00:00:00/00:04:00:00:00/e0 tag 0 dma
598016 in
res 51/84:af:df:00:00/84:03:00:00:00/e0 Emask 0x12 (ATA bus error)
[ 80.964173] ata5.00: status: { DRDY ERR }
[ 80.964185] ata5.00: error: { ICRC ABRT }
[ 80.964209] ata5: hard resetting link
[ 81.284056] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[ 81.300531] ata5.00: configured for UDMA/133
[ 81.300569] ata5: Incompatible drive (WD?): enabling workaround
[ 81.300598] ata5: EH complete
Signed-off-by: Ondrej Zary
---
drivers/ata/sata_via.c | 72 +---
1 file changed, 44 insertions(+), 28 deletions(-)
diff --git a/drivers/ata/sata_via.c b/drivers/ata/sata_via.c
index 17d31fc..65c9ab9 100644
--- a/drivers/ata/sata_via.c
+++ b/drivers/ata/sata_via.c
@@ -85,6 +85,7 @@ static void vt6420_bmdma_start(struct ata_queued_cmd *qc);
static int vt6421_pata_cable_detect(struct ata_port *ap);
static void vt6421_set_pio_mode(struct ata_port *ap, struct ata_device *adev);
static void vt6421_set_dma_mode(struct ata_port *ap, struct ata_device *adev);
+static void svia_error_handler(struct ata_port *ap);
static const struct pci_device_id svia_pci_tbl[] = {
{ PCI_VDEVICE(VIA, 0x5337), vt6420 },
@@ -124,6 +125,7 @@ static struct ata_port_operations vt6420_sata_ops = {
.freeze = svia_noop_freeze,
.prereset = vt6420_prereset,
.bmdma_start= vt6420_bmdma_start,
+ .error_handler = svia_error_handler,
};
static struct ata_port_operations vt6421_pata_ops = {
@@ -137,6 +139,7 @@ static struct ata_port_operations vt6421_sata_ops = {
.inherits = &svia_base_ops,
.scr_read = svia_scr_read,
.scr_write = svia_scr_write,
+ .error_handler = svia_error_handler,
};
static struct ata_port_operations vt8251_ops = {
@@ -536,6 +539,47 @@ static int vt8251_prepare_host(struct pci_dev *pdev,
struct ata_host **r_host)
return 0;
}
+static void svia_error_handler(struct ata_port *ap)
+{
+ u8 tmp8;
+ struct pci_dev *pdev = to_pci_dev(ap->host->dev);
+ struct ata_eh_context *ehc = &ap->link.eh_context;
+
+ ata_sff_error_handler(ap);
+ /*
+* vt6420/1 has problems talking to some drives. The following
+* is the fix from Joseph Chan .
+*
+* When host issues HOLD, device may send up to 20DW of data
+* before acknowledging it with HOLDA and the host should be
+* able to buffer them in FIFO. Unfortunately, some WD drives
+* send up to 40DW before acknowledging HOLD and, in the
+* default configuration, this ends up overflowing vt6421's
+* FIFO, making the controller abort the transaction with
+* R_ERR.
+*
+* Rx52[2] is the internal 128DW FIFO Flow control watermark
+* adjusting mechanism enable bit and the default value 0
+* means host will issue HOLD to device when the left FIFO
+* size goes below 32DW. Setting it to 1 makes the watermark
+* 64DW.
+*
+* https://bugzilla.kernel.org/show_bug.cgi?id=15173
+* http://article.gmane.org/gmane.linux.ide/46352
+* http://thread.gmane.org/gmane.linux.kernel/1062139
+*
+* As the fix slows down data transfer, apply it only if the error
+* actually appears (symptom: SErr == 0x1000500)
+*/
+ if (ehc->i.serror == 0x1000500) {
+ pci_read_config_byte(pdev, 0x52, &tmp8);
+
Re: [PATCH 6/6] soc: rockchip: power-domain: check the existing of regmap
Am Montag, 15. Februar 2016, 11:33:57 schrieb Shawn Lin:
> Check return value of syscon_node_to_regmap for
> rockchip_pm_domain_probe. If err value is returned, probe
> procedure should abort.
>
> Signed-off-by: Shawn Lin
applied to my armsoc/drivers branch for 4.6 with one change below
> ---
>
> drivers/soc/rockchip/pm_domains.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/soc/rockchip/pm_domains.c
> b/drivers/soc/rockchip/pm_domains.c index 534c589..3c4a44d 100644
> --- a/drivers/soc/rockchip/pm_domains.c
> +++ b/drivers/soc/rockchip/pm_domains.c
> @@ -402,6 +402,10 @@ static int rockchip_pm_domain_probe(struct
> platform_device *pdev) }
>
> pmu->regmap = syscon_node_to_regmap(parent->of_node);
> + if (IS_ERR(pmu->regmap)) {
> + dev_err(dev, "no regmap available\n");
> + return -ENODEV;
Instead of returning ENODEV I did go with
return PTR_ERR(pmu->regmap);
the error from trying to grab the regmap.
Heiko
[PATCH 1/2] ser_gigaset: bail out if gigaset_initcs() fails
The first substantial thing that ser_gigaset's open() operation does, is
calling gigaset_initcs(). That function is well behaved: if it fails it
cleans up after itself and returns NULL. So if we receive a NULL here we
might as well bail out directly. (Note that both the bas_gigaset driver
and the usb_gigaset driver already do that.)
Besides, in the error path tty->disc_data will be set to NULL. But
tty->disc_data hasn't been touched yet, so there's no reason to set it
to NULL.
Not-yet-signed-off-by: Paul Bolle
---
drivers/isdn/gigaset/ser-gigaset.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/isdn/gigaset/ser-gigaset.c
b/drivers/isdn/gigaset/ser-gigaset.c
index 2a506fe0c8a4..ae69ab89c5c0 100644
--- a/drivers/isdn/gigaset/ser-gigaset.c
+++ b/drivers/isdn/gigaset/ser-gigaset.c
@@ -514,10 +514,8 @@ gigaset_tty_open(struct tty_struct *tty)
/* allocate memory for our device state and initialize it */
cs = gigaset_initcs(driver, 1, 1, 0, cidmode, GIGASET_MODULENAME);
- if (!cs) {
- rc = -ENODEV;
- goto error;
- }
+ if (!cs)
+ return -ENODEV;
cs->dev = &cs->hw.ser->dev.dev;
cs->hw.ser->tty = tty;
--
2.4.3
ser_gigaset: fix memory leak
Hi Dmitry, I've cobbled together a two part series to fix the leak syzkaller uncovered in ser_gigaset. I'd really appreciate it if you'd unleash syzkaller on this small series one more time. Just to be sure that this also fixes the leak on your box and that it doesn't introduce neww horrors. Thanks, Paul Bolle
[PATCH 2/2] ser_gigaset: use container_of() instead of detour
The purpose of gigaset_device_release() is to kfree() the struct
ser_cardstate that contains our struct device. This is done via a bit of
a detour. First we make our struct device's driver_data point to the
container of our struct ser_cardstate (which is a struct cardstate). In
gigaset_device_release() we then retrieve that driver_data again. And
after that we finally kfree() the struct ser_cardstate that was saved in
the struct cardstate.
All of this can be achieved much easier by using container_of() to get
from our struct device to its container, struct ser_cardstate. Do so.
Note that the detour via driver_data broke down in commit 25cad69f21f5
("base/platform: Fix platform drivers with no probe callback"). That
commit reconnected our platform_device and our platform_driver again.
And one of the consequences of that fix was that
__device_release_driver() no longer is a NOP for our struct device but
actually does stuff again. One of the things it does, is setting our
driver_data to NULL. That, in turn, makes it impossible for
gigaset_device_release() to get to our struct cardstate. Which has the
net effect of leaking a struct ser_cardstate at every call of this
driver's tty close() operation. So using container_of() has the
additional benefit of actually working.
Reported-by: Dmitry Vyukov
Not-yet-signed-off-by: Paul Bolle
---
drivers/isdn/gigaset/ser-gigaset.c | 9 +
1 file changed, 1 insertion(+), 8 deletions(-)
diff --git a/drivers/isdn/gigaset/ser-gigaset.c
b/drivers/isdn/gigaset/ser-gigaset.c
index ae69ab89c5c0..6d40800f362c 100644
--- a/drivers/isdn/gigaset/ser-gigaset.c
+++ b/drivers/isdn/gigaset/ser-gigaset.c
@@ -373,13 +373,7 @@ static void gigaset_freecshw(struct cardstate *cs)
static void gigaset_device_release(struct device *dev)
{
- struct cardstate *cs = dev_get_drvdata(dev);
-
- if (!cs)
- return;
- dev_set_drvdata(dev, NULL);
- kfree(cs->hw.ser);
- cs->hw.ser = NULL;
+ kfree(container_of(dev, struct ser_cardstate, dev.dev));
}
/*
@@ -408,7 +402,6 @@ static int gigaset_initcshw(struct cardstate *cs)
cs->hw.ser = NULL;
return rc;
}
- dev_set_drvdata(&cs->hw.ser->dev.dev, cs);
tasklet_init(&cs->write_tasklet,
gigaset_modem_fill, (unsigned long) cs);
--
2.4.3
Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'
* Rafael J. Wysocki [160215 12:39]:
> On Mon, Feb 15, 2016 at 8:58 PM, Tony Lindgren wrote:
> > * Guenter Roeck [160215 11:41]:
> >> On 02/15/2016 11:01 AM, Tony Lindgren wrote:
> >> >
> >> >https://kernelci.org/boot/all/job/next/kernel/next-20160215/
> >> >
> >> >The SMP ones seem to fail with some regulator issues?
> >> >
> >>
> >> There is another problem, introduced with 6a0712f6f199e ("PM / OPP: Add
> >> dev_pm_opp_set_rate()"). The kernelci boot log for
> >> next-20160212:omap3-overo-tobi
> >> and others experience that problem.
> >>
> >> Essentially, the code now assumes that a CPU clock always has a voltage
> >> regulator attached to it, which is not correct. I sent out a patch to fix
> >> that problem a minute ago.
> >
> > Yes that fixed it thanks.
>
> Can you please also check if this alternative fix from Viresh works:
>
> https://patchwork.kernel.org/patch/8316611/
Yes that one too seems to fix the issue on SMP systems for
me:
Tested-by: Tony Lindgren
Regards,
Tony
Re: [PATCH 1/6] clk: rockchip: handle alt_parent in err cases when registering cpuclk
Am Montag, 15. Februar 2016, 11:33:15 schrieb Shawn Lin: > Add clk_disable_unprepare to handle cpuclk->alt_parent if > rockchip_clk_register_cpuclk fails. > > Signed-off-by: Shawn Lin applied to my clk branch for 4.6
Re: [PATCH 2/6] clk: rockchip: check grf when waiting pll lock
Am Montag, 15. Februar 2016, 11:33:25 schrieb Shawn Lin:
> rockchip_clk_get_grf pass on return value from
> syscon_regmap_lookup_by_phandle, so we check grf to
> make sure whether to do the following things or not.
>
> Signed-off-by: Shawn Lin
applied to my clk-branch for 4.6 with one change below
> ---
>
> drivers/clk/rockchip/clk-pll.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/rockchip/clk-pll.c
> b/drivers/clk/rockchip/clk-pll.c index b7e66c9..dddbc29 100644
> --- a/drivers/clk/rockchip/clk-pll.c
> +++ b/drivers/clk/rockchip/clk-pll.c
> @@ -90,10 +90,16 @@ static long rockchip_pll_round_rate(struct clk_hw *hw,
> */
> static int rockchip_pll_wait_lock(struct rockchip_clk_pll *pll)
> {
> - struct regmap *grf = rockchip_clk_get_grf();
> + struct regmap *grf;
> unsigned int val;
> int delay = 2400, ret;
>
> + grf = rockchip_clk_get_grf();
> + if (IS_ERR(grf)) {
> + pr_err("%s: grf regmap not available\n", __func__);
> + return -ENODEV;
I've changed that to PTR_ERR(grf), similar to the preexisting checks
Heiko
[PATCH v10 1/3] cpufreq: Add mechanism for registering utilization update callbacks
From: Rafael J. Wysocki
Introduce a mechanism by which parts of the cpufreq subsystem
("setpolicy" drivers or the core) can register callbacks to be
executed from cpufreq_update_util() which is invoked by the
scheduler's update_load_avg() on CPU utilization changes.
This allows the "setpolicy" drivers to dispense with their timers
and do all of the computations they need and frequency/voltage
adjustments in the update_load_avg() code path, among other things.
The update_load_avg() changes were suggested by Peter Zijlstra.
Signed-off-by: Rafael J. Wysocki
Acked-by: Viresh Kumar
---
Changes from v9:
- Move the additional RT/DL hooks back to update_curr_rt/dl() (Peter says
that's OK), but only call them if updating the current CPU's rq, update
the cpufreq_trigger_update() kerneldoc.
Changes from v8:
- Peter thinks that cpufreq hooks in update_curr_rt/dl() are overkill so
move them to task_tick_rt/dl() and enqueue_task_rt/dl() (in case RT/DL
tasks are only active between ticks), update the cpufreq_trigger_update()
kerneldoc.
Changes from v7
- cpufreq_trigger_update() has a kerneldoc describing it as a band-aid to
be replaced in the future and the comments next to its call sites ask
the reader to see that comment.
No functional changes.
Changes from v6:
- Steve suggested to use rq_clock() instead of rq_clock_task() as the time
argument for cpufreq_update_util() as that seems to be more suitable for
this purpose.
---
drivers/cpufreq/cpufreq.c | 45 +
include/linux/cpufreq.h | 34 ++
kernel/sched/deadline.c |4
kernel/sched/fair.c | 26 +-
kernel/sched/rt.c |4
kernel/sched/sched.h |1 +
6 files changed, 113 insertions(+), 1 deletion(-)
Index: linux-pm/include/linux/cpufreq.h
===
--- linux-pm.orig/include/linux/cpufreq.h
+++ linux-pm/include/linux/cpufreq.h
@@ -151,6 +151,36 @@ static inline bool policy_is_shared(stru
extern struct kobject *cpufreq_global_kobject;
#ifdef CONFIG_CPU_FREQ
+void cpufreq_update_util(u64 time, unsigned long util, unsigned long max);
+
+/**
+ * cpufreq_trigger_update - Trigger CPU performance state evaluation if needed.
+ * @time: Current time.
+ *
+ * The way cpufreq is currently arranged requires it to evaluate the CPU
+ * performance state (frequency/voltage) on a regular basis to prevent it from
+ * being stuck in a completely inadequate performance level for too long.
+ * That is not guaranteed to happen if the updates are only triggered from CFS,
+ * though, because they may not be coming in if RT or deadline tasks are active
+ * all the time (or there are RT and DL tasks only).
+ *
+ * As a workaround for that issue, this function is called by the RT and DL
+ * sched classes to trigger extra cpufreq updates to prevent it from stalling,
+ * but that really is a band-aid. Going forward it should be replaced with
+ * solutions targeted more specifically at RT and DL tasks.
+ */
+static inline void cpufreq_trigger_update(u64 time)
+{
+ cpufreq_update_util(time, ULONG_MAX, 0);
+}
+
+struct update_util_data {
+ void (*func)(struct update_util_data *data,
+u64 time, unsigned long util, unsigned long max);
+};
+
+void cpufreq_set_update_util_data(int cpu, struct update_util_data *data);
+
unsigned int cpufreq_get(unsigned int cpu);
unsigned int cpufreq_quick_get(unsigned int cpu);
unsigned int cpufreq_quick_get_max(unsigned int cpu);
@@ -162,6 +192,10 @@ int cpufreq_update_policy(unsigned int c
bool have_governor_per_policy(void);
struct kobject *get_governor_parent_kobj(struct cpufreq_policy *policy);
#else
+static inline void cpufreq_update_util(u64 time, unsigned long util,
+ unsigned long max) {}
+static inline void cpufreq_trigger_update(u64 time) {}
+
static inline unsigned int cpufreq_get(unsigned int cpu)
{
return 0;
Index: linux-pm/kernel/sched/sched.h
===
--- linux-pm.orig/kernel/sched/sched.h
+++ linux-pm/kernel/sched/sched.h
@@ -9,6 +9,7 @@
#include
#include
#include
+#include
#include "cpupri.h"
#include "cpudeadline.h"
Index: linux-pm/kernel/sched/fair.c
===
--- linux-pm.orig/kernel/sched/fair.c
+++ linux-pm/kernel/sched/fair.c
@@ -2824,7 +2824,8 @@ static inline void update_load_avg(struc
{
struct cfs_rq *cfs_rq = cfs_rq_of(se);
u64 now = cfs_rq_clock_task(cfs_rq);
- int cpu = cpu_of(rq_of(cfs_rq));
+ struct rq *rq = rq_of(cfs_rq);
+ int cpu = cpu_of(rq);
/*
* Track task load average for carrying it to new CPU after migrated,
and
@@ -2836,6 +2837,29 @@ static inline void update_load_avg(struc
if (update_cfs_rq_load_avg(now, cfs_rq) && up
Re: [PATCH] pinctrl: sunxi: set pin function as input on export
On Mon, Feb 8, 2016 at 3:37 PM, Krzysztof Adamski wrote: > Default function of a pin in sunxi SoCs is "disabled". By default gpios > exported by sysfs are set as input and indeed, when reading "direction" > file you will get "in". The "value" pin won't return proper value, > though, confusing user of this interface. > > This patch sets direction of a GPIO as input when exporting it. > > Signed-off-by: Krzysztof Adamski As maxime says it's not a sunxi problem. So maybe it is wrong to set pins to either input or output when exporting them, I suspect they should be exported as is. Also: the sysfs ABI is deprecated. I suggest you invest your time in working on the new chardev ABI. Yours, Linus Walleij
Re: [PATCH v2 1/4] locking/mutex: Add waiter parameter to mutex_optimistic_spin()
On 02/12/2016 03:23 PM, Peter Zijlstra wrote:
On Fri, Feb 12, 2016 at 12:32:12PM -0500, Waiman Long wrote:
This patch adds a new waiter parameter to the mutex_optimistic_spin()
function to prepare it to be used by a waiter-spinner that doesn't
need to go into the OSQ as there can only be one waiter-spinner which
is the head of the waiting queue.
Does not explain why..
static bool mutex_optimistic_spin(struct mutex *lock,
+ struct ww_acquire_ctx *ww_ctx,
+ const bool use_ww_ctx, int waiter)
{
struct task_struct *task = current;
+ bool acquired = false;
+ if (!waiter) {
+ if (!mutex_can_spin_on_owner(lock))
+ goto done;
Why doesn't the waiter have to check mutex_can_spin_on_owner() ?
The reason why regular spinner need to call mutex_can_spin_on_owner is
because we want to avoid the overhead of the OSQ if we can't spin. As
mutex_can_spin_on_owner() is similar to mutex_spin_on_owner(), the
waiter-spinner will exit spinning after calling mutex_spin_on_owner().
Cheers,
Longman
Re: remap_file_pages regression
On Mon, Feb 15, 2016 at 12:26 PM, Kirill A. Shutemov
wrote:
> On Mon, Feb 15, 2016 at 03:32:55AM +0200, Grazvydas Ignotas wrote:
>> Hi,
>>
>> since remap_file_pages() rework the following simple program fails.
>> I haven't actually bisected this, only know it worked on 3.19 at least
>> (I bought a new system now and need 4.2+ for hardware support).
>
> The patch below should fix the issue. Please test.
It works, thanks.
Tested-by: Grazvydas Ignotas
>
>> If you are curious, the program is an emulator and is using
>> remap_file_pages() to implement memory mirroring efficiently (and to
>> remap things during run time).
>
> Could you elaborate on this?
>
> Why creating file on tmpfs/shmem (using memfd_create() for example) plus
> plain mmap()s wouldn't work for you?
It works, but remap_file_pages() is just more convenient, you don't
need many mmap()/munmap() calls (less syscalls), and as the emulator
needs to reconfigure the mappings during runtime (it's not a one time
init thing), remap_file_pages() makes more sense. The reduced number
of VMAs of the past was also a benefit I guess.
Actually I'm not the author of the emulator in question, so I've asked
the author to comment:
--- quote ---
One of the things we do with remap_file_pages is a mapping for the
emulated system's VRAM. The system allows many different
configurations of several differently sized VRAM banks to a 16MB area
of address space. The banks are multiples of 16KB in size and their
allocations are also 16KB aligned. With remap_file_pages we can map
that entire space to an (in-memory) file and then arbitrarily map
chunks of it as desired. We have an mmap-based fallback, but it
requires us to manage a separate mmap for each 16KB region."
--- end of quote ---
Apparently the mentioned fallback was a compile time option, so I was
hit with the issue after upgrading my machine.
>
>
> Signed-off-by: Kirill A. Shutemov
Cc: stable?
Fixes: c8d78c182 (I guess?)
> Reported-by: Grazvydas Ignotas
> ---
> mm/mmap.c | 34 +-
> 1 file changed, 29 insertions(+), 5 deletions(-)
>
> diff --git a/mm/mmap.c b/mm/mmap.c
> index 2f2415a7a688..76d1ec29149b 100644
> --- a/mm/mmap.c
> +++ b/mm/mmap.c
> @@ -2664,12 +2664,29 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long,
> start, unsigned long, size,
> if (!vma || !(vma->vm_flags & VM_SHARED))
> goto out;
>
> - if (start < vma->vm_start || start + size > vma->vm_end)
> + if (start < vma->vm_start)
> goto out;
>
> - if (pgoff == linear_page_index(vma, start)) {
> - ret = 0;
> - goto out;
> + if (start + size > vma->vm_end) {
> + struct vm_area_struct *next;
> +
> + for (next = vma->vm_next; next; next = next->vm_next) {
> + /* hole between vmas ? */
> + if (next->vm_start != next->vm_prev->vm_end)
> + goto out;
> +
> + if (next->vm_file != vma->vm_file)
> + goto out;
> +
> + if (next->vm_flags != vma->vm_flags)
> + goto out;
> +
> + if (start + size <= next->vm_end)
> + break;
> + }
> +
> + if (!next)
> + goto out;
> }
>
> prot |= vma->vm_flags & VM_READ ? PROT_READ : 0;
> @@ -2679,9 +2696,16 @@ SYSCALL_DEFINE5(remap_file_pages, unsigned long,
> start, unsigned long, size,
> flags &= MAP_NONBLOCK;
> flags |= MAP_SHARED | MAP_FIXED | MAP_POPULATE;
> if (vma->vm_flags & VM_LOCKED) {
> + struct vm_area_struct *tmp;
> flags |= MAP_LOCKED;
> +
> /* drop PG_Mlocked flag for over-mapped range */
> - munlock_vma_pages_range(vma, start, start + size);
> + for (tmp = vma; tmp->vm_start >= start + size;
> + tmp = tmp->vm_next) {
> + munlock_vma_pages_range(tmp,
> + max(tmp->vm_start, start),
> + min(tmp->vm_end, start + size));
> + }
> }
>
> file = get_file(vma->vm_file);
> --
> Kirill A. Shutemov
Gražvydas
Re: [PATCH 02/14] clkdev: Remove clk_register_clkdevs()
Quoting Stephen Boyd (2016-02-08 17:45:29)
> Now that we've converted the only caller over to another clkdev
> API, remove this one.
>
> Cc: Andy Shevchenko
> Cc: Russell King
> Signed-off-by: Stephen Boyd
Looks good to me.
Regards,
Mike
> ---
> drivers/clk/clkdev.c | 27 ---
> include/linux/clkdev.h | 1 -
> 2 files changed, 28 deletions(-)
>
> diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
> index 779b6ff0c7ad..ae61f2e57048 100644
> --- a/drivers/clk/clkdev.c
> +++ b/drivers/clk/clkdev.c
> @@ -383,30 +383,3 @@ int clk_register_clkdev(struct clk *clk, const char
> *con_id,
> return cl ? 0 : -ENOMEM;
> }
> EXPORT_SYMBOL(clk_register_clkdev);
> -
> -/**
> - * clk_register_clkdevs - register a set of clk_lookup for a struct clk
> - * @clk: struct clk to associate with all clk_lookups
> - * @cl: array of clk_lookup structures with con_id and dev_id pre-initialized
> - * @num: number of clk_lookup structures to register
> - *
> - * To make things easier for mass registration, we detect error clks
> - * from a previous clk_register() call, and return the error code for
> - * those. This is to permit this function to be called immediately
> - * after clk_register().
> - */
> -int clk_register_clkdevs(struct clk *clk, struct clk_lookup *cl, size_t num)
> -{
> - unsigned i;
> -
> - if (IS_ERR(clk))
> - return PTR_ERR(clk);
> -
> - for (i = 0; i < num; i++, cl++) {
> - cl->clk_hw = __clk_get_hw(clk);
> - __clkdev_add(cl);
> - }
> -
> - return 0;
> -}
> -EXPORT_SYMBOL(clk_register_clkdevs);
> diff --git a/include/linux/clkdev.h b/include/linux/clkdev.h
> index 08bffcc466de..43a8c2e8ac29 100644
> --- a/include/linux/clkdev.h
> +++ b/include/linux/clkdev.h
> @@ -46,7 +46,6 @@ int clk_add_alias(const char *, const char *, const char *,
> struct device *);
>
> int clk_register_clkdev(struct clk *, const char *, const char *, ...)
> __printf(3, 4);
> -int clk_register_clkdevs(struct clk *, struct clk_lookup *, size_t);
>
> #ifdef CONFIG_COMMON_CLK
> int __clk_get(struct clk *clk);
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: [PATCH 03/14] clk: Add {devm_}clk_hw_{register,unregister}() APIs
Quoting Stephen Boyd (2016-02-08 17:45:30)
> We've largely split the clk consumer and provider APIs along
> struct clk and struct clk_hw, but clk_register() still returns a
> struct clk pointer for each struct clk_hw that's registered.
> Eventually we'd like to only allocate struct clks when there's a
> user, because struct clk is per-user now, so clk_register() needs
> to change.
>
> Let's add new APIs to register struct clk_hws, but this time
> we'll hide the struct clk from the caller by returning an int
> error code. Also add an unregistration API that takes the clk_hw
> structure that was passed to the registration API. This way
> provider drivers never have to deal with a struct clk pointer
> unless they're using the clk consumer APIs.
>
> Signed-off-by: Stephen Boyd
Looks good to me.
Regards,
Mike
> ---
> Documentation/driver-model/devres.txt | 1 +
> drivers/clk/clk.c | 86
> +++
> include/linux/clk-provider.h | 6 +++
> 3 files changed, 93 insertions(+)
>
> diff --git a/Documentation/driver-model/devres.txt
> b/Documentation/driver-model/devres.txt
> index 831a5363f6be..600e30bf52c5 100644
> --- a/Documentation/driver-model/devres.txt
> +++ b/Documentation/driver-model/devres.txt
> @@ -236,6 +236,7 @@ certainly invest a bit more effort into libata core
> layer).
> CLOCK
>devm_clk_get()
>devm_clk_put()
> + devm_clk_hw_register()
>
> DMA
>dmam_alloc_coherent()
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index b4db67a446c8..adaaead3639f 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -2613,6 +2613,22 @@ fail_out:
> }
> EXPORT_SYMBOL_GPL(clk_register);
>
> +/**
> + * clk_hw_register - register a clk_hw and return an error code
> + * @dev: device that is registering this clock
> + * @hw: link to hardware-specific clock data
> + *
> + * clk_hw_register is the primary interface for populating the clock tree
> with
> + * new clock nodes. It returns an integer equal to zero indicating success or
> + * less than zero indicating failure. Drivers must test for an error code
> after
> + * calling clk_hw_register().
> + */
> +int clk_hw_register(struct device *dev, struct clk_hw *hw)
> +{
> + return PTR_ERR_OR_ZERO(clk_register(dev, hw));
> +}
> +EXPORT_SYMBOL_GPL(clk_hw_register);
> +
> /* Free memory allocated for a clock. */
> static void __clk_release(struct kref *ref)
> {
> @@ -2714,11 +2730,26 @@ void clk_unregister(struct clk *clk)
> }
> EXPORT_SYMBOL_GPL(clk_unregister);
>
> +/**
> + * clk_hw_unregister - unregister a currently registered clk_hw
> + * @hw: hardware-specific clock data to unregister
> + */
> +void clk_hw_unregister(struct clk_hw *hw)
> +{
> + clk_unregister(hw->clk);
> +}
> +EXPORT_SYMBOL_GPL(clk_hw_unregister);
> +
> static void devm_clk_release(struct device *dev, void *res)
> {
> clk_unregister(*(struct clk **)res);
> }
>
> +static void devm_clk_hw_release(struct device *dev, void *res)
> +{
> + clk_hw_unregister(*(struct clk_hw **)res);
> +}
> +
> /**
> * devm_clk_register - resource managed clk_register()
> * @dev: device that is registering this clock
> @@ -2749,6 +2780,36 @@ struct clk *devm_clk_register(struct device *dev,
> struct clk_hw *hw)
> }
> EXPORT_SYMBOL_GPL(devm_clk_register);
>
> +/**
> + * devm_clk_hw_register - resource managed clk_hw_register()
> + * @dev: device that is registering this clock
> + * @hw: link to hardware-specific clock data
> + *
> + * Managed clk_hw_register(). Clocks returned from this function are
> + * automatically clk_hw_unregister()ed on driver detach. See
> clk_hw_register()
> + * for more information.
> + */
> +int devm_clk_hw_register(struct device *dev, struct clk_hw *hw)
> +{
> + struct clk_hw **hwp;
> + int ret;
> +
> + hwp = devres_alloc(devm_clk_hw_release, sizeof(*hwp), GFP_KERNEL);
> + if (!hwp)
> + return -ENOMEM;
> +
> + ret = clk_hw_register(dev, hw);
> + if (!ret) {
> + *hwp = hw;
> + devres_add(dev, hwp);
> + } else {
> + devres_free(hwp);
> + }
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(devm_clk_hw_register);
> +
> static int devm_clk_match(struct device *dev, void *res, void *data)
> {
> struct clk *c = res;
> @@ -2757,6 +2818,15 @@ static int devm_clk_match(struct device *dev, void
> *res, void *data)
> return c == data;
> }
>
> +static int devm_clk_hw_match(struct device *dev, void *res, void *data)
> +{
> + struct clk_hw *hw = res;
> +
> + if (WARN_ON(!hw))
> + return 0;
> + return hw == data;
> +}
> +
> /**
> * devm_clk_unregister - resource managed clk_unregister()
> * @clk: clock to unregister
> @@ -2771,6 +2841,22 @@ void devm_clk_unregister(struct device *dev, struct
> clk *clk)
> }
> EXPORT_SYMBOL_GPL(devm_clk_unregister);
>
> +/**
> + * devm_clk_hw_unregister - resource ma
Re: [PATCH 01/14] mfd: intel_quark_i2c_gpio: Use clkdev_create()
Quoting Stephen Boyd (2016-02-08 17:45:28)
> Convert this driver to use clkdev_create() instead of
> clk_register_clkdevs(). The latter API is only used by this driver,
> although this driver only allocates one clk to add anyway.
> Furthermore, this driver allocates the clk_lookup structure with
> devm, but clkdev_drop() will free that structure when passed,
> leading to a double free when this driver is removed. Clean it
> all up and pave the way for the removal of clk_register_clkdevs().
>
> Cc: Lee Jones
> Cc: Andy Shevchenko
> Cc: Russell King
> Signed-off-by: Stephen Boyd
Looks good to me.
Regards,
Mike
> ---
> drivers/mfd/intel_quark_i2c_gpio.c | 26 +-
> 1 file changed, 9 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/mfd/intel_quark_i2c_gpio.c
> b/drivers/mfd/intel_quark_i2c_gpio.c
> index 042137465300..bdc5e27222c0 100644
> --- a/drivers/mfd/intel_quark_i2c_gpio.c
> +++ b/drivers/mfd/intel_quark_i2c_gpio.c
> @@ -52,8 +52,6 @@
> /* The Quark I2C controller source clock */
> #define INTEL_QUARK_I2C_CLK_HZ 3300
>
> -#define INTEL_QUARK_I2C_NCLK 1
> -
> struct intel_quark_mfd {
> struct pci_dev *pdev;
> struct clk *i2c_clk;
> @@ -128,30 +126,24 @@ MODULE_DEVICE_TABLE(pci, intel_quark_mfd_ids);
> static int intel_quark_register_i2c_clk(struct intel_quark_mfd *quark_mfd)
> {
> struct pci_dev *pdev = quark_mfd->pdev;
> - struct clk_lookup *i2c_clk_lookup;
> struct clk *i2c_clk;
> - int ret;
> -
> - i2c_clk_lookup = devm_kcalloc(&pdev->dev, INTEL_QUARK_I2C_NCLK,
> - sizeof(*i2c_clk_lookup), GFP_KERNEL);
> - if (!i2c_clk_lookup)
> - return -ENOMEM;
> -
> - i2c_clk_lookup[0].dev_id = INTEL_QUARK_I2C_CONTROLLER_CLK;
>
> i2c_clk = clk_register_fixed_rate(&pdev->dev,
> INTEL_QUARK_I2C_CONTROLLER_CLK,
> NULL,
> CLK_IS_ROOT,
> INTEL_QUARK_I2C_CLK_HZ);
> + if (IS_ERR(i2c_clk))
> + return PTR_ERR(i2c_clk);
>
> - quark_mfd->i2c_clk_lookup = i2c_clk_lookup;
> quark_mfd->i2c_clk = i2c_clk;
> + quark_mfd->i2c_clk_lookup = clkdev_create(i2c_clk, NULL,
> +
> INTEL_QUARK_I2C_CONTROLLER_CLK);
>
> - ret = clk_register_clkdevs(i2c_clk, i2c_clk_lookup,
> - INTEL_QUARK_I2C_NCLK);
> - if (ret)
> - dev_err(&pdev->dev, "Fixed clk register failed: %d\n", ret);
> + if (!quark_mfd->i2c_clk_lookup) {
> + dev_err(&pdev->dev, "Fixed clk register failed\n");
> + return -ENOMEM;
> + }
>
> - return ret;
> + return 0;
> }
>
> static void intel_quark_unregister_i2c_clk(struct pci_dev *pdev)
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
>
Re: remap_file_pages regression
On Tue, Feb 16, 2016 at 12:08:34AM +0200, Grazvydas Ignotas wrote:
> On Mon, Feb 15, 2016 at 12:26 PM, Kirill A. Shutemov
> wrote:
> > On Mon, Feb 15, 2016 at 03:32:55AM +0200, Grazvydas Ignotas wrote:
> >> Hi,
> >>
> >> since remap_file_pages() rework the following simple program fails.
> >> I haven't actually bisected this, only know it worked on 3.19 at least
> >> (I bought a new system now and need 4.2+ for hardware support).
> >
> > The patch below should fix the issue. Please test.
>
> It works, thanks.
> Tested-by: Grazvydas Ignotas
>
> >
> >> If you are curious, the program is an emulator and is using
> >> remap_file_pages() to implement memory mirroring efficiently (and to
> >> remap things during run time).
> >
> > Could you elaborate on this?
> >
> > Why creating file on tmpfs/shmem (using memfd_create() for example) plus
> > plain mmap()s wouldn't work for you?
>
> It works, but remap_file_pages() is just more convenient, you don't
> need many mmap()/munmap() calls (less syscalls)
mmap(MAP_FIXED) would do munmap() for you.
> > Signed-off-by: Kirill A. Shutemov
>
> Cc: stable?
> Fixes: c8d78c182 (I guess?)
Right.
Cc: sta...@vger.kernel.org # v4.0+
Fixes: c8d78c1823f4 ("mm: replace remap_file_pages() syscall with emulation")
--
Kirill A. Shutemov
Re: [PATCH v8 4/8] ppc64 ftrace_with_regs configuration variables
On Mon, Feb 15, 2016 at 03:04:08PM +0100, Torsten Duwe wrote:
> If you use "-pg -mprofile-kernel", gcc seems to forget that, and omits the TOC
> load, for a similar assembler calling sequence.
>
> Looking at the code I can _understand_ why this is so, but my GCC knowledge
> is not that deep that I could easily _fix_ this reliably.
Nonetheless, here's a proposal.
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -25154,6 +25154,10 @@ rs6000_emit_prologue (void)
{
cfun->machine->r2_setup_needed = df_regs_ever_live_p (TOC_REGNUM);
+ /* Profiling _will_ generate a call to a global _mcount. */
+ if (crtl->profile)
+ cfun->machine->r2_setup_needed = true;
+
/* With -mminimal-toc we may generate an extra use of r2 below. */
if (TARGET_TOC && TARGET_MINIMAL_TOC && get_pool_size () != 0)
cfun->machine->r2_setup_needed = true;
Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'
On 15 February 2016 at 17:05, Guenter Roeck wrote: > I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace > timers with utilization update callbacks' with next-20160215. An example > crash log and bisect results are attached below. > > Please let me know if there is anything I can do to help tracking down > the problem. > > Thanks, > Guenter > > --- > > Building arm:beagle:multi_v7_defconfig:omap3-beagle ... running . failed > (crashed) > > qemu log: You're using the QEMU beagle board emulation? Can I ask which QEMU you're using (qemu-linaro?). If the OMAP3 emulation is still actively useful to people I might have another stab at getting it into upstream QEMU some day... thanks -- PMM
Re: [PATCH v2] phy: marvell: Fix and unify reg-init behavior
Hi Fabio,
On Mon, Feb 15, 2016 at 06:54:29PM -0200, Fabio Estevam wrote:
> On Mon, Feb 15, 2016 at 6:01 PM, Clemens Gruber
> wrote:
>
> > +static int marvell_config_init(struct phy_device *phydev)
> > +{
> > + int err;
> > +
> > + /* Set registers from marvell,reg-init DT property */
> > + err = marvell_of_reg_init(phydev);
> > + if (err < 0)
> > + return err;
> > +
> > + return 0;
> > }
>
> Couldn't this be replaced by
>
> return marvell_of_reg_init(phydev); ?
I wanted to add some missing errata fixes from the Marvell Release Notes
into that function (in the near future).
But you are right, I should probably not change things preemptively.
I'll send a v3 with that part replaced!
Thanks,
Clemens
[PATCH] ACPI / video: remove unused device_decode
From: Colin Ian King
device_decode is now no longer used, so we may as well remove it.
Fixes gcc 6 warning:
drivers/acpi/acpi_video.c:221:19: warning: ‘device_decode’ defined
but not used [-Wunused-const-variable]
static const char device_decode[][30] = {
^
Signed-off-by: Colin Ian King
---
drivers/acpi/acpi_video.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index a76f8be..4361bc9 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -218,13 +218,6 @@ struct acpi_video_device {
struct thermal_cooling_device *cooling_dev;
};
-static const char device_decode[][30] = {
- "motherboard VGA device",
- "PCI VGA device",
- "AGP VGA device",
- "UNKNOWN",
-};
-
static void acpi_video_device_notify(acpi_handle handle, u32 event, void
*data);
static void acpi_video_device_rebind(struct acpi_video_bus *video);
static void acpi_video_device_bind(struct acpi_video_bus *video,
--
2.7.0
Re: [PATCH 4/6] clk: rockchip: don't return NULL when registering mmc branch fails
Am Montag, 15. Februar 2016, 11:33:41 schrieb Shawn Lin: > Avoid return NULL if rockchip_clk_register_mmc fails, otherwise > rockchip_clk_register_branches print "unknown clock type". The acutal > case is that it's a known clock type but we fail to regiser it, which > may makes user confuse the reason of failure. > > Signed-off-by: Shawn Lin applied to my clk-branch for 4.6
Re: [PATCH 3/6] clk: rockchip: don't return NULL when registering inverter fails
Am Montag, 15. Februar 2016, 11:33:33 schrieb Shawn Lin: > Avoid return NULL if rockchip_clk_register_inverter fails, otherwise > rockchip_clk_register_branches print "unknown clock type". The acutal > case is that it's a known clock type but we fail to regiser it, which > may makes user confuse the reason of failure. > > Signed-off-by: Shawn Lin applied to my clk-branch for 4.6
Re: [PATCH 5/6] clk: rockchip: fix coding style for clk-cpu.c
Am Montag, 15. Februar 2016, 11:33:50 schrieb Shawn Lin: > Fix the issue reported by checkpatch: > ERROR: space prohibited before that ',' (ctx:WxW) > + writel(clksel->val , cpuclk->reg_base + clksel->reg); > > Signed-off-by: Shawn Lin applied to my clk-branch for 4.6
[PATCH v3] phy: marvell: Fix and unify reg-init behavior
For the Marvell 88E1510, marvell_of_reg_init was called too late, in the
config_aneg function.
Since commit 113c74d83eef ("net: phy: turn carrier off on phy attach"),
this lead to the link not coming up at boot anymore, due to the phy
state machine being stuck at waiting for interrupts (off by default on
the 88E1510).
For seven other Marvell PHYs, marvell_of_reg_init was not called at all.
Add a generic marvell_config_init function, which in turn calls
marvell_of_reg_init.
PHYs, which already have a specific config_init function with a call to
marvell_of_reg_init, are left untouched. The generic marvell_config_init
function is called for all the others, to get consistent behavior across
all Marvell PHYs.
Signed-off-by: Clemens Gruber
---
Changes from v2:
- Simplified marvell_config_init (No preemptive error handling)
---
drivers/net/phy/marvell.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/marvell.c b/drivers/net/phy/marvell.c
index e3eb964..ab1d0fc 100644
--- a/drivers/net/phy/marvell.c
+++ b/drivers/net/phy/marvell.c
@@ -446,6 +446,12 @@ static int m88e1510_config_aneg(struct phy_device *phydev)
if (err < 0)
return err;
+ return 0;
+}
+
+static int marvell_config_init(struct phy_device *phydev)
+{
+ /* Set registers from marvell,reg-init DT property */
return marvell_of_reg_init(phydev);
}
@@ -495,7 +501,7 @@ static int m88e1116r_config_init(struct phy_device *phydev)
mdelay(500);
- return 0;
+ return marvell_config_init(phydev);
}
static int m88e3016_config_init(struct phy_device *phydev)
@@ -514,7 +520,7 @@ static int m88e3016_config_init(struct phy_device *phydev)
if (reg < 0)
return reg;
- return 0;
+ return marvell_config_init(phydev);
}
static int m88e_config_init(struct phy_device *phydev)
@@ -1078,6 +1084,7 @@ static struct phy_driver marvell_drivers[] = {
.features = PHY_GBIT_FEATURES,
.probe = marvell_probe,
.flags = PHY_HAS_INTERRUPT,
+ .config_init = &marvell_config_init,
.config_aneg = &marvell_config_aneg,
.read_status = &genphy_read_status,
.ack_interrupt = &marvell_ack_interrupt,
@@ -1149,6 +1156,7 @@ static struct phy_driver marvell_drivers[] = {
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
+ .config_init = &marvell_config_init,
.config_aneg = &m88e1121_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
@@ -1167,6 +1175,7 @@ static struct phy_driver marvell_drivers[] = {
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
+ .config_init = &marvell_config_init,
.config_aneg = &m88e1318_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
@@ -1259,6 +1268,7 @@ static struct phy_driver marvell_drivers[] = {
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
+ .config_init = &marvell_config_init,
.config_aneg = &m88e1510_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
@@ -1277,6 +1287,7 @@ static struct phy_driver marvell_drivers[] = {
.features = PHY_GBIT_FEATURES,
.flags = PHY_HAS_INTERRUPT,
.probe = marvell_probe,
+ .config_init = &marvell_config_init,
.config_aneg = &m88e1510_config_aneg,
.read_status = &marvell_read_status,
.ack_interrupt = &marvell_ack_interrupt,
--
2.7.1
Re: [PATCH v5 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver
On Wed, Feb 10, 2016 at 2:23 PM, Andrew Duggan wrote: > This is the v5 patch series which fixes the issues identified by kbuild > and coccinelle in the previous patch series. These include: > > - Using ARRAY_SIZE instead of a custom macro to calculate the size of the > function handler array. > - Remove setting the .owner field for the driver in rmi_i2c and rmi_spi > since the i2c-core and spi set that field. > - Fix if statment in rmi_f30 which was testing has_led twice instead of > testing has_gpio. > > Thanks, > Andrew > > Andrew Duggan (10): > Input: synaptics-rmi4: Add support for Synaptics RMI4 devices > Input: synaptics-rmi4: Add I2C transport driver > Input: synaptics-rmi4: Add device tree support for RMI4 I2C devices > Input: synaptics-rmi4: Add support for 2D sensors and F11 > Input: synaptics-rmi4: Add device tree support for 2d sensors and F11 > Input: synaptics-rmi4: Add support for F12 > Input: synaptics-rmi4: Add support for F30 > Input: synaptics-rmi4: Add SPI transport driver > Input: synaptics-rmi4: Add device tree support to the SPI transport > driver > HID: rmi: Make hid-rmi a transport driver for synaptics-rmi4 > My rmi4 device is powered by two regulators that are left disabled by the boot, so I have a patch to acquire those and toggle them appropriately. I plan to send that out once your patches lands. Tested-by: Bjorn Andersson Regards, Bjorn
[PATCH] net-sysfs: remove unused fmt_long_hex
From: Colin Ian King
Ever since commit 04ed3e741d0f133e02bed7fa5c98edba128f90e7
("net: change netdev->features to u32") the format string
fmt_long_hex has not been used, so we may as well remove it.
Signed-off-by: Colin Ian King
---
net/core/net-sysfs.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/core/net-sysfs.c b/net/core/net-sysfs.c
index b6c8a66..e326707 100644
--- a/net/core/net-sysfs.c
+++ b/net/core/net-sysfs.c
@@ -29,7 +29,6 @@
#ifdef CONFIG_SYSFS
static const char fmt_hex[] = "%#x\n";
-static const char fmt_long_hex[] = "%#lx\n";
static const char fmt_dec[] = "%d\n";
static const char fmt_ulong[] = "%lu\n";
static const char fmt_u64[] = "%llu\n";
--
2.7.0
Re: [PATCH v3 0/6] alienware-wmi: new platform and feature support
On 02/07/2016 02:05 PM, Darren Hart wrote: > On Tue, Feb 02, 2016 at 03:38:51PM -0600, Mario Limonciello wrote: >> I've got some extensions for the alienware-wmi driver that have >> been introduced for a few new platforms and can be controlled via the WMI >> interface. > Thanks Mario, and apologies for the delay. This appears functionally correct > at > each patch. There were still a couple minor line wrapping and comment block > formatting issues, but given the time delay, I just took care of those myself > and annotated it in the commit messages. These are now queued to testing. > > If you would like to verify my changes, they are available in the testing > branch > of my tree. > Everything looks good, thanks!
Re: [RFC] component: Fix: Unassign components' masters if bringing up master fails
On Mon, Feb 15, 2016 at 07:32:02PM +, Jon Medhurst (Tixy) wrote: > It seems to me that for other error cases (that don't result in deletion > of objects) we would want to leave the references between components and > masters intact once they have been created. Indeed we do - because we want to avoid having to redo the matching work each and every time we try to bring up the master. It's needless expense to keep re-running all the matches every time. > The other components or master should subsequently get cleaned up by > calling component_del() or component_master_del(), which take care of > updating the relevant references between components and master. Correct. > For component_master_del this is not immediately obvious, but > take_down_master calls devres_release_group which causes > devm_component_match_release to be called. Also correct. For component_master_del(), the list of components will be going away, so there's no point cleaning that list (it's freed when the device model releases its devres group.) However, the components themselves must not be left pointing at the freed memory, otherwise they'll effectively be marked "in-use" by a non-existent master - that's what "free_master()" is about - ensuring that when 'struct master' is freed, there are no components left pointing at the to-be-freed master device. -- RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/ FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up according to speedtest.net.
Re: [PATCH] ARM: dts: Move syscon reboot/poweroff to common dtsi for Exynos
On 15.02.2016 22:38, Javier Martinez Canillas wrote: >> >> In some of the DTSI this was under "soc" node, not at top-level. >> Unfortunately we do not have consistency here - some DTSI have "soc", > > Yes, I noticed this but as you said not all DTSI have a soc node > and that's why I made it top level in the DTSI. > >> some not. Anyway I think we should move to "soc" version. >> > > Not sure I'm following, did you mean to do it as a follow up or > to add a soc node for the missing DTSI as a part of this series? I meant to send a v2 with this under "soc" node even though on some DTS we do not have the "soc". Optional follow up would be to make DTS consistent and move nodes under "soc"... but that would be also a lot of churn. Best regards, Krzysztof
Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count
On Mon, Feb 15, 2016 at 10:19:54AM -0800, Daniel Walker wrote: > On 02/14/2016 01:18 PM, Dave Chinner wrote: > >On Fri, Feb 12, 2016 at 12:14:39PM -0800, Daniel Walker wrote: > >>From: Khalid Mughal > >> > >>Currently there is no way to figure out the droppable pagecache size > >>from the meminfo output. The MemFree size can shrink during normal > >>system operation, when some of the memory pages get cached and is > >>reflected in "Cached" field. Similarly for file operations some of > >>the buffer memory gets cached and it is reflected in "Buffers" field. > >>The kernel automatically reclaims all this cached & buffered memory, > >>when it is needed elsewhere on the system. The only way to manually > >>reclaim this memory is by writing 1 to /proc/sys/vm/drop_caches. But > >>this can have performance impact. Since it discards cached objects, > >>it may cause high CPU & I/O utilization to recreate the dropped > >>objects during heavy system load. > >>This patch computes the droppable pagecache count, using same > >>algorithm as "vm/drop_caches". It is non-destructive and does not > >>drop any pages. Therefore it does not have any impact on system > >>performance. The computation does not include the size of > >>reclaimable slab. > >Why, exactly, do you need this? You've described what the patch > >does (i.e. redundant, because we can read the code), and described > >that the kernel already accounts this reclaimable memory elsewhere > >and you can already read that and infer the amount of reclaimable > >memory from it. So why isn't that accounting sufficient? > > We need it to determine accurately what the free memory in the > system is. If you know where we can get this information already > please tell, we aren't aware of it. For instance /proc/meminfo isn't > accurate enough. What you are proposing isn't accurate, either, because it will be stale by the time the inode cache traversal is completed and the count returned to userspace. e.g. pages that have already been accounted as droppable can be reclaimed or marked dirty and hence "unreclaimable". IOWs, the best you are going to get is an approximate point-in-time indication of how much memory is available for immediate reclaim. We're never going to get an accurate measure in userspace unless we accurately account for it in the kernel itself. Which, I think it has already been pointed out, is prohibitively expensive so isn't done. As for a replacement, looking at what pages you consider "droppable" is really only file pages that are not under dirty or under writeback. i.e. from /proc/meminfo: Active(file): 220128 kB Inactive(file):60232 kB Dirty: 0 kB Writeback: 0 kB i.e. reclaimable file cache = Active + inactive - dirty - writeback. And while you are there, when you drop slab caches: SReclaimable: 66632 kB some amount of that may be freed. No guarantees can be made about the amount, though. Cheers, Dave. -- Dave Chinner da...@fromorbit.com
Re: [PATCH] gpio: tps65086: Add GPO driver for the TPS65086 PMIC
On Thu, Feb 11, 2016 at 10:20 AM, Lee Jones wrote: > Very well, applied. > > I also know Linus W likes dicing with death, so this is going into my > main branch. As this is a new driver, it shouldn't be an issue; Haha as long as there are no collisions in Makefile or Kconfig it should work out just fine I think. If something blows up in -next we can set up an immutable branch. Yours, Linus Walleij
Re: [PATCH V8 5/8] gpio: add DT binding doc for gpio of PMIC max77620/max20024
On Thu, Feb 11, 2016 at 12:56 PM, Laxman Dewangan wrote: > Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins > which act as GPIO as well as special function mode. > > Add DT binding document to support these pins in GPIO > mode via GPIO framework. > > Signed-off-by: Laxman Dewangan > Acked-by: Rob Herring Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH V8 3/8] pinctrl: add DT binding doc for pincontrol of PMIC max77620/max20024
On Thu, Feb 11, 2016 at 12:56 PM, Laxman Dewangan wrote: > Maxim Semiconductor's PMIC MAX77620/MAX20024 has 8 GPIO pins > which act as GPIO as well as special function mode. > > Add DT binding document to configure pins in function mode as > well as pin configuration parameters. > > Signed-off-by: Laxman Dewangan > Acked-by: Rob Herring Acked-by: Linus Walleij Yours, Linus Walleij
Re: [PATCH V8 6/8] gpio: max77620: add gpio driver for MAX77620/MAX20024
On Thu, Feb 11, 2016 at 12:56 PM, Laxman Dewangan wrote: > MAXIM Semiconductor's PMIC, MAX77620/MAX20024 has 8 GPIO > pins. It also supports interrupts from these pins. > > Add GPIO driver for these pins to control via GPIO APIs. > > Signed-off-by: Laxman Dewangan > Reviewed-by: Linus Walleij (...) Nit and no big deal: > +#include should be enough. Yours, Linus Walleij
[PATCH] x86/cpufeature: Speedup cpu_feature_enabled()
From: Borislav Petkov When gcc cannot do constant folding for this macro, it falls back to cpu_has(). But static_cpu_has() is optimal and it works at all times now. So use it and speedup the fallback case. Before we had this: mov0x99d674(%rip),%rdx# 81b0d9f4 shr$0x2e,%rdx and$0x1,%edx jne811704e9 After alternatives patching, it turns into: jmp0x81170390 nopl (%rax) ... callq 81056e00 81170390: mov0x170(%r12),%rdi Signed-off-by: Borislav Petkov Cc: Joerg Roedel --- arch/x86/include/asm/cpufeature.h | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/x86/include/asm/cpufeature.h b/arch/x86/include/asm/cpufeature.h index 9fba7a5dd24a..68e4e8258b84 100644 --- a/arch/x86/include/asm/cpufeature.h +++ b/arch/x86/include/asm/cpufeature.h @@ -88,8 +88,7 @@ extern const char * const x86_bug_flags[NBUGINTS*32]; * is not relevant. */ #define cpu_feature_enabled(bit) \ - (__builtin_constant_p(bit) && DISABLED_MASK_BIT_SET(bit) ? 0 : \ -cpu_has(&boot_cpu_data, bit)) + (__builtin_constant_p(bit) && DISABLED_MASK_BIT_SET(bit) ? 0 : static_cpu_has(bit)) #define boot_cpu_has(bit) cpu_has(&boot_cpu_data, bit) -- 2.3.5
Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'
On 02/15/2016 02:29 PM, Peter Maydell wrote: On 15 February 2016 at 17:05, Guenter Roeck wrote: I see crashes in various arm qemu tests due to 'cpufreq: governor: Replace timers with utilization update callbacks' with next-20160215. An example crash log and bisect results are attached below. Please let me know if there is anything I can do to help tracking down the problem. Thanks, Guenter --- Building arm:beagle:multi_v7_defconfig:omap3-beagle ... running . failed (crashed) qemu log: You're using the QEMU beagle board emulation? Can I ask which QEMU you're using (qemu-linaro?). If the OMAP3 emulation is still actively useful to people I might have another stab at getting it into upstream QEMU some day... Yes, I use qemu-linaro for those tests. Is it useful ? Obviously for me, yes. It lets me test images in qemu, and I don't need real hardware to run those tests. That means that I don't depend on the hardware really working, and I am not hosed if the hardware breaks down and I don't have a replacement. Plus, of course, I don't need a lab with 90+ pieces of hardware. Guenter
Re: [PATCH 2/4] mfd: max77686: Use module_i2c_driver() instead of subsys initcall
On 16.02.2016 00:21, Javier Martinez Canillas wrote: > Hello Krzysztof, > > On 02/15/2016 03:54 AM, Krzysztof Kozlowski wrote: >> On 12.02.2016 13:30, Javier Martinez Canillas wrote: >>> The driver's init and exit function don't do anything besides adding and >>> deleting the I2C driver so the module_i2c_driver() macro could be used. >>> >>> Currently is not being used because the driver is initialized at subsys >>> initcall level, claiming that this is done to allow consumers devices to >>> use the resources provided by this driver. But dependencies should be in >>> the DT and consumers drivers should not rely in the registration order. >>> >>> Signed-off-by: Javier Martinez Canillas >>> --- >>> >>> drivers/mfd/max77686.c | 13 + >>> 1 file changed, 1 insertion(+), 12 deletions(-) >>> >> >> In the past not all dependencies supported deferred probing so such >> ordering was required. >> >> I don't like the "dependencies should be in DT" reason for the change... >> because it is kind of wishful thinking. Yeah, the dependencies should be >> in DT, but are they? >> >> Instead *please check it* and write: >> "Dependencies are in DT so manual ordering of init calls is not >> necessary any more". >> > > For the max77802 I know that's the case since the only two DTS in mainline > that use it are the Peach Pit and Pi and I'm very familiar with those two. > > But I wonder how can I check that this is the case for the max77686. Most > DTS in mainline have nodes that use some clocks and regulators provided by > the PMIC, only arch/arm/boot/dts/exynos5250-smdk5250.dts doesn't have one > of the regulators as input supply or clock consumer defined. +Cc Marek Szyprowski, who may know a lot more about dependencies between these. I wouldn't care for drivers not taking references to regulators/clocks. Most of necessary regulators and clocks are turned on by bootloader or by default values in PMIC. This means that later probing of PMIC shouldn't influence drivers which are not using it. The remaining problem was unsupported deferred probing by some of the drivers using regulators/clocks (drivers being consumers of regulators or clocks). AFAIR one of example was USB OTG. By "please check" in this case I mean - look if every regulator/clock consumer using stuff exposed by PMIC, supports properly deferred probing. > For the clock, I guess the RTC is just broken since it's using the s3c6410 > controller that requires a source clock and this is not defined. > > Now the question is if it doesn't really need the regulators or is that > the DTS isn't correctly defined and some drivers were relying on the MFD > and regulator drivers to be registered at subsys initcall level? I suspect the consumers are not defined in DTS. However I wouldn't care about such issue. If there is no consumer, then probe order shouldn't matter... > >> My fast tests of this patch shown that it works good... but some more >> thorough tests should be done. >> > > What do you suggest? The drivers now support deferred probing but as said, > I don't know how I can be sure that drivers aren't missing input supplies > and relying in regulators being registered early and marked as always-on. So test it... You are posting a small improvement without any important benefit but in the same time it might broke existing platforms. Perfect is the enemy of the good (or if it ain't broken, don't touch it), so please be sure that max77686 still works. :) Best regards, Krzysztof
Re: [BUG] random kernel crashes after THP rework on s390 (maybe also on PowerPC and ARM)
On Mon, Feb 15, 2016 at 07:37:02PM +0100, Gerald Schaefer wrote: > On Mon, 15 Feb 2016 13:31:59 +0200 > "Kirill A. Shutemov" wrote: > > > On Sat, Feb 13, 2016 at 12:58:31PM +0100, Sebastian Ott wrote: > > > > > > On Sat, 13 Feb 2016, Kirill A. Shutemov wrote: > > > > Could you check if revert of fecffad25458 helps? > > > > > > I reverted fecffad25458 on top of 721675fcf277cf - it oopsed with: > > > > > > ¢ 1851.721062! Unable to handle kernel pointer dereference in virtual > > > kernel address space > > > ¢ 1851.721075! failing address: TEID: 0483 > > > ¢ 1851.721078! Fault in home space mode while using kernel ASCE. > > > ¢ 1851.721085! AS:00d5c007 R3:0007 S:a800 > > > P:003d > > > ¢ 1851.721128! Oops: 0004 ilc:3 ¢#1! PREEMPT SMP DEBUG_PAGEALLOC > > > ¢ 1851.721135! Modules linked in: bridge stp llc btrfs mlx4_ib mlx4_en > > > ib_sa ib_mad vxlan xor ip6_udp_tunnel ib_core udp_tunnel ptp pps_core > > > ib_addr ghash_s390raid6_pq prng ecb aes_s390 mlx4_core des_s390 > > > des_generic genwqe_card sha512_s390 sha256_s390 sha1_s390 sha_common > > > crc_itu_t dm_mod scm_block vhost_net tun vhost eadm_sch macvtap macvlan > > > kvm autofs4 > > > ¢ 1851.721183! CPU: 7 PID: 256422 Comm: bash Not tainted > > > 4.5.0-rc3-00058-g07923d7-dirty #178 > > > ¢ 1851.721186! task: 7fbfd290 ti: 8c604000 task.ti: > > > 8c604000 > > > ¢ 1851.721189! Krnl PSW : 0704d0018000 0045d3b8 > > > (__rb_erase_color+0x280/0x308) > > > ¢ 1851.721200!R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:1 > > > PM:0 EA:3 > > >Krnl GPRS: 0001 0020 > > > bd07eff1 > > > ¢ 1851.721205!0027ca10 > > > 83e45898 77b61198 > > > ¢ 1851.721207!7ce1a490 bd07eff0 > > > 7ce1a548 0027ca10 > > > ¢ 1851.721210!bd07c350 bd07eff0 > > > 8c607aa8 8c607a68 > > > ¢ 1851.721221! Krnl Code: 0045d3aa: e3c0d0080024 stg > > > %%r12,8(%%r13) > > > 0045d3b0: b9040039 lgr > > > %%r3,%%r9 > > > #0045d3b4: a53b0001 oill > > > %%r3,1 > > > >0045d3b8: e3301024 stg > > > %%r3,0(%%r1) > > > 0045d3be: ec28000e007c cgij > > > %%r2,0,8,45d3da > > > 0045d3c4: e3402004 lg > > > %%r4,0(%%r2) > > > 0045d3ca: b904001c lgr > > > %%r1,%%r12 > > > 0045d3ce: ec143f3f0056 rosbg > > > %%r1,%%r4,63,63,0 > > > ¢ 1851.721269! Call Trace: > > > ¢ 1851.721273! (¢<83e45898>! 0x83e45898) > > > ¢ 1851.721279! ¢<0029342a>! unlink_anon_vmas+0x9a/0x1d8 > > > ¢ 1851.721282! ¢<00283f34>! free_pgtables+0xcc/0x148 > > > ¢ 1851.721285! ¢<0028c376>! exit_mmap+0xd6/0x300 > > > ¢ 1851.721289! ¢<00134db8>! mmput+0x90/0x118 > > > ¢ 1851.721294! ¢<002d76bc>! flush_old_exec+0x5d4/0x700 > > > ¢ 1851.721298! ¢<003369f4>! load_elf_binary+0x2f4/0x13e8 > > > ¢ 1851.721301! ¢<002d6e4a>! search_binary_handler+0x9a/0x1f8 > > > ¢ 1851.721304! ¢<002d8970>! > > > do_execveat_common.isra.32+0x668/0x9a0 > > > ¢ 1851.721307! ¢<002d8cec>! do_execve+0x44/0x58 > > > ¢ 1851.721310! ¢<002d8f92>! SyS_execve+0x3a/0x48 > > > ¢ 1851.721315! ¢<006fb096>! system_call+0xd6/0x258 > > > ¢ 1851.721317! ¢<03ff997436d6>! 0x3ff997436d6 > > > ¢ 1851.721319! INFO: lockdep is turned off. > > > ¢ 1851.721321! Last Breaking-Event-Address: > > > ¢ 1851.721323! ¢<0045d31a>! __rb_erase_color+0x1e2/0x308 > > > ¢ 1851.721327! > > > ¢ 1851.721329! ---¢ end trace 0d80041ac00cfae2 !--- > > > > > > > > > > > > > > And could you share how crashes looks like? I haven't seen backtraces > > > > yet. > > > > > > > > > > Sure. I didn't because they really looked random to me. Most of the time > > > in rcu or list debugging but I thought these have just been the messenger > > > observing a corruption first. Anyhow, here is an older one that might look > > > interesting: > > > > > > [ 59.851421] list_del corruption. next->prev should be > > > 6e1eb000, but was 0400 > > > > This kinda interesting: 0x400 is TAIL_MAPPING.. Hm.. > > > > Could you check if you see the problem on commit 1c290f642101 and its > > immediate parent? > > > > How should the page->mapping poison end up as next->prev in the list of > pre-allocated THP splitting page tables? May be pgtable was casted to struct page or something. I don't know. > Also, commit 1c290f642101 is before the THP rework, at least the > non-bisectable part, so we should expect not to see the prob
Re: [PATCH v2] rtc: s3c: Document in binding that only s3c6410 needs a src clk
On 15.02.2016 23:11, Javier Martinez Canillas wrote: > The S3C binding doc says that the RTC and RTC source clocks are required > but the S3C driver supports different HW IP and only the s3c6410 needs a > source clock. > > Fix the binding explaining that the source clock is only needed for the > s3c6410-rtc compatible controller. > > Reported-by: Krzysztof Kozlowski > Signed-off-by: Javier Martinez Canillas > Acked-by: Alexandre Belloni > > --- > Hello, > > This patch depends on a previous one that was picked by Rob Herring so > this one has to go through his tree again and not through the RTC tree > to avoid conflicts. > > Best regards, > Javier > > Changes in v2: > - Remove the mention to a commit sha-1 that's not in mainline (Alexandre). > - Fix typo in commit message (Alexandre). > - Add Alexandre's Acked-by tag. > > Documentation/devicetree/bindings/rtc/s3c-rtc.txt | 7 --- > 1 file changed, 4 insertions(+), 3 deletions(-) > Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof
Re: [PATCH 01/14] pinctrl: sunxi: Add A83T R_PIO controller support
On Thu, Feb 11, 2016 at 4:12 PM, Maxime Ripard wrote: > On Thu, Feb 11, 2016 at 02:47:57PM +0100, Linus Walleij wrote: >> Can you guys supply a MAINTAINERS entry for the sunxi >> stuff? > > We have one, and Chen-Yu is listed as co-maintainer: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/MAINTAINERS#n911 Modified request: can you put in F: wildcards there to match the files pertaining to the sunxi platform, so that scripts/find-maintainer.pl finds them. Yours, Linus Walleij
Re: [RESEND PATCH 0/8] Support and fixes the rk3228 SoCS for thermal
Am Montag, 15. Februar 2016, 15:33:25 schrieb Caesar Wang: > Hello Eduardo, Heiko, Michael & Stephen: > > This series pacthes to support the rk3228 SoCs thermal. > > They have the following patches to work on rk3228 SoCs. > > 1a6f334 clk: rockchip: add id of the tsadc clock found on rk3228 SoCs > 8cf2d1b clk: rockchip: add the tsadc clocks found on rk3228 SoCs > bdc79c0 ARM: dts: rockchip: add the thermal main info found on rk3228 > 22ea3c3 ARM: dts: rockchip: enable the tsadc for rk3228 evb clk and devicetree patches look good and I'll pick those up once Eduardo is ok with (and has taken) the thermal-specific changes: > bd2720c thermal: rockchip: fix a impossible condition caused by the > warning df9c1bd thermal: rockchip: fix calculation error for code_to_temp > fb11fbd thermal: rockchip: the rename compatibles for rockchip SoCs > b907b75 thermal: rockchip: fix the tsadc sequence output on rk3228/rk3399 Heiko
Re: [PATCH v4 4/4] livepatch/module: remove livepatch module notifier
On Sun, Feb 14, 2016 at 11:59:00PM +0100, Jiri Kosina wrote:
> On Wed, 10 Feb 2016, Jiri Kosina wrote:
>
> > > > Remove the livepatch module notifier in favor of directly enabling and
> > > > disabling patches to modules in the module loader. Hard-coding the
> > > > function calls ensures that ftrace_module_enable() is run before
> > > > klp_module_coming() during module load, and that klp_module_going() is
> > > > run before ftrace_release_mod() during module unload. This way, ftrace
> > > > and livepatch code is run in the correct order during the module
> > > > load/unload sequence without dependence on the module notifier call
> > > > chain.
> > > >
> > > > This fixes a notifier ordering issue in which the ftrace module notifier
> > > > (and hence ftrace_module_enable()) for coming modules was being called
> > > > after klp_module_notify(), which caused livepatch modules to initialize
> > > > incorrectly.
> > >
> > > Without a Fixes: line, it's not absolutely clear whether this needs
> > > CC:stable, needs to go to Linus now, or can wait for the next merge
> > > window.
> > >
> > > I *think* you want all four merged this merge window, and 3 and 4 are
> > > required to fix a regression introduced since 4.4...
> >
> > Your understanding is correct; #3 and #4 are needed to fix a 4.4
> > regression. It makes sense for the whole lot go to together, but for #1
> > and #2 I absolutely need your Ack before I take it to my tree, as I don't
> > want to be merging this behind your back.
> >
> > Once you Ack #1 and #2, I plan to take this to Linus immediately so that
> > we avoid doing these changes as very last minute.
>
> Rusty, friendly ping? :)
>
> I know that this is quite tight timing, but I'd like to have the 4.4
> regression fixed, and we are quite late in the -rc phase already.
So I think the commit causing the regression is 5156dca34a3e, which
occurred in the 4.5 cycle, *not* in 4.4.
Also it's my understanding that only the third patch ("remove ftrace
module notifier") is needed to fix the regression, and the other patches
are just general improvements. So if needed I think we can just rebase
that patch (which already has Rusty's ack I believe) and send it to
Linus now.
--
Josh
Re: [PATCH v4 4/4] livepatch/module: remove livepatch module notifier
On Mon, 15 Feb 2016, Josh Poimboeuf wrote:
> So I think the commit causing the regression is 5156dca34a3e, which
> occurred in the 4.5 cycle, *not* in 4.4.
Agreed, by "4.4 regresion" I mean "regression compared to 4.4"; i.e.
regression that will become real issue once 4.5 is released.
> Also it's my understanding that only the third patch ("remove ftrace
> module notifier") is needed to fix the regression, and the other patches
> are just general improvements. So if needed I think we can just rebase
> that patch (which already has Rusty's ack I believe) and send it to
> Linus now.
3/4 and 4/4 are be sufficient, yes (although I'd like to have this
confimed by Jessica, as she apparently already has a reliable testcase).
To be honest: I was skiing (and being offline) thursday - sunday :), so my
original plan was to get Ack from Rusty in the meantime, and then send
pull request to Linus once I am back on sunday evening.
This is not going to happen, so we have to start with plan B (which is
pushing just 3/4 and 4/4). Jessica, could you please send me updated (and
tested on your side) patchset with module.c cleanups omitted?
Steven, I'd appreciate if you could tell me whether your Ack to
"ftrace/module: remove ftrace module notifier" still holds even if
module.c changes are not happening.
Thanks,
--
Jiri Kosina
SUSE Labs
Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count
On 02/15/2016 03:05 PM, Dave Chinner wrote: On Mon, Feb 15, 2016 at 10:19:54AM -0800, Daniel Walker wrote: On 02/14/2016 01:18 PM, Dave Chinner wrote: On Fri, Feb 12, 2016 at 12:14:39PM -0800, Daniel Walker wrote: From: Khalid Mughal Currently there is no way to figure out the droppable pagecache size >from the meminfo output. The MemFree size can shrink during normal system operation, when some of the memory pages get cached and is reflected in "Cached" field. Similarly for file operations some of the buffer memory gets cached and it is reflected in "Buffers" field. The kernel automatically reclaims all this cached & buffered memory, when it is needed elsewhere on the system. The only way to manually reclaim this memory is by writing 1 to /proc/sys/vm/drop_caches. But this can have performance impact. Since it discards cached objects, it may cause high CPU & I/O utilization to recreate the dropped objects during heavy system load. This patch computes the droppable pagecache count, using same algorithm as "vm/drop_caches". It is non-destructive and does not drop any pages. Therefore it does not have any impact on system performance. The computation does not include the size of reclaimable slab. Why, exactly, do you need this? You've described what the patch does (i.e. redundant, because we can read the code), and described that the kernel already accounts this reclaimable memory elsewhere and you can already read that and infer the amount of reclaimable memory from it. So why isn't that accounting sufficient? We need it to determine accurately what the free memory in the system is. If you know where we can get this information already please tell, we aren't aware of it. For instance /proc/meminfo isn't accurate enough. What you are proposing isn't accurate, either, because it will be stale by the time the inode cache traversal is completed and the count returned to userspace. e.g. pages that have already been accounted as droppable can be reclaimed or marked dirty and hence "unreclaimable". IOWs, the best you are going to get is an approximate point-in-time indication of how much memory is available for immediate reclaim. We're never going to get an accurate measure in userspace unless we accurately account for it in the kernel itself. Which, I think it has already been pointed out, is prohibitively expensive so isn't done. As for a replacement, looking at what pages you consider "droppable" is really only file pages that are not under dirty or under writeback. i.e. from /proc/meminfo: Active(file): 220128 kB Inactive(file):60232 kB Dirty: 0 kB Writeback: 0 kB i.e. reclaimable file cache = Active + inactive - dirty - writeback. And while you are there, when you drop slab caches: SReclaimable: 66632 kB some amount of that may be freed. No guarantees can be made about the amount, though. I got this response from another engineer here at Cisco (Nag he's CC'd also), " Approximate point-in-time indication is an accurate characterization of what we are doing. This is good enough for us. NO matter what we do, we are never going to be able to address the "time of check to time of use” window. But, this approximation works reasonably well for our use case. As to his other suggestion of estimating the droppable cache, I have considered it but found it unusable. The problem is the inactive file pages count a whole lot pages more than the droppable pages. See the value of these, before and [after] dropping reclaimable pages. Before: Active(file): 183488 kB Inactive(file): 180504 kB After (the drop caches): Active(file): 89468 kB Inactive(file):32016 kB The dirty and the write back are mostly 0KB under our workload as we are mostly dealing with the readonly file pages of binaries (programs/libraries).. "
Re: [PATCH v2 1/4] locking/mutex: Add waiter parameter to mutex_optimistic_spin()
On 02/12/2016 05:02 PM, Davidlohr Bueso wrote:
On Fri, 12 Feb 2016, Waiman Long wrote:
This patch adds a new waiter parameter to the mutex_optimistic_spin()
function to prepare it to be used by a waiter-spinner that doesn't
need to go into the OSQ as there can only be one waiter-spinner which
is the head of the waiting queue.
Signed-off-by: Waiman Long
---
kernel/locking/mutex.c | 55
---
1 files changed, 37 insertions(+), 18 deletions(-)
diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c
index 0551c21..3c41448 100644
--- a/kernel/locking/mutex.c
+++ b/kernel/locking/mutex.c
@@ -273,11 +273,15 @@ static inline int
mutex_can_spin_on_owner(struct mutex *lock)
/*
* Atomically try to take the lock when it is available
+ *
+ * For waiter-spinner, the count needs to be set to -1 first which
will be
+ * cleared to 0 later on if the list becomes empty. For regular
spinner,
+ * the count will be set to 0.
*/
-static inline bool mutex_try_to_acquire(struct mutex *lock)
+static inline bool mutex_try_to_acquire(struct mutex *lock, int waiter)
{
return !mutex_is_locked(lock) &&
-(atomic_cmpxchg_acquire(&lock->count, 1, 0) == 1);
+(atomic_cmpxchg_acquire(&lock->count, 1, waiter ? -1 : 0) ==
1);
}
This can be a really hot path, could we get rid of the waiter check
and just
introduce mutex_tro_to_acquire_waiter() or such and set the counter to
-1 there?
Thanks,
Davidlohr
It is hot in the sense that the lock cacheline is highly contested. On
x86, the ?: statement will most likely be translated to a cmov
instruction before doing the cmpxchg. The cmov instruction won't affect
the amount of cacheline contention on that lock cacheline. So I don't
see there is any problem here.
Cheers,
Longman
[PATCH net-next] net: macb: make magic-packet property generic
Signed-off-by: Sergio Prado --- As requested by Rob Herring on patch https://patchwork.ozlabs.org/patch/580862/ --- Documentation/devicetree/bindings/net/macb.txt | 2 +- drivers/net/ethernet/cadence/macb.c| 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/net/macb.txt b/Documentation/devicetree/bindings/net/macb.txt index c6b1cb5ffa87..b5a42df4c928 100644 --- a/Documentation/devicetree/bindings/net/macb.txt +++ b/Documentation/devicetree/bindings/net/macb.txt @@ -25,7 +25,7 @@ Required properties: Optional properties for PHY child node: - reset-gpios : Should specify the gpio for phy reset -- cdns,magic-packet : If present, indicates that the hardware supports waking +- magic-packet : If present, indicates that the hardware supports waking up via magic packet. Examples: diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c index 69af049e55a8..7ccf2298a5fa 100644 --- a/drivers/net/ethernet/cadence/macb.c +++ b/drivers/net/ethernet/cadence/macb.c @@ -2929,7 +2929,7 @@ static int macb_probe(struct platform_device *pdev) bp->jumbo_max_len = macb_config->jumbo_max_len; bp->wol = 0; - if (of_get_property(np, "cdns,magic-packet", NULL)) + if (of_get_property(np, "magic-packet", NULL)) bp->wol |= MACB_WOL_HAS_MAGIC_PACKET; device_init_wakeup(&pdev->dev, bp->wol & MACB_WOL_HAS_MAGIC_PACKET); -- 1.9.1
Re: [PATCH -next] PM / OPP: Fix crash seen if CPU clock has no voltage regulator
Hi Jon,
[auto build test WARNING on next-20160215]
url:
https://github.com/0day-ci/linux/commits/Jon-Hunter/PM-OPP-Fix-NULL-pointer-dereference-crash-when-setting-the-OPP/20160215-220238
config: x86_64-randconfig-s0-02160737 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
All warnings (new ones prefixed by >>):
drivers/base/power/opp/core.c: In function 'dev_pm_opp_set_rate':
>> drivers/base/power/opp/core.c:603:38: warning: 'ou_volt_max' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
unsigned long ou_volt, ou_volt_min, ou_volt_max;
^
>> drivers/base/power/opp/core.c:603:25: warning: 'ou_volt_min' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
unsigned long ou_volt, ou_volt_min, ou_volt_max;
^
>> drivers/base/power/opp/core.c:603:16: warning: 'ou_volt' may be used
>> uninitialized in this function [-Wmaybe-uninitialized]
unsigned long ou_volt, ou_volt_min, ou_volt_max;
^
vim +/ou_volt_max +603 drivers/base/power/opp/core.c
6a0712f6 Viresh Kumar 2016-02-09 587 * @dev: device for which we do this
operation
6a0712f6 Viresh Kumar 2016-02-09 588 * @target_freq: frequency to achieve
6a0712f6 Viresh Kumar 2016-02-09 589 *
6a0712f6 Viresh Kumar 2016-02-09 590 * This configures the power-supplies
and clock source to the levels specified
6a0712f6 Viresh Kumar 2016-02-09 591 * by the OPP corresponding to the
target_freq.
6a0712f6 Viresh Kumar 2016-02-09 592 *
6a0712f6 Viresh Kumar 2016-02-09 593 * Locking: This function takes
rcu_read_lock().
6a0712f6 Viresh Kumar 2016-02-09 594 */
6a0712f6 Viresh Kumar 2016-02-09 595 int dev_pm_opp_set_rate(struct device
*dev, unsigned long target_freq)
6a0712f6 Viresh Kumar 2016-02-09 596 {
6a0712f6 Viresh Kumar 2016-02-09 597 struct device_opp *dev_opp;
6a0712f6 Viresh Kumar 2016-02-09 598 struct dev_pm_opp *old_opp, *opp;
6a0712f6 Viresh Kumar 2016-02-09 599 struct regulator *reg;
6a0712f6 Viresh Kumar 2016-02-09 600 struct clk *clk;
6a0712f6 Viresh Kumar 2016-02-09 601 unsigned long freq, old_freq;
6a0712f6 Viresh Kumar 2016-02-09 602 unsigned long u_volt, u_volt_min,
u_volt_max;
6a0712f6 Viresh Kumar 2016-02-09 @603 unsigned long ou_volt, ou_volt_min,
ou_volt_max;
6a0712f6 Viresh Kumar 2016-02-09 604 int ret;
6a0712f6 Viresh Kumar 2016-02-09 605
6a0712f6 Viresh Kumar 2016-02-09 606 if (unlikely(!target_freq)) {
6a0712f6 Viresh Kumar 2016-02-09 607 dev_err(dev, "%s: Invalid
target frequency %lu\n", __func__,
6a0712f6 Viresh Kumar 2016-02-09 608 target_freq);
6a0712f6 Viresh Kumar 2016-02-09 609 return -EINVAL;
6a0712f6 Viresh Kumar 2016-02-09 610 }
6a0712f6 Viresh Kumar 2016-02-09 611
:: The code at line 603 was first introduced by commit
:: 6a0712f6f199e737aa5913d28ec4bd3a25de9660 PM / OPP: Add
dev_pm_opp_set_rate()
:: TO: Viresh Kumar
:: CC: Rafael J. Wysocki
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
4.4.1 skb_warn_bad_offload+0xc5/0x110
Please keep me in CC. I've been seeing the following on some of my VMs ran under qemu. The VMs do not have internet connectivity. This happened when some files were accessed via NFS to another VM (NOTE: Both VMs throw these warnings. Both VMs are running the exact same kernel). The host is also throwing these warnings and is also 4.4.1, but not the same kernel build. The issue appears to have gone away if I issue the following on the guests and on the host (except br0 instead of eth0 on host) ethtool -K eth0 gso off gro off ufo off tso off On the host, br0 does not have any interfaces enslaved except for the interface for the VMs and also does not have an IPv4 address assigned. [ 90.067519] [ cut here ] [ 90.067678] WARNING: CPU: 0 PID: 2258 at /usr/src/linux/dist/4.4.1-nobklcd/net/core/dev.c:2422 skb_warn_bad_offload+0xc5/0x110() [ 90.067766] virtio_net: caps=(0x0804001f4a29, 0x) len=32934 data_len=32768 gso_size=1480 gso_type=2 ip_summed=0 [ 90.067878] Modules linked in: nfsv3 nfsd auth_rpcgss oid_registry exportfs nfs lockd grace sunrpc ipv6 virtio_net virtio_balloon evdev unix [ 90.068206] CPU: 0 PID: 2258 Comm: kworker/0:1H Not tainted 4.4.1 #1 [ 90.068258] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS Debian-1.8.2-1 04/01/2014 [ 90.068340] Workqueue: rpciod rpc_async_schedule [sunrpc] [ 90.068433] 81503288 811d455e 880276ffb9a0 81041343 [ 90.068575] 88007b85be00 880276ffb9f0 0002 880276f87aac [ 90.068725] 88027692c000 810413b7 81503498 0030 [ 90.068846] Call Trace: [ 90.06] [] ? dump_stack+0x47/0x69 [ 90.068967] [] ? warn_slowpath_common+0x73/0xa0 [ 90.069068] [] ? warn_slowpath_fmt+0x47/0x50 [ 90.069129] [] ? skb_warn_bad_offload+0xc5/0x110 [ 90.069191] [] ? __skb_gso_segment+0x71/0xc0 [ 90.069250] [] ? validate_xmit_skb.isra.119.part.120+0x100/0x290 [ 90.069314] [] ? lock_timer_base.isra.22+0x49/0x60 [ 90.069381] [] ? validate_xmit_skb_list+0x31/0x50 [ 90.069440] [] ? sch_direct_xmit+0x140/0x1e0 [ 90.069497] [] ? __dev_queue_xmit+0x1c8/0x490 [ 90.069555] [] ? ip_finish_output2+0x122/0x300 [ 90.069613] [] ? release_sock+0xfd/0x160 [ 90.069671] [] ? ip_output+0xb5/0xc0 [ 90.069720] [] ? ip_reply_glue_bits+0x50/0x50 [ 90.069784] [] ? prandom_u32+0x1b/0x30 [ 90.069833] [] ? ip_local_out+0x12/0x40 [ 90.069877] [] ? ip_send_skb+0x10/0x40 [ 90.069922] [] ? udp_send_skb+0x160/0x240 [ 90.069990] [] ? udp_push_pending_frames+0x34/0x50 [ 90.070050] [] ? udp_sendpage+0xe4/0x150 [ 90.070095] [] ? kernel_sendmsg+0x2a/0x40 [ 90.070164] [] ? xs_send_kvec+0x83/0x90 [sunrpc] [ 90.070223] [] ? inet_sendpage+0x93/0xe0 [ 90.070270] [] ? xs_sendpages+0x16f/0x1b0 [sunrpc] [ 90.070330] [] ? xs_udp_send_request+0x5e/0x100 [sunrpc] [ 90.070390] [] ? xprt_transmit+0x47/0x230 [sunrpc] [ 90.070449] [] ? call_transmit+0x175/0x220 [sunrpc] [ 90.070508] [] ? __rpc_execute+0x4b/0x290 [sunrpc] [ 90.070575] [] ? finish_task_switch+0x83/0x1b0 [ 90.070653] [] ? process_one_work+0x129/0x3f0 [ 90.070711] [] ? worker_thread+0x42/0x490 [ 90.070764] [] ? process_one_work+0x3f0/0x3f0 [ 90.070816] [] ? kthread+0xb8/0xd0 [ 90.070860] [] ? kthread_worker_fn+0x100/0x100 [ 90.070925] [] ? ret_from_fork+0x3f/0x70 [ 90.070974] [] ? kthread_worker_fn+0x100/0x100 [ 90.071035] ---[ end trace ffb4f8c2d24c1959 ]--- -- Microsoft has beaten Volkswagen's world record. Volkswagen only created 22 million bugs.
Re: [PATCH] acpi, pci, irq: account for early penalty assignment
On Mon, Feb 15, 2016 at 5:41 PM, Sinan Kaya wrote:
> A crash has been observed when assigning penalty on x86 systems.
>
> It looks like this problem happens on x86 platforms with IOAPIC and an SCI
> interrupt override in the ACPI table with interrupt number greater than
> 16. (22 in this example)
>
> The bug has been introduced by "ACPI, PCI, irq: remove interrupt count
> restriction" commit. The code was using kmalloc to resize the interrupt
> list. In this use case, the set penalty call is coming from early phase
> and the heap is not initialized yet.
>
> BUG: unable to handle kernel NULL pointer dereference at 0018
> IP: [] kmem_cache_alloc_trace+0xad/0x1c0
> PGD 0
> Oops: [#1] SMP
> Modules linked in:
> CPU: 0 PID: 0 Comm: swapper Not tainted 4.5.0-rc2Feb-3_RK #1
> Hardware name: HP Superdome2 16s, BIOS Bundle: 007.006.000 SFW: 033.162.000
> 10/30/2015
> [] acpi_irq_set_penalty+0x60/0x8e
> [] acpi_irq_add_penalty+0x21/0x26
> [] acpi_penalize_sci_irq+0x25/0x28
> [] acpi_sci_ioapic_setup+0x68/0x78
> [] acpi_boot_init+0x2cc/0x533
> [] ? set_pte_vaddr_pud+0x48/0x50
> [] ? acpi_parse_x2apic+0x77/0x77
> [] ? dmi_ignore_irq0_timer_override+0x30/0x30
> [] setup_arch+0xc24/0xce9
> [] ? early_idt_handler_array+0x120/0x120
> [] start_kernel+0xfc/0x506
> [] ? early_idt_handler_array+0x120/0x120
> [] ? early_idt_handler_array+0x120/0x120
> [] x86_64_start_reservations+0x2a/0x2c
> [] x86_64_start_kernel+0x14c/0x16f
>
> Besides from the use case above, there is one more situation where
> set_penalty is being called from the init context like. There is support
> for setting the penalty through kernel command line.
>
> Adding support to be called from early context for limited number of
> interrupts.
>
> Signed-off-by: Sinan Kaya
This looks somewhat hackish to me to be honest.
> ---
> drivers/acpi/pci_link.c | 32
> 1 file changed, 28 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index fa28635..24b69e1 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -47,6 +47,7 @@ ACPI_MODULE_NAME("pci_link");
> #define ACPI_PCI_LINK_FILE_INFO"info"
> #define ACPI_PCI_LINK_FILE_STATUS "state"
> #define ACPI_PCI_LINK_MAX_POSSIBLE 16
> +#define ACPI_PCI_LINK_MAX_EARLY_IRQINFO 1024
>
> static int acpi_pci_link_add(struct acpi_device *device,
> const struct acpi_device_id *not_used);
> @@ -470,9 +471,13 @@ struct irq_penalty_info {
> int irq;
> int penalty;
> struct list_head node;
> + bool early;
Where is this field used ->
> };
>
> static LIST_HEAD(acpi_irq_penalty_list);
> +static int early_init_done;
> +static struct irq_penalty_info
> early_irq_infos[ACPI_PCI_LINK_MAX_EARLY_IRQINFO];
> +static int early_irq_info_counter;
>
> static int acpi_irq_get_penalty(int irq)
> {
> @@ -507,10 +512,20 @@ static int acpi_irq_set_penalty(int irq, int
> new_penalty)
> }
> }
>
> - /* nope, let's allocate a slot for this IRQ */
> - irq_info = kzalloc(sizeof(*irq_info), GFP_KERNEL);
> - if (!irq_info)
> - return -ENOMEM;
> + if (!early_init_done) {
> + if (early_irq_info_counter < ARRAY_SIZE(early_irq_infos)) {
> + irq_info = &early_irq_infos[early_irq_info_counter];
> + irq_info->early = true;
-> except for being set here?
> + early_irq_info_counter++;
> + } else {
> + return -ENOMEM;
> + }
> + } else {
> + /* nope, let's allocate a slot for this IRQ */
> + irq_info = kzalloc(sizeof(*irq_info), GFP_KERNEL);
> + if (!irq_info)
> + return -ENOMEM;
> + }
>
> irq_info->irq = irq;
> irq_info->penalty = new_penalty;
> @@ -968,3 +983,12 @@ void __init acpi_pci_link_init(void)
> register_syscore_ops(&irqrouter_syscore_ops);
> acpi_scan_add_handler(&pci_link_handler);
> }
> +
> +
> +static int acpi_pci_link_subsys_init(void)
> +{
> + early_init_done = true;
Why do you need yet another subsys_initcall do set this? Can't it be
set in, say, acpi_init()?
And isn't there any existing way to check that? Like checking
acpi_gbl_permanent_mmap or something?
> + return 0;
> +}
> +
> +subsys_initcall(acpi_pci_link_subsys_init)
> --
Thanks,
Rafael
Re: [PATCH v8 0/2] Add Rockchip Inno-HDMI driver
Hi
Ping, it seems inno hdmi driver is ready, So I'd like to merge it into
drm/rockchip if there is no doubt these days.
Thanks.
Mark
On 2016年01月29日 14:42, Yakir Yang wrote:
Here are a brief introduction to Innosilicon HDMI IP:
- Support HDMI 1.4a, HDCP 1.2 and DVI 1.0 standard compliant transmitter
- Support HDMI1.4 a/b 3D function defined in HDMI 1.4 a/b spec
- Digital video interface supports a pixel size of 24, 30, 36, 48bits color
depth in RGB
- S/PDIF output supports PCM, Dolby Digital, DTS digital audio transmission
(32-192kHz Fs) using IEC60958 and IEC 61937
- The EDID and CEC function are also supported by Innosilicon HDMI
Transmitter Controlle
Changes in v8:
- Don't check whether encoder output format is RGB colorspace, cause driver
default configure the output colorspace to RGB. (ZhengYang)
- Correct the check condition in inno_hdmi_config_video_csc() (ZhengYang)
- if (data->enc_out_format == data->enc_out_format) {
+ if (data->enc_in_format == data->enc_out_format) {
Changes in v7:
- Correct the module licnese statement (Paul)
- MODULE_LICENSE("GPL");
+ MODULE_LICENSE("GPLv2");
- Start indentation with tabs and fix the misspell in Kconfig (Paul)
- Carry the lost device-binding document (Heiko)
Changes in v6:
- Rebase the Makefile/Kconfig files which add by Chris's rockchip-mipi driver
(Caeser)
Changes in v5:
- Use hdmi_infoframe helper functions to packed the infoframe (Russell)
- Remove the unused double wait_for_completion_timeout for ddc transfer
(Russell)
- Remove the unused local variable in "inno_hdmi_i2c_write()" function (Russell)
Changes in v4:
- Modify the commit title "drm/rockchip: hdmi: ..." (Mark)
- Correct the "DKMS" to "DPMS" (Mark)
- Fix over 80 characters problems (Mark)
- Remove encoder .prepare/.commit helper functions, and move the vop mode
configure function into encoder .enable helper functions. (Mark)
Changes in v3:
- Use encoder enable/disable function, and remove the encoder DPMS function
- Keep HDMI PLL power on in standby mode
Changes in v2:
- Using DRM atomic helper functions for connector init (Mark)
- Remove "hdmi->connector.encoder = encoder;" (Mark)
- Add the Acked-by tags from Rob
- Correct the misspell "rk3036-dw-hdmi" (Heiko)
Yakir Yang (2):
drm/rockchip: hdmi: add Innosilicon HDMI support
dt-bindings: add document for Innosilicon HDMI on Rockchip platform
.../display/rockchip/inno_hdmi-rockchip.txt| 50 ++
drivers/gpu/drm/rockchip/Kconfig | 8 +
drivers/gpu/drm/rockchip/Makefile | 1 +
drivers/gpu/drm/rockchip/inno_hdmi.c | 939 +
drivers/gpu/drm/rockchip/inno_hdmi.h | 362
5 files changed, 1360 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/rockchip/inno_hdmi-rockchip.txt
create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.c
create mode 100644 drivers/gpu/drm/rockchip/inno_hdmi.h
Re: [PATCH] kernel: fs: drop_caches: add dds drop_caches_count
On Mon, Feb 15, 2016 at 03:52:31PM -0800, Daniel Walker wrote: > >>We need it to determine accurately what the free memory in the > >>system is. If you know where we can get this information already > >>please tell, we aren't aware of it. For instance /proc/meminfo isn't > >>accurate enough. > > Approximate point-in-time indication is an accurate characterization > of what we are doing. This is good enough for us. NO matter what we > do, we are never going to be able to address the "time of check to > time of use” window. But, this approximation works reasonably well > for our use case. Why do you need such accuracy, and what do you consider "good enough". Having something which iterates over all of the inodes in the system is something that really shouldn't be in a general production kernel At the very least it should only be accessible by root (so now only a careless system administrator can DOS attack the system) but the Dave's original question still stands. Why do you need a certain level of accuracy regarding how much memory is available after dropping all of the caches? What problem are you trying to solve/avoid? It may be that you are going about things completely the wrong way, which is why understanding the higher order problem you are trying to solve might be helpful in finding something which is safer, architecturally cleaner, and something that could go into the upstream kernel. Cheers, - Ted
Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation
On Mon, Feb 15, 2016 at 11:07:41AM -0500, Steven Rostedt wrote: > On Mon, 15 Feb 2016 12:04:50 +0900 > js1...@gmail.com wrote: > > > From: Joonsoo Kim > > > > CMA allocation should be guaranteed to succeed by definition, but, > > unfortunately, it would be failed sometimes. It is hard to track down > > the problem, because it is related to page reference manipulation and > > we don't have any facility to analyze it. > > > > This patch adds tracepoints to track down page reference manipulation. > > With it, we can find exact reason of failure and can fix the problem. > > Following is an example of tracepoint output. > > > > <...>-9018 [004]92.678375: page_ref_set: pfn=0x17ac9 flags=0x0 > > count=1 mapcount=0 mapping=(nil) mt=4 val=1 > > <...>-9018 [004]92.678378: kernel_stack: > > => get_page_from_freelist (81176659) > > => __alloc_pages_nodemask (81176d22) > > => alloc_pages_vma (811bf675) > > => handle_mm_fault (8119e693) > > => __do_page_fault (810631ea) > > => trace_do_page_fault (81063543) > > => do_async_page_fault (8105c40a) > > => async_page_fault (817581d8) > > [snip] > > <...>-9018 [004]92.678379: page_ref_mod: pfn=0x17ac9 > > flags=0x40048 count=2 mapcount=1 mapping=0x880015a78dc1 mt=4 val=1 > > [snip] > > ... > > ... > > <...>-9131 [001]93.174468: test_pages_isolated: start_pfn=0x17800 > > end_pfn=0x17c00 fin_pfn=0x17ac9 ret=fail > > [snip] > > <...>-9018 [004]93.174843: page_ref_mod_and_test: pfn=0x17ac9 > > flags=0x40068 count=0 mapcount=0 mapping=0x880015a78dc1 mt=4 val=-1 > > ret=1 > > => release_pages (8117c9e4) > > => free_pages_and_swap_cache (811b0697) > > => tlb_flush_mmu_free (81199616) > > => tlb_finish_mmu (8119a62c) > > => exit_mmap (811a53f7) > > => mmput (81073f47) > > => do_exit (810794e9) > > => do_group_exit (81079def) > > => SyS_exit_group (81079e74) > > => entry_SYSCALL_64_fastpath (817560b6) > > > > This output shows that problem comes from exit path. In exit path, > > to improve performance, pages are not freed immediately. They are gathered > > and processed by batch. During this process, migration cannot be possible > > and CMA allocation is failed. This problem is hard to find without this > > page reference tracepoint facility. > > > > Enabling this feature bloat kernel text 30 KB in my configuration. > > > >textdata bss dec hex filename > > 121273272243616 1507328 15878271 f2487f vmlinux_disabled > > 121572082258880 1507328 15923416 f2f8d8 vmlinux_enabled > > > > v2: > > o Use static key of each tracepoints to avoid function call overhead > > when tracepoints are disabled. > > o Print human-readable page flag through show_page_flags() > > o Add more description to Kconfig.debug. > > > > Acked-by: Michal Nazarewicz > > Signed-off-by: Joonsoo Kim > > --- > > include/linux/page_ref.h| 90 +-- > > include/trace/events/page_ref.h | 133 > > > > mm/Kconfig.debug| 13 > > mm/Makefile | 1 + > > mm/debug_page_ref.c | 53 > > 5 files changed, 285 insertions(+), 5 deletions(-) > > create mode 100644 include/trace/events/page_ref.h > > create mode 100644 mm/debug_page_ref.c > > > > diff --git a/include/linux/page_ref.h b/include/linux/page_ref.h > > index 534249c..fd6d9a5 100644 > > --- a/include/linux/page_ref.h > > +++ b/include/linux/page_ref.h > > @@ -1,6 +1,54 @@ > > #include > > #include > > #include > > +#include > > + > > +extern struct tracepoint __tracepoint_page_ref_set; > > +extern struct tracepoint __tracepoint_page_ref_mod; > > +extern struct tracepoint __tracepoint_page_ref_mod_and_test; > > +extern struct tracepoint __tracepoint_page_ref_mod_and_return; > > +extern struct tracepoint __tracepoint_page_ref_mod_unless; > > +extern struct tracepoint __tracepoint_page_ref_freeze; > > +extern struct tracepoint __tracepoint_page_ref_unfreeze; > > + > > +#ifdef CONFIG_DEBUG_PAGE_REF > > +#define page_ref_tracepoint_active(t) static_key_false(&(t).key) > > Please don't open code this. Use the following instead: > > trace_page_ref_set_enabled() > trace_page_ref_mod_enabled() > trace_page_ref_mod_and_test_enabled() > trace_page_ref_mod_and_return_enabled() > trace_page_ref_mod_unless_enabled() > trace_page_ref_freeze_enabled() > trace_page_ref_unfreeze_enabled() > > They return true when CONFIG_TRACEPOINTS is configured in and the > tracepoint is enabled, and false otherwise. This implementation is what you proposed before. Please refer below link and source. https://lkml.org/lkml/2015/12/9/699 arch/x86/include/asm/msr.h There is header file dependency problem between mm.h and tracepoint.h. page_ref.h should be include
Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value
On 15-02-16, 22:13, Rafael J. Wysocki wrote: > That should be something like -ENXIO IMO. Thanks for modifying and applying the patch :) -- viresh
Re: [PATCH -next] PM / OPP: Fix crash seen if CPU clock has no voltage regulator
On 15-02-16, 11:34, Guenter Roeck wrote:
> omap3 overo boots crash with
>
> Unable to handle kernel NULL pointer dereference at virtual address 0030
> pgd = c0204000
> [0030] *pgd=
> Internal error: Oops: 17 [#1] SMP ARM
> ...
> [] (regulator_set_voltage) from [] (_set_opp_voltage+0x34/0x90)
> [] (_set_opp_voltage) from [] (dev_pm_opp_set_rate+0x19c/0x288)
> [] (dev_pm_opp_set_rate) from [] (__cpufreq_driver_target+0x17c/0x29c)
> [] (__cpufreq_driver_target) from [] (dbs_check_cpu+0x19c/0x1e4)
> [] (dbs_check_cpu) from [] (cpufreq_governor_dbs+0x308/0x5c4)
> [] (cpufreq_governor_dbs) from [] (__cpufreq_governor+0x20c/0x24c)
> [] (__cpufreq_governor) from [] (cpufreq_init_policy+0x60/0x8c)
> [] (cpufreq_init_policy) from [] (cpufreq_online+0x2cc/0x6d8)
> [] (cpufreq_online) from [] (subsys_interface_register+0x80/0xc4)
> [] (subsys_interface_register) from [] (cpufreq_register_driver+0x144/0x1a0)
> [] (cpufreq_register_driver) from [] (dt_cpufreq_probe+0x64/0xe8)
> [] (dt_cpufreq_probe) from [] (platform_drv_probe+0x50/0xb0)
> [] (platform_drv_probe) from [] (driver_probe_device+0x1f4/0x2b0)
> ...
>
> Analysis shows that regulator==NULL in regulator_set_voltage().
> Code around _set_opp_voltage() suggests that having no voltage regulator
> attached to a CPU clock is valid, so do not attempt to set a voltage
> in that case.
>
> Fixes: 6a0712f6f199e ("PM / OPP: Add dev_pm_opp_set_rate()"
> Cc: Viresh Kumar
> Signed-off-by: Guenter Roeck
> ---
> drivers/base/power/opp/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Sorry about that, a separate fix for the same is pushed by Rafael in
pm/linux-next now.
--
viresh
Re: livepatch/module: remove livepatch module notifier
+++ Jiri Kosina [16/02/16 00:42 +0100]:
On Mon, 15 Feb 2016, Josh Poimboeuf wrote:
So I think the commit causing the regression is 5156dca34a3e, which
occurred in the 4.5 cycle, *not* in 4.4.
Agreed, by "4.4 regresion" I mean "regression compared to 4.4"; i.e.
regression that will become real issue once 4.5 is released.
Also it's my understanding that only the third patch ("remove ftrace
module notifier") is needed to fix the regression, and the other patches
are just general improvements. So if needed I think we can just rebase
that patch (which already has Rusty's ack I believe) and send it to
Linus now.
3/4 and 4/4 are be sufficient, yes (although I'd like to have this
confimed by Jessica, as she apparently already has a reliable testcase).
Yes, so Josh is right; technically only patch 3/4 "ftrace/module:
remove ftrace module notifier" is sufficient enough to fix the bug,
and patch 4/4 is just a natural extension of that change. Since I'm
going to be sending out another patchset anyway without the module.c
cleanups, I'll just keep them together.
Jessica
To be honest: I was skiing (and being offline) thursday - sunday :), so my
original plan was to get Ack from Rusty in the meantime, and then send
pull request to Linus once I am back on sunday evening.
This is not going to happen, so we have to start with plan B (which is
pushing just 3/4 and 4/4). Jessica, could you please send me updated (and
tested on your side) patchset with module.c cleanups omitted?
Steven, I'd appreciate if you could tell me whether your Ack to
"ftrace/module: remove ftrace module notifier" still holds even if
module.c changes are not happening.
Thanks,
--
Jiri Kosina
SUSE Labs
Re: [PATCH v2 2/2] tracing/rcu: don't trace rcu_callback on offline CPUs
On Sun, Feb 14, 2016 at 10:05:22PM -0800, Paul E. McKenney wrote: > On Sun, Feb 14, 2016 at 09:50:18AM +0300, Denis Kirjanov wrote: > > Tracepoints use RCU for protection and they must not be called on > > offline CPUS. So make this tracepoint conditional. > > Good catch! Queued for review and testing. And I dequeued this in favor of Steven's more recent patch. But there is one other hitch... It is currently not legal to invoke call_rcu() from an offline CPU. You can get away with it during a short window towards the end of the offline process, but shortly after the outgoing CPU hits the idle loop, call_rcu() will splat and leak the callback. So what exactly is the purpose of invoking call_rcu() from an offline CPU? (Yes, I could probably make it work, but there needs to be a good reason.) Thanx, Paul > > NFO: suspicious RCU usage. ] > > [ 413.344670] 4.4.0-6-g0fe53e8-dirty #33 Tainted: G S > > [ 413.344672] --- > > [ 413.344673] include/trace/events/rcu.h:457 suspicious > > rcu_dereference_check() usage! > > [ 413.344674] > > other info that might help us debug this: > > > > [ 413.344676] > > RCU used illegally from offline CPU! > > rcu_scheduler_active = 1, debug_locks = 1 > > [ 413.344678] no locks held by swapper/4/0. > > [ 413.344679] > > stack backtrace: > > [ 413.344682] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G S > > 4.4.0-6-g0fe53e8-dirty #33 > > [ 413.344683] Call Trace: > > [ 413.344692] [c005b76b7800] [c08bb080] .dump_stack+0x98/0xd4 > > (unreliable) > > [ 413.344698] [c005b76b7880] [c010c8b8] > > .lockdep_rcu_suspicious+0x108/0x170 > > [ 413.344703] [c005b76b7910] [c013b9e4] > > .__call_rcu.constprop.60+0x264/0x600 > > [ 413.344708] [c005b76b79e0] [c02bceec] .put_object+0x5c/0x80 > > [ 413.344712] [c005b76b7a60] [c029a368] > > .kmem_cache_free+0x298/0x450 > > [ 413.344716] [c005b76b7b00] [c0093494] .__mmdrop+0x54/0x150 > > [ 413.344720] [c005b76b7b90] [c00e4010] > > .idle_task_exit+0x130/0x140 > > [ 413.344725] [c005b76b7c20] [c0075804] > > .pseries_mach_cpu_die+0x64/0x310 > > [ 413.344730] [c005b76b7cd0] [c0043e7c] .cpu_die+0x3c/0x60 > > [ 413.344734] [c005b76b7d40] [c00188d8] > > .arch_cpu_idle_dead+0x28/0x40 > > [ 413.344738] [c005b76b7db0] [c0101e8c] > > .cpu_startup_entry+0x50c/0x560 > > [ 413.344741] [c005b76b7ed0] [c0043bd8] > > .start_secondary+0x328/0x360 > > [ 413.344746] [c005b76b7f90] [c0008a6c] > > start_secondary_prolog+0x10/0x14 > > > > Signed-off-by: Denis Kirjanov > > --- > > > > v2: Fix the build error that was made > > while sending the pacthes from another machine > > > > include/trace/events/rcu.h | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/include/trace/events/rcu.h b/include/trace/events/rcu.h > > index ef72c4a..793d306b 100644 > > --- a/include/trace/events/rcu.h > > +++ b/include/trace/events/rcu.h > > @@ -428,13 +428,15 @@ TRACE_EVENT(rcu_prep_idle, > > * number of lazy callbacks queued, and the fourth element is the > > * total number of callbacks queued. > > */ > > -TRACE_EVENT(rcu_callback, > > +TRACE_EVENT_CONDITION(rcu_callback, > > > > TP_PROTO(const char *rcuname, struct rcu_head *rhp, long qlen_lazy, > > long qlen), > > > > TP_ARGS(rcuname, rhp, qlen_lazy, qlen), > > > > + TP_CONDITION(cpu_online(raw_smp_processor_id())), > > + > > TP_STRUCT__entry( > > __field(const char *, rcuname) > > __field(void *, rhp) > > -- > > 2.4.0 > >
Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value
On Tuesday, February 16, 2016 06:17:16 AM Viresh Kumar wrote: > On 15-02-16, 22:13, Rafael J. Wysocki wrote: > > That should be something like -ENXIO IMO. > > Thanks for modifying and applying the patch :) Well, you're welcome. I wanted it to be fixed in the tomorrow's linux-next so people can boot their systems again. Thanks, Rafael
Re: [PATCH v3] powercap/rapl: reduce ipi calls
On Friday, January 15, 2016 11:04:13 AM Jacob Pan wrote:
> Reduce remote CPU calls for MSR access by combining read
> modify write into one function. Also optimize search for active CPU on
> package such that remote CPU is not used if the current CPU is already
> on the target package.
>
> Suggested-by: Peter Zijlstra
> Signed-off-by: Jacob Pan
I'm wondering if there are any comments on this one?
> ---
> drivers/powercap/intel_rapl.c | 122
> ++
> 1 file changed, 87 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/powercap/intel_rapl.c b/drivers/powercap/intel_rapl.c
> index 48747c2..2dcd95f 100644
> --- a/drivers/powercap/intel_rapl.c
> +++ b/drivers/powercap/intel_rapl.c
> @@ -133,6 +133,12 @@ struct rapl_domain_data {
> unsigned long timestamp;
> };
>
> +struct msrl_action {
> + u32 msr_no;
> + u64 clear_mask;
> + u64 set_mask;
> + int err;
> +};
>
> #define DOMAIN_STATE_INACTIVE BIT(0)
> #define DOMAIN_STATE_POWER_LIMIT_SETBIT(1)
> @@ -263,7 +269,11 @@ static struct rapl_package *find_package_by_id(int id)
> /* caller to ensure CPU hotplug lock is held */
> static int find_active_cpu_on_package(int package_id)
> {
> - int i;
> + /* try to avoid remote cpu call, use raw since we are preemptible */
> + int i = raw_smp_processor_id();
> +
> + if (topology_physical_package_id(i) == package_id)
> + return i;
>
> for_each_online_cpu(i) {
> if (topology_physical_package_id(i) == package_id)
> @@ -800,35 +810,62 @@ static int rapl_read_data_raw(struct rapl_domain *rd,
> return 0;
> }
>
> +
> +static int msrl_update_safe(u32 msr_no, u64 clear_mask, u64 set_mask)
> +{
> + int err;
> + u64 val;
> +
> + err = rdmsrl_safe(msr_no, &val);
> + if (err)
> + goto out;
> +
> + val &= ~clear_mask;
> + val |= set_mask;
> +
> + err = wrmsrl_safe(msr_no, val);
> +
> +out:
> + return err;
> +}
> +
> +static void msrl_update_func(void *info)
> +{
> + struct msrl_action *ma = info;
> +
> + ma->err = msrl_update_safe(ma->msr_no, ma->clear_mask, ma->set_mask);
> +}
> +
> /* Similar use of primitive info in the read counterpart */
> static int rapl_write_data_raw(struct rapl_domain *rd,
> enum rapl_primitives prim,
> unsigned long long value)
> {
> - u64 msr_val;
> - u32 msr;
> struct rapl_primitive_info *rp = &rpi[prim];
> int cpu;
> + u64 bits;
> + struct msrl_action ma;
> + int ret;
>
> cpu = find_active_cpu_on_package(rd->package_id);
> if (cpu < 0)
> return cpu;
> - msr = rd->msrs[rp->id];
> - if (rdmsrl_safe_on_cpu(cpu, msr, &msr_val)) {
> - dev_dbg(&rd->power_zone.dev,
> - "failed to read msr 0x%x on cpu %d\n", msr, cpu);
> - return -EIO;
> - }
> - value = rapl_unit_xlate(rd, rd->package_id, rp->unit, value, 1);
> - msr_val &= ~rp->mask;
> - msr_val |= value << rp->shift;
> - if (wrmsrl_safe_on_cpu(cpu, msr, msr_val)) {
> - dev_dbg(&rd->power_zone.dev,
> - "failed to write msr 0x%x on cpu %d\n", msr, cpu);
> - return -EIO;
> - }
>
> - return 0;
> + bits = rapl_unit_xlate(rd, rd->package_id, rp->unit, value, 1);
> + bits |= bits << rp->shift;
> + memset(&ma, 0, sizeof(ma));
> +
> + ma.msr_no = rd->msrs[rp->id];
> + ma.clear_mask = rp->mask;
> + ma.set_mask = bits;
> +
> + ret = smp_call_function_single(cpu, msrl_update_func, &ma, 1);
> + if (ret)
> + WARN_ON_ONCE(ret);
> + else
> + ret = ma.err;
> +
> + return ret;
> }
>
> /*
> @@ -893,6 +930,21 @@ static int rapl_check_unit_atom(struct rapl_package *rp,
> int cpu)
> return 0;
> }
>
> +static void power_limit_irq_save_cpu(void *info)
> +{
> + u32 l, h = 0;
> + struct rapl_package *rp = (struct rapl_package *)info;
> +
> + /* save the state of PLN irq mask bit before disabling it */
> + rdmsr_safe(MSR_IA32_PACKAGE_THERM_INTERRUPT, &l, &h);
> + if (!(rp->power_limit_irq & PACKAGE_PLN_INT_SAVED)) {
> + rp->power_limit_irq = l & PACKAGE_THERM_INT_PLN_ENABLE;
> + rp->power_limit_irq |= PACKAGE_PLN_INT_SAVED;
> + }
> + l &= ~PACKAGE_THERM_INT_PLN_ENABLE;
> + wrmsr_safe(MSR_IA32_PACKAGE_THERM_INTERRUPT, l, h);
> +}
> +
>
> /* REVISIT:
> * When package power limit is set artificially low by RAPL, LVT
> @@ -906,7 +958,6 @@ static int rapl_check_unit_atom(struct rapl_package *rp,
> int cpu)
>
> static void package_power_limit_irq_save(int package_id)
> {
> - u32 l, h = 0;
> int cpu;
> struct rapl_package *rp;
>
> @@ -920,20 +971,27 @@ static void package_power_limit_irq_save(int package_id)
> cpu = find_active_cpu_on_package(package_id);
> if (cpu < 0)
>
Re: checkpatch falsepositives in Lustre code
On Mon, 2016-02-15 at 18:49 -0500, Oleg Drokin wrote:
> Hello!
>
>
> As I am going over Lustre to clean up the code style, I noticed this bunch
> below.
>
> Those all are function definitions, though I guess it might have been
> foiled by
> return type on the previous line?
> Now sure if anything could be done about this.
>
> Thanks.
>
> ERROR: that open brace { should be on the previous line
> #2098: FILE: drivers/staging/lustre/lustre/libcfs/hash.c:1358:
> +cfs_ash_for_each_enter(struct cfs_hash *hs)
> +{
[etc...]
Yeah, that's a defect of some type.
I'm not sure if it's really possible to handle it well though.
Maybe there could be a test added for something like
"^[\+ ](?:$Declare\s*|DeclareMisordered\s*)?\$Ident\("
to find what looks like function declarations in the
first column to avoid some of these false positives.
Andy?
Re: [PATCH] PM / OPP: Initialize regulator pointer to an error value
Cc'ing Mark as well.
On 15-02-16, 21:38, Arnd Bergmann wrote:
> There is usually something else wrong if you have to check for both.
> Why exactly do you need to check for both IS_ERR and NULL?
And here is the reasoning behind it:
- It is normally said that 'NULL' is a valid clk. The same is
applicable to regulators as well, right? At least, that is what
below says:
commit 4a511de96d69 ("cpufreq: cpufreq-cpu0: NULL is a valid
regulator")
- And so I left the regulator pointer to NULL in OPP core.
- But then I realized that its not safe to call many regulator core
APIs with NULL regulator, as those caused the crashes reported by
multiple people now.
- clk APIs guarantee that they return early when NULL clk is passed to
them.
- Do we need to do the same for regulator core as well ?
- And so I initialized the pointer to an error value now, as
initializing it to NULL (possibly a valid regulator, in theory)
isn't the right thing to do.
> > diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
> > index d7cd4e265766..146b6197d598 100644
> > --- a/drivers/base/power/opp/core.c
> > +++ b/drivers/base/power/opp/core.c
> > @@ -257,7 +257,7 @@ unsigned long dev_pm_opp_get_max_volt_latency(struct
> > device *dev)
> > }
> >
> > reg = dev_opp->regulator;
> > - if (IS_ERR_OR_NULL(reg)) {
> > + if (IS_ERR(reg)) {
> > /* Regulator may not be required for device */
> > if (reg)
> > dev_err(dev, "%s: Invalid regulator (%ld)\n", __func__,
> > @@ -798,6 +798,9 @@ static struct device_opp *_add_device_opp(struct device
> > *dev)
> > of_node_put(np);
> > }
> >
> > + /* Set regulator to a non-NULL error value */
> > + dev_opp->regulator = ERR_PTR(-EFAULT);
> > +
> > /* Find clk for the device */
> > dev_opp->clk = clk_get(dev, NULL);
> > if (IS_ERR(dev_opp->clk)) {
>
> -EFAULT has a very specific meaning (accessing an invalid pointer from
> user space), I don't think you want that one.
Sorry, wasn't aware of those requirements. What Rafael suggested is
the right thing to do then.
--
viresh
Re: [RFC 6/6] RCU: Track rcu_dereference() in RCU read-side critical section
On Thu, Feb 04, 2016 at 12:45:12AM +0800, Boqun Feng wrote:
> The variables protected by an RCU read-side critical section are
> sometimes hard to figure out, especially when the critical section is
> long or has some function calls in it. However, figuring out which
> variable a RCU read-side critical section protects could save
> us a lot of time for code reviewing, bug fixing or performance tuning.
>
> This patch therefore uses the LOCKED_ACCESS to collect the information
> of relationship between rcu_dereference*() and rcu_read_lock*() by
> doing:
>
> Step 0: define a locked_access_class for RCU.
>
> Step 1: set the content of rcu_*_lock_key and __srcu_key to the
> address of the locked_access_class for RCU.
>
> Step 2: add locked_access_point() in __rcu_dereference_check()
>
> After that we can figure out not only in which RCU read-side critical
> section but also after which rcu_read_lock*() called an
> rcu_dereference*() is called.
>
> This feature is controlled by a config option RCU_LOCKED_ACCESS.
>
> Also clean up the initialization code of lockdep_maps for different
> flavors of RCU a little bit.
>
> Signed-off-by: Boqun Feng
> ---
> include/linux/rcupdate.h | 8
> include/linux/srcu.h | 8 +++-
> kernel/locking/lockdep.c | 3 +++
> kernel/rcu/update.c | 31 +--
> lib/Kconfig.debug| 12
> 5 files changed, 47 insertions(+), 15 deletions(-)
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 14e6f47..4bab658 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -610,6 +610,13 @@ static inline void rcu_preempt_sleep_check(void)
> #define rcu_dereference_sparse(p, space)
> #endif /* #else #ifdef __CHECKER__ */
>
> +#ifdef CONFIG_RCU_LOCKED_ACCESS
> +extern struct locked_access_class rcu_laclass;
> +#define rcu_dereference_access() \
> + locked_access_point(&rcu_laclass, LOCKED_ACCESS_TYPE_READ)
> +#else /* #ifdef CONFIG_LOCKED_ACCESS */
> +#define rcu_dereference_access()
> +#endif /* #else #ifdef CONFIG_LOCKED_ACCESS */
> #define __rcu_access_pointer(p, space) \
> ({ \
> typeof(*p) *_p1 = (typeof(*p) *__force)READ_ONCE(p); \
> @@ -622,6 +629,7 @@ static inline void rcu_preempt_sleep_check(void)
> typeof(*p) *p1 = (typeof(*p) *__force)lockless_dereference(p); \
> RCU_LOCKDEP_WARN(!(c), "suspicious rcu_dereference_check() usage"); \
> rcu_dereference_sparse(p, space); \
> + rcu_dereference_access(); \
> ((typeof(*p) __force __kernel *)(p1)); \
> })
> #define __rcu_dereference_protected(p, c, space) \
> diff --git a/include/linux/srcu.h b/include/linux/srcu.h
> index f5f80c5..ff048a2 100644
> --- a/include/linux/srcu.h
> +++ b/include/linux/srcu.h
> @@ -64,12 +64,18 @@ struct srcu_struct {
>
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
>
> +# ifdef CONFIG_RCU_LOCKED_ACCESS
> +# define RCU_KEY { .laclass = &rcu_laclass }
> +# else
> +# define RCU_KEY { 0 }
> +# endif
> +
> int __init_srcu_struct(struct srcu_struct *sp, const char *name,
> struct lock_class_key *key);
>
> #define init_srcu_struct(sp) \
> ({ \
> - static struct lock_class_key __srcu_key; \
> + static struct lock_class_key __srcu_key = RCU_KEY; \
This gets me the following for the TASKS01, TINY02, TREE02, TREE05,
TREE06, and TREE08 configurations:
CC mm/mmap.o
In file included from
/home/paulmck/public_git/linux-rcu/include/linux/notifier.h:15:0,
from
/home/paulmck/public_git/linux-rcu/arch/x86/include/asm/kdebug.h:4,
from
/home/paulmck/public_git/linux-rcu/include/linux/kdebug.h:4,
from /home/paulmck/public_git/linux-rcu/kernel/notifier.c:1:
/home/paulmck/public_git/linux-rcu/kernel/notifier.c: In function
‘srcu_init_notifier_head’:
/home/paulmck/public_git/linux-rcu/include/linux/srcu.h:78:16: warning: missing
braces around initializer [-Wmissing-braces]
static struct lock_class_key __srcu_key = RCU_KEY; \
^
/home/paulmck/public_git/linux-rcu/kernel/notifier.c:526:6: note: in expansion
of macro ‘init_srcu_struct’
if (init_srcu_struct(&nh->srcu) < 0)
^
/home/paulmck/public_git/linux-rcu/include/linux/srcu.h:78:16: warning: (near
initialization for ‘__srcu_key.subkeys’) [-Wmissing-braces]
static struct lock_class_key __srcu_key = RCU_KEY; \
^
/home/paulmck/public_git/linux-rcu/kernel/notifier.c:526:6: note: in expansion
of macro ‘init_srcu_struct’
if (init_srcu_struct(&nh->srcu) < 0)
^
These have the following in their .config files:
CONFIG_DEBUG_LOCK_ALLOC=y
However, none of your new Kconfig options are set, which needs to be
tested because this will be the common case. Several of them have
CONFIG_PROVE_LOCKING=y, but others do not.
I have dequeued these for the moment. Please send an updated patch
series when you have this fixed.
Re: [PATCH V7 0/5] rtc: max77686: make max77686 rtc driver as IP driver
On 09/02/2016 at 22:56:29 +0530, Laxman Dewangan wrote : > Based on discussion on patch series of MAX77620 when adding separate > driver for max77620 RTC, it is discussed to reuse the max77686 driver > for all CHips MAX77802, MAX77686 and MAX77620. For this, the rtc-max77686 > need to make as IP driver independent of their MFD parent driver. > > This series makes the rtc-max77686 as independent driver from its > parent. Required information is passed through the device parent > which is generic and does not depends on any max77686 specific > header ifnromation. > > CC: Krzysztof Kozlowski > CC: Javier Martinez Canillas > > Changes from V1: > - Added reviewed/tested by tag which we got from V1. > - Remove changes from Kconfig. > - Maintain all register definition in max77686 private header and remove > the movement to rtc driver. > - Taken care of all comments on V1 from Krzysztof and Javier. > > Changes from V2: > - Fix the issue of crash in unbind. > > Changes from V3: > - Fix suspend-resume after unbind/bind by unmapping virq in remove callback. > > Changes from V5: > - Abandon the addition of new API in regmap-irq and add dispose of virq > in regmap_del_irq_chip(). > > Changes from V6: > - make regmap change as independent of this series and rebase it on linux-next > 20160209 > > Laxman Dewangan (5): > rtc: max77686: fix checkpatch error > rtc: max77686: use rtc regmap to access RTC registers > rtc: max77686: avoid reference of parent device info multiple places > mfd: max77686: do not set i2c client data for rtc i2c client > rtc: max77686: move initialisation of rtc regmap, irq chip locally > All applied, thanks. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
Re: Crashes in arm qemu emulations due to 'cpufreq: governor: Replace timers with utilization ...'
On 15-02-16, 19:41, Rafael J. Wysocki wrote: > On Mon, Feb 15, 2016 at 6:05 PM, Guenter Roeck wrote: > > [1.34] [] (__cpufreq_driver_target) from [] > > (dbs_check_cpu+0x1ac/0x1e8) > > [1.34] [] (dbs_check_cpu) from [] > > (cpufreq_governor_dbs+0x1fc/0x608) > > [1.34] [] (cpufreq_governor_dbs) from [] > > (__cpufreq_governor+0x1a8/0x204) > > [1.34] [] (__cpufreq_governor) from [] > > (cpufreq_init_policy+0x60/0x8c) > > [1.34] [] (cpufreq_init_policy) from [] > > (cpufreq_online+0x2e8/0x708) > > [1.34] [] (cpufreq_online) from [] > > (subsys_interface_register+0x80/0xc4) > > [1.34] [] (subsys_interface_register) from [] > > (cpufreq_register_driver+0x144/0x1a0) > > This is the registration of the cpufreq driver (cpufreq-dt in this case). > > It does > cpufreq_online()->cpufreq_init_policy()->__cpufreq_governor()->cpufreq_governor_dbs()->dbs_check_cpu(). > > The only way that can happen is when cpufreq_set_policy() finds that > the "old" and the "new" policies use the same governor, so it goes and > calls __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS), but I'm not sure > how this is possible during the initialization ATM. > > Viresh, any ideas? You misread probably. During init, policy->gov is NULL and new_policy->gov is set to the default one, probably ondemand/conservative. And in that case, we do: - INIT - START - LIMITS So above sequence is guaranteed to happen rather. -- viresh
Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation
On Tue, 16 Feb 2016 09:47:20 +0900 Joonsoo Kim wrote: > > They return true when CONFIG_TRACEPOINTS is configured in and the > > tracepoint is enabled, and false otherwise. > > This implementation is what you proposed before. Please refer below > link and source. > > https://lkml.org/lkml/2015/12/9/699 > arch/x86/include/asm/msr.h That was a year ago, how am I suppose to remember ;-) > > There is header file dependency problem between mm.h and tracepoint.h. > page_ref.h should be included in mm.h and tracepoint.h cannot > be included in this case. Ah, OK, I forgot about that. I'll take another look at it again. A lot happened since then, that's all a fog to me. -- Steve
Re: [PATCH v6 1/2] ACPI: introduce a function to find the first physical device
On Wednesday, January 20, 2016 08:29:26 PM Aleksey Makarov wrote:
> Factor out the code that finds the first physical device
> of a given ACPI device. It is used in several places.
>
> Reviewed-by: Andy Shevchenko
I guess the above doesn't apply any more, does it?
> Signed-off-by: Aleksey Makarov
> ---
> drivers/acpi/acpi_platform.c | 19 ++-
> drivers/acpi/bus.c | 33 ++---
> drivers/acpi/internal.h | 1 +
> 3 files changed, 25 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/acpi/acpi_platform.c b/drivers/acpi/acpi_platform.c
> index 296b7a1..c3af108 100644
> --- a/drivers/acpi/acpi_platform.c
> +++ b/drivers/acpi/acpi_platform.c
> @@ -43,7 +43,6 @@ static const struct acpi_device_id forbidden_id_list[] = {
> struct platform_device *acpi_create_platform_device(struct acpi_device *adev)
> {
> struct platform_device *pdev = NULL;
> - struct acpi_device *acpi_parent;
> struct platform_device_info pdevinfo;
> struct resource_entry *rentry;
> struct list_head resource_list;
> @@ -82,22 +81,8 @@ struct platform_device *acpi_create_platform_device(struct
> acpi_device *adev)
>* attached to it, that physical device should be the parent of the
>* platform device we are about to create.
>*/
> - pdevinfo.parent = NULL;
> - acpi_parent = adev->parent;
> - if (acpi_parent) {
> - struct acpi_device_physical_node *entry;
> - struct list_head *list;
> -
> - mutex_lock(&acpi_parent->physical_node_lock);
> - list = &acpi_parent->physical_node_list;
> - if (!list_empty(list)) {
> - entry = list_first_entry(list,
> - struct acpi_device_physical_node,
> - node);
> - pdevinfo.parent = entry->dev;
> - }
> - mutex_unlock(&acpi_parent->physical_node_lock);
> - }
> + pdevinfo.parent = adev->parent ?
> + acpi_get_first_physical_node(adev->parent) : NULL;
> pdevinfo.name = dev_name(&adev->dev);
> pdevinfo.id = -1;
> pdevinfo.res = resources;
> diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
> index a212cef..832b26d 100644
> --- a/drivers/acpi/bus.c
> +++ b/drivers/acpi/bus.c
> @@ -478,24 +478,35 @@ static void acpi_device_remove_notify_handler(struct
> acpi_device *device)
> Device Matching
>
> -- */
>
> -static struct acpi_device *acpi_primary_dev_companion(struct acpi_device
> *adev,
> - const struct device *dev)
> +/**
> + * acpi_device_fix_parent - Get first physical node of an ACPI device
Please fix the function name here.
> + * @adev: ACPI device in question
> + */
> +struct device *acpi_get_first_physical_node(struct acpi_device *adev)
> {
> struct mutex *physical_node_lock = &adev->physical_node_lock;
> + struct device *node = NULL;
>
> mutex_lock(physical_node_lock);
> - if (list_empty(&adev->physical_node_list)) {
> - adev = NULL;
> - } else {
> - const struct acpi_device_physical_node *node;
>
> + if (!list_empty(&adev->physical_node_list))
> node = list_first_entry(&adev->physical_node_list,
> - struct acpi_device_physical_node, node);
> - if (node->dev != dev)
> - adev = NULL;
> - }
> + struct acpi_device_physical_node, node)->dev;
> +
No, you don't have to change all that code.
Exercise: rework this function with as few lines of code changed as you
possibly can.
> mutex_unlock(physical_node_lock);
> - return adev;
> +
> + return node;
> +}
> +
> +static struct acpi_device *acpi_primary_dev_companion(struct acpi_device
> *adev,
> + const struct device *dev)
> +{
> + const struct device *node = acpi_get_first_physical_node(adev);
s/node/phys_dev/ ?
> +
> + if (node && node == dev)
> + return adev;
> +
> + return NULL;
return phys_dev && phys_dev == dev ? adev : NULL;
One line of code instead of 4.
> }
>
> /**
> diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
> index 11d87bf..ee9312ba 100644
> --- a/drivers/acpi/internal.h
> +++ b/drivers/acpi/internal.h
> @@ -98,6 +98,7 @@ bool acpi_device_is_present(struct acpi_device *adev);
> bool acpi_device_is_battery(struct acpi_device *adev);
> bool acpi_device_is_first_physical_node(struct acpi_device *adev,
> const struct device *dev);
> +struct device *acpi_get_first_physical_node(struct acpi_device *adev);
>
> /* --
> Device
Re: [PATCH v6 1/2] ACPI: introduce a function to find the first physical device
On Wednesday, January 20, 2016 05:12:18 PM Andy Shevchenko wrote:
> On Wed, Jan 20, 2016 at 4:29 PM, Aleksey Makarov
> wrote:
> > Factor out the code that finds the first physical device
> > of a given ACPI device. It is used in several places.
> >
> > Reviewed-by: Andy Shevchenko
> > Signed-off-by: Aleksey Makarov
>
> Hmm… Sorry, didn't notice one style issue and there is one is matter
> of taste below.
>
> > --- a/drivers/acpi/acpi_platform.c
> > +++ b/drivers/acpi/acpi_platform.c
> > @@ -43,7 +43,6 @@ static const struct acpi_device_id forbidden_id_list[] = {
>
> > + pdevinfo.parent = adev->parent ?
> > + acpi_get_first_physical_node(adev->parent) : NULL;
>
> Matter of taste, but I believe if-else looks better here even when
> consumes +2 LOC.
I disagree.
Thanks,
Rafael
[PATCH] Add fix case for open braces
Some quite excellent fixes from Joe Perches that belong
back in the original. Submitting to Joe for inclusion. Joe
was the original author of these fixes that save a lot of time
rewriting code. Thanks Joe.
Signed-off-by: Jeffrey Merkey
---
scripts/checkpatch.pl | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 874132b..71f93e8 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3108,9 +3108,15 @@ sub process {
#print
"pre<$pre_ctx>\nline<$line>\nctx<$ctx>\nnext<$lines[$ctx_ln - 1]>\n";
if ($ctx !~ /{\s*/ && defined($lines[$ctx_ln - 1]) &&
$lines[$ctx_ln - 1] =~ /^\+\s*{/) {
- ERROR("OPEN_BRACE",
- "that open brace { should be on the
previous line\n" .
- "$here\n$ctx\n$rawlines[$ctx_ln -
1]\n");
+ if (ERROR("OPEN_BRACE",
+ "that open brace { should be on the
previous line\n" .
+ "$here\n$ctx\n$rawlines[$ctx_ln -
1]\n") &&
+ $fix &&
+ $rawlines[$ctx_ln - 2] =~ /^\+/ &&
+ $rawlines[$ctx_ln - 1] =~ /^\+\s*{\s*$/) {
+ $fixed[$ctx_ln - 2] =
rtrim($fixed[$ctx_ln - 2]) . ' {';
+ fix_delete_line($ctx_ln - 1,
$rawlines[$ctx_ln - 1]);
+ }
}
if ($level == 0 && $pre_ctx !~ /}\s*while\s*\($/ &&
$ctx =~ /\)\s*\;\s*$/ &&
@@ -4807,8 +4813,15 @@ sub process {
$herectx .= raw_line($linenr, $n) .
"\n";
}
- WARN("BRACES",
-"braces {} are not necessary for single
statement blocks\n" . $herectx);
+ if (WARN("BRACES",
+ "braces {} are not necessary for single
statement blocks\n" . $herectx) &&
+ $fix &&
+ $fixed[$fixlinenr] =~ /^\+.*\{\s*$/ &&
+ $fixed[$fixlinenr + 1] =~ /^\+.*;\s*$/
&&
+ $fixed[$fixlinenr + 2] =~
/^\+\s*\}\s*$/) {
+ $fixed[$fixlinenr] =~ s/\{\s*$//;
+ fix_delete_line($fixlinenr + 2,
$rawlines[$fixlinenr + 2]);
+ }
}
}
--
1.8.3.1
Re: [PATCH v6 2/2] ACPI: amba bus probing support
On Wednesday, January 20, 2016 08:29:27 PM Aleksey Makarov wrote: > From: Graeme Gregory > > On ARM64 some devices use the AMBA device and not the platform bus for > probing so add support for this. Uses a dummy clock for apb_pclk as ACPI > does not have a suitable clock representation and to keep the core > AMBA bus code unchanged between probing methods. > > Acked-by: Russell King > Signed-off-by: Graeme Gregory > Signed-off-by: Aleksey Makarov This one looks OK to me, so please just post an update of the [1/2]. Thanks, Rafael
