Re: [PATCH v6 2/2] leds: rt5033: Add RT5033 Flash led device driver
Hi Jacek,
Thanks for the review.
On 2015년 11월 26일 00:13, Jacek Anaszewski wrote:
> Hi Ingi,
>
> Thanks for the update.
>
> On 11/25/2015 11:22 AM, Ingi Kim wrote:
>> This patch adds device driver of Richtek RT5033 PMIC.
>> The RT5033 Flash LED Circuit is designed for one or two LEDs driving
>> for torch and strobe applications, it provides an I2C software command
>> to trigger the torch and strobe operation.
>>
>> Each of LED outputs can contorl a separate LED sharing their setting,
>
> s/contorl/control/
>
Oh, I see, Thanks
>> and can be connected together for a single connected LED.
>> One LED is represented by one child node.
>>
>> Signed-off-by: Ingi Kim
>> ---
>> drivers/leds/Kconfig | 8 +
>> drivers/leds/Makefile | 1 +
>> drivers/leds/leds-rt5033.c | 541
>> +
>> include/linux/mfd/rt5033-private.h | 51
>> 4 files changed, 601 insertions(+)
>> create mode 100644 drivers/leds/leds-rt5033.c
>>
>> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
>> index b1ab8bd..f41ac9b 100644
>> --- a/drivers/leds/Kconfig
>> +++ b/drivers/leds/Kconfig
>> @@ -345,6 +345,14 @@ config LEDS_PCA963X
>> LED driver chip accessed via the I2C bus. Supported
>> devices include PCA9633 and PCA9634
>>
>> +config LEDS_RT5033
>> +tristate "LED support for RT5033 PMIC"
>> +depends on LEDS_CLASS_FLASH && OF
>> +depends on MFD_RT5033
>> +help
>> + This option enables support for on-chip LED driver on
>> + RT5033 PMIC.
>> +
>> config LEDS_WM831X_STATUS
>> tristate "LED support for status LEDs on WM831x PMICs"
>> depends on LEDS_CLASS
>> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
>> index e9d53092..77cfad5 100644
>> --- a/drivers/leds/Makefile
>> +++ b/drivers/leds/Makefile
>> @@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+= leds-cobalt-qube.o
>> obj-$(CONFIG_LEDS_COBALT_RAQ)+= leds-cobalt-raq.o
>> obj-$(CONFIG_LEDS_SUNFIRE)+= leds-sunfire.o
>> obj-$(CONFIG_LEDS_PCA9532)+= leds-pca9532.o
>> +obj-$(CONFIG_LEDS_RT5033)+= leds-rt5033.o
>> obj-$(CONFIG_LEDS_GPIO_REGISTER)+= leds-gpio-register.o
>> obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
>> obj-$(CONFIG_LEDS_LP3944)+= leds-lp3944.o
>> diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
>> new file mode 100644
>> index 000..256df74
>> --- /dev/null
>> +++ b/drivers/leds/leds-rt5033.c
>> @@ -0,0 +1,541 @@
>> +/*
>> + * led driver for RT5033
>> + *
>> + * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
>> + * Ingi Kim
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +#define RT5033_LED_FLASH_TIMEOUT_MIN64000
>> +#define RT5033_LED_FLASH_TIMEOUT_STEP32000
>> +#define RT5033_LED_FLASH_BRIGHTNESS_MIN5
>> +#define RT5033_LED_FLASH_BRIGHTNESS_MAX_1CH60
>> +#define RT5033_LED_FLASH_BRIGHTNESS_MAX_2CH80
>> +#define RT5033_LED_FLASH_BRIGHTNESS_STEP25000
>> +#define RT5033_LED_TORCH_BRIGHTNESS_MIN12500
>> +#define RT5033_LED_TORCH_BRIGHTNESS_STEP12500
>> +
>> +#define FLED1_IOUT(BIT(0))
>> +#define FLED2_IOUT(BIT(1))
>> +
>> +enum rt5033_fled {
>> +FLED1,
>> +FLED2,
>> +};
>> +
>> +struct rt5033_sub_led {
>> +enum rt5033_fled fled_id;
>> +struct led_classdev_flash fled_cdev;
>> +
>> +u32 flash_brightness;
>> +u32 flash_timeout;
>> +};
>> +
>> +/* RT5033 Flash led platform data */
>> +struct rt5033_led {
>> +struct device *dev;
>> +struct mutex lock;
>> +struct regmap *regmap;
>> +struct rt5033_sub_led sub_leds[2];
>> +
>> +u32 current_flash_timeout;
>> +u32 current_flash_brightness;
>> +
>> +bool iout_joint;
>> +u8 fled_mask;
>> +u8 current_iout;
>> +};
>> +
>> +struct rt5033_led_config_data {
>> +const char *label[2];
>> +u32 flash_max_microamp[2];
>> +u32 flash_max_timeout[2];
>> +u32 torch_max_microamp[2];
>> +u32 num_leds;
>> +};
>> +
>> +static u8 rt5033_torch_brightness_to_reg(u32 ua)
>> +{
>> +return (ua - RT5033_LED_TORCH_BRIGHTNESS_MIN) /
>> +RT5033_LED_TORCH_BRIGHTNESS_STEP;
>> +}
>> +
>> +static u8 rt5033_flash_brightness_to_reg(u32 ua)
>> +{
>> +return (ua - RT5033_LED_FLASH_BRIGHTNESS_MIN) /
>> +RT5033_LED_FLASH_BRIGHTNESS_STEP;
>> +}
>> +
>> +static u8 rt5033_flash_timeout_to_reg(u32 us)
>> +{
>> +return (us - RT5033_LED_FLASH_TIMEOUT_MIN) /
>> +RT5033_LED_FLASH_TIMEOUT_STEP;
>> +}
>
> Previous solution with macro was fine. Please bring it back, but rename
> as I asked in the previous review.
>
Okay, I'll change it
>> +static struct rt5033_sub_led *flcdev_to
[PATCH v1] mm: hugetlb: call huge_pte_alloc() only if ptep is null
Currently at the beginning of hugetlb_fault(), we call huge_pte_offset()
and check whether the obtained *ptep is a migration/hwpoison entry or not.
And if not, then we get to call huge_pte_alloc(). This is racy because the
*ptep could turn into migration/hwpoison entry after the huge_pte_offset()
check. This race results in BUG_ON in huge_pte_alloc().
We don't have to call huge_pte_alloc() when the huge_pte_offset() returns
non-NULL, so let's fix this bug with moving the code into else block.
Note that the *ptep could turn into a migration/hwpoison entry after
this block, but that's not a problem because we have another !pte_present
check later (we never go into hugetlb_no_page() in that case.)
Fixes: 290408d4a250 ("hugetlb: hugepage migration core")
Signed-off-by: Naoya Horiguchi
Cc: [2.6.36+]
---
mm/hugetlb.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git next-20151123/mm/hugetlb.c next-20151123_patched/mm/hugetlb.c
index 1101ccd..6ad5e91 100644
--- next-20151123/mm/hugetlb.c
+++ next-20151123_patched/mm/hugetlb.c
@@ -3696,12 +3696,12 @@ int hugetlb_fault(struct mm_struct *mm, struct
vm_area_struct *vma,
} else if (unlikely(is_hugetlb_entry_hwpoisoned(entry)))
return VM_FAULT_HWPOISON_LARGE |
VM_FAULT_SET_HINDEX(hstate_index(h));
+ } else {
+ ptep = huge_pte_alloc(mm, address, huge_page_size(h));
+ if (!ptep)
+ return VM_FAULT_OOM;
}
- ptep = huge_pte_alloc(mm, address, huge_page_size(h));
- if (!ptep)
- return VM_FAULT_OOM;
-
mapping = vma->vm_file->f_mapping;
idx = vma_hugecache_offset(h, vma, address);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 06/13] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
On Thu, Nov 26, 2015 at 03:03:54PM +0800, Chris Zhong wrote:
> Hi Thierry
>
> Thanks for your feedback.
>
>
> On 11/21/2015 12:07 AM, Thierry Reding wrote:
> >On Fri, Nov 20, 2015 at 04:15:32PM +0800, Chris Zhong wrote:
> >>add Synopsys DesignWare MIPI DSI host controller driver support.
> >>
> >>Signed-off-by: Chris Zhong
> >>---
> >>
> >>Changes in v4:
> >>eliminate some warnning
> >>
> >>Changes in v3: None
> >>Changes in v2: None
> >>
> >> drivers/gpu/drm/bridge/Kconfig | 11 +
> >> drivers/gpu/drm/bridge/Makefile |1 +
> >> drivers/gpu/drm/bridge/dw_mipi_dsi.c | 1056
> >> ++
> >> include/drm/bridge/dw_mipi_dsi.h | 27 +
> >> 4 files changed, 1095 insertions(+)
> >> create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c
> >> create mode 100644 include/drm/bridge/dw_mipi_dsi.h
> >>
> >>
> >>+struct dw_mipi_dsi {
> >>+ struct mipi_dsi_host dsi_host;
> >>+ struct drm_connector connector;
> >>+ struct drm_encoder *encoder;
> >struct drm_bridge already has a pointer to an encoder, can't you reuse
> >that instead?
> >
> >>+ struct drm_bridge *bridge;
> >Typically you'd embed the bridge into the driver structure.
> I'm almost done with all the modifications according to your comments.
> Remaining this point I can not understand, the dsi is a pointer of
> drm_bridge,
> hence I can not get the bridge by container_of.
> Although, the "bridge->driver_private = dsi" have done in
> dw_mipi_dsi_register.
I don't understand. If you don't make bridge a pointer, but rather embed
it within the structure, then you can use container_of(), can't you? You
get it allocated automatically as part of allocating the dw_mipi_dsi
structure. See for example the ps8622 and ptn3460 bridge drivers.
On a slightly unrelated note, I'm not sure if we discussed this already
or if it was in another thread, but why is this even a bridge driver? A
bridge is typically some IC outside of the SoC, whereas this clearly is
IP designed into the SoC. So it's really more of an encoder rather than
a bridge.
Thierry
signature.asc
Description: PGP signature
Re: [PATCH] cgroups: move cpuset specific checks from generic code to cpuset_can_attach
On Wed, Nov 25, 2015 at 08:01:17PM -0200, Marcelo Tosatti wrote: > > Move PF_NO_SETAFFINITY check to cpuset cgroups, where it belongs. > This makes it possible to attach PF_NO_SETAFFINITY to Intel CAT cgroups. Looks that's the right place. I tried intel_rdt subsystem at least it doesn't have this restriction anymore (all the tasks can be moved out of the default group), hence: Reviewed-by: Chao Peng Chao -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf tools: Always give options even it not compiled
On 2015/11/20 18:54, 平松雅巳 / HIRAMATU，MASAMI wrote:
From: Wang Nan [mailto:wangn...@huawei.com]
This patch keeps options of perf builtins same in all condition. If the
option is disabled because of compiling options, users should be
notified.
This patch does it by introducing a series of new option macros, flags
and field in struct options. For those options disabled by compiling,
OPT_NOTBUILT_NOARG, OPT_NOTBUILT_OPTARG and OPT_NOTBUILT can be used
to record the help messages and the reason why not built them.
Options in 'perf record' and 'perf probe' are fixed by those new macros.
Hmm, OK, I agree the reason why this is useful. Could you reconsider
the implementation, because just cloning the code is ugly and not
maintainable?
It will be better if we can replace OPT_BOOLEAN with;
OPT_DEPENDS(HAVE_DWARF_SUPPORT, BOOLEAN, '\0', "no-inlines",
&probe_conf.no_inlines, ...
This may be done by following macros ;
#define OPTMSG_HAVE_DWARF_SUPPORT "NO_DWARF"
#ifdef HAVE_DWARF_SUPPORT
#define OPTVAL_HAVE_DWARF_SUPPORT 1
#else
#define OPTVAL_HAVE_DWARF_SUPPORT 0
#endif
#define __OPT_DEPENDS(val, msg, opt, ...) \
{.type = OPTION_NEXT_DEPENDS, .value = (void *)val, .data = msg, },
opt(__VA_ARGS__)
#define _OPT_DEPENDS(val, msg, opt, ...)\
__OPT_DEPENDS(val, msg, opt, __VA_ARGS__)
#define OPT_DEPENDS(flag, opt, ...) \
_OPT_DEPENDS(OPTVAL_ ## flag, OPTMSG_ ## flag, OPT_ ## opt, __VA_ARGS__)
And if the parser find OPTION_NEXT_DEPENDS and .value != NULL, it skips next
entry.
That would be good, but don't forget we have a options__order() which
reorder the options array. To archive our goal I think we must preprocess
the options array to 'merge' information in the OPTION_NEXT_DEPENDS into
the real option it decorates.
Thank you.
Thank you,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] ASoC: hdac_hdmi: convert num_nodes to int
All uses of num_nodes are considering it as a signed integer and that is
very much clear when we try to save the error value in it and later try
to compare it with less than 0.
Signed-off-by: Sudip Mukherjee
---
include/sound/hdaudio.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h
index e2b712c..c5fad14 100644
--- a/include/sound/hdaudio.h
+++ b/include/sound/hdaudio.h
@@ -71,7 +71,7 @@ struct hdac_device {
unsigned int flags, unsigned int *res);
/* widgets */
- unsigned int num_nodes;
+ int num_nodes;
hda_nid_t start_nid, end_nid;
/* misc flags */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink+0x4b/0x50()
On 11/25/2015 10:54 PM, OGAWA Hirofumi wrote: Vegard Nossum writes: On 11/23/2015 11:21 PM, Richard Weinberger wrote: Am 23.11.2015 um 08:55 schrieb Vegard Nossum: With the attached vfat disk image (fuzzed), I get the following WARNING: WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink+0x4b/0x50() [...] Can you try this one? That seems to fix the problem here, thanks! The last potential issue I'm seeing (completely unrelated to your patch) is this: [ 340.61] VFS: Lookup of '1' in vfat loop0 would have caused loop [ 354.36] d_splice_alias: 1104 callbacks suppressed [ 354.36] VFS: Lookup of '1' in vfat loop0 would have caused loop Is that worth investigating closer? Thanks, Vegard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 0/7] perf/core improvements and fixes
* Ingo Molnar wrote: > > * Arnaldo Carvalho de Melo wrote: > > > Hi Ingo, > > > > Please consider pulling, > > > > - Arnaldo > > > > > > The following changes since commit b7883a1c4f75edb62fc49da6000c59fb881e3c7b: > > > > perf/x86: Handle multiple umask bits for BDW CYCLE_ACTIVITY.* (2015-11-23 > > 09:58:27 +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 646a6e846c4dc3812c614fd061603b6db5b8d380: > > > > perf callchain: Add missing parent_val initialization (2015-11-23 > > 18:31:25 -0300) > > > > > > perf/core improvements and fixes: > > > > User visible: > > > > - Allow callchain order (caller, callee) to the libdw and libunwind based > > DWARF > > unwinders (Jiri Olsa) > > > > - Add missing parent_val initialization in the callchain code, fixing a > > SEGFAULT when using callchains with 'perf top' (Jiri Olsa) > > > > - Add initial 'perf config' command, for now just with a --list command to > > show the contents of the configuration file in use and a basic man page > > describing its format, commands for doing edits and detailed documentation > > are being reviewed and proof-read. (Taeung Song) > > > > Signed-off-by: Arnaldo Carvalho de Melo > > > > > > Jiri Olsa (5): > > perf callchain: Move initial entry call into get_entries function > > perf callchain: Add order support for libunwind DWARF unwinder > > perf test: Add callchain order setup for DWARF unwinder test > > perf callchain: Add order support for libdw DWARF unwinder > > perf callchain: Add missing parent_val initialization > > > > Taeung Song (2): > > perf tools: Add 'perf config' command > > perf config: Add initial man page > > > > tools/perf/Build | 1 + > > tools/perf/Documentation/perf-config.txt | 103 > > +++ > > tools/perf/builtin-config.c | 66 > > tools/perf/builtin.h | 1 + > > tools/perf/command-list.txt | 1 + > > tools/perf/perf.c| 1 + > > tools/perf/tests/dwarf-unwind.c | 22 ++- > > tools/perf/util/callchain.h | 1 + > > tools/perf/util/unwind-libdw.c | 53 +++- > > tools/perf/util/unwind-libdw.h | 2 + > > tools/perf/util/unwind-libunwind.c | 60 +++--- > > 11 files changed, 272 insertions(+), 39 deletions(-) > > create mode 100644 tools/perf/Documentation/perf-config.txt > > create mode 100644 tools/perf/builtin-config.c > > Hm, I noticed something weird - I think it started with this pull request - > the > feature detection build messages come mixed with the regular build: As per the discussion that followed, this seems to be an old and unrelated bug, so I pulled your tree, thanks a lot Arnaldo! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
QUEUE_FLAG_NO_SG_MERGE and non-block-mq
Hi all, while investigating the crash in scsi_lib.c I found a rather curious behaviour for QUEUE_FLAG_NO_SG_MERGE. While the flag is evaluated in blk_recalc_rq_segments and blk_recount_segments (resulting in nr_phys_segments being computed based on that flag) it is completely ignored during blk_rq_map_sg() or the actual merging itself. This typically shouldn't be an issue, seeing that with QUEUE_FLAG_NO_SG_MERGE nr_phys_segments will always be larger than the actual segment count. However, it still makes me wonder: What is the point of having a QUEUE_FLAG_NO_SG_MERGE which doesn't work as advertised? Or, to be precise, which only works for blk-mq? Should we make it work for non-block-mq, too? Cheers, Hannes -- Dr. Hannes ReineckezSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remoteproc: avoid stack overflow in debugfs file
On Fri, Nov 20, 2015 at 7:26 PM, Arnd Bergmann wrote:
> Recent gcc versions warn about reading from a negative offset of
> an on-stack array:
>
> drivers/remoteproc/remoteproc_debugfs.c: In function 'rproc_recovery_write':
> drivers/remoteproc/remoteproc_debugfs.c:167:9: warning: 'buf[4294967295u]'
> may be used uninitialized in this function [-Wmaybe-uninitialized]
>
> I don't see anything in sys_write() that prevents us from
> being called with a zero 'count' argument, so we should
> add an extra check in rproc_recovery_write() to prevent the
> access and avoid the warning.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 2e37abb89a2e ("remoteproc: create a 'recovery' debugfs entry")
Applied to remoteproc-fixes, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] powerpc: tracing: don't trace hcalls on offline CPUs
On 11/26/15, Michael Ellerman wrote: > On Tue, 2015-11-24 at 21:23 +0300, Denis Kirjanov wrote: > >> ./drmgr -c cpu -a -r gives the following warning: >> >> [ 2327.035563] RCU used illegally from offline CPU! >> rcu_scheduler_active = 1, debug_locks = 1 >> [ 2327.035564] no locks held by swapper/12/0. >> [ 2327.035565] stack backtrace: >> [ 2327.035567] CPU: 12 PID: 0 Comm: swapper/12 Tainted: G S > >> 4.3.0-rc3-00060-g353169a #5 >> [ 2327.035568] Call Trace: >> [ 2327.035573] [c001d62578e0] [c08977fc] .dump_stack+0x98/0xd4 >> (unreliable) >> [ 2327.035577] [c001d6257960] [c0109bd8] >> .lockdep_rcu_suspicious+0x108/0x170 >> [ 2327.035580] [c001d62579f0] [c006a1d0] >> .__trace_hcall_exit+0x2b0/0x2c0 >> [ 2327.035584] [c001d6257ab0] [c006a2e8] >> plpar_hcall_norets_trace+0x70/0x8c >> [ 2327.035588] [c001d6257b20] [c0067a14] >> .icp_hv_set_cpu_priority+0x54/0xc0 >> [ 2327.035592] [c001d6257ba0] [c0066c5c] >> .xics_teardown_cpu+0x5c/0xa0 >> [ 2327.035595] [c001d6257c20] [c00747ac] >> .pseries_mach_cpu_die+0x6c/0x320 >> [ 2327.035598] [c001d6257cd0] [c00439cc] .cpu_die+0x3c/0x60 >> [ 2327.035602] [c001d6257d40] [c00183d8] >> .arch_cpu_idle_dead+0x28/0x40 >> [ 2327.035606] [c001d6257db0] [c00ff1dc] >> .cpu_startup_entry+0x4fc/0x560 >> [ 2327.035610] [c001d6257ed0] [c0043728] >> .start_secondary+0x328/0x360 >> [ 2327.035614] [c001d6257f90] [c0008a6c] >> start_secondary_prolog+0x10/0x14 >> [ 2327.035620] cpu 12 (hwid 12) Ready to die... >> [ 2327.144463] cpu 13 (hwid 13) Ready to die... >> [ 2327.294180] cpu 14 (hwid 14) Ready to die... >> [ 2327.403599] cpu 15 (hwid 15) Ready to die... > > > I can't get this to hit. > > I've got LOCKDEP=y, I've enabled the hcall tracepoints, and then I offline > a > cpu via sysfs. I haven't tried it via sysfs. Could you share the command so I give a try to reproduce. > > What am I missing? Or does it only hit when you use drmgr? Right, I hit it with drmgr... > > cheers > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 0/4] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi, > > Please consider pulling, this is on top of my previous > perf-core-for-mingo pull request. > > - Arnaldo > > The following changes since commit 646a6e846c4dc3812c614fd061603b6db5b8d380: > > perf callchain: Add missing parent_val initialization (2015-11-23 18:31:25 > -0300) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git > tags/perf-core-for-mingo-2 > > for you to fetch changes up to d8ad6a15cc3a364de6c8010378adc3fb06ce3ff1: > > tools lib bpf: Don't do a feature check when cleaning (2015-11-25 16:38:13 > -0300) > > > perf/core improvements and fixes: > > User visible: > > - Fix to free temporal Dwarf_Frame correctly in 'perf probe', fixing a > regression introduced in perf/core that prevented, at least, adding > an uprobe collecting function parameter values (Masami Hiramatsu) > > - Fix output of %llu for 64 bit values read on 32 bit machines in > libtraceevent (Steven Rostedt) > > Developer visible: > > - Clean CFLAGS and LDFLAGS for fixdep in tools/build (Wang Nan) > > - Don't do a feature check when cleaning tools/lib/bpf (Wang Nan) > > Signed-off-by: Arnaldo Carvalho de Melo > > > Masami Hiramatsu (1): > perf probe: Fix to free temporal Dwarf_Frame correctly > > Steven Rostedt (1): > tools lib traceevent: Fix output of %llu for 64 bit values read on 32 > bit machines > > Wang Nan (2): > tools build: Clean CFLAGS and LDFLAGS for fixdep > tools lib bpf: Don't do a feature check when cleaning > > tools/build/Makefile.include | 2 +- > tools/lib/bpf/Makefile | 10 ++ > tools/lib/traceevent/event-parse.c | 5 ++--- > tools/perf/util/probe-finder.c | 13 ++--- > 4 files changed, 19 insertions(+), 11 deletions(-) Pulled, thanks a lot Arnaldo! Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] vmscan: do not throttle kthreads due to too_many_isolated
On Wed, Nov 25, 2015 at 07:27:57PM +0300, Vladimir Davydov wrote: > On Wed, Nov 25, 2015 at 04:45:13PM +0100, Vlastimil Babka wrote: > > On 11/25/2015 04:36 PM, Vladimir Davydov wrote: > > > Block device drivers often hand off io request processing to kernel > > > threads (example: device mapper). If such a thread calls kmalloc, it can > > > dive into direct reclaim path and end up waiting for too_many_isolated > > > to return false, blocking writeback. This can lead to a dead lock if the > > > > Shouldn't such allocation lack __GFP_IO to prevent this and other kinds of > > deadlocks? And/or have mempools? > > Not necessarily. loopback is an example: it can call > grab_cache_write_begin -> add_to_page_cache_lru with GFP_KERNEL. Anyway, kthreads that use GFP_NOIO and/or mempool aren't safe either, because it isn't an allocation context problem: the reclaimer locks up not because it tries to take an fs/io lock the caller holds, but because it waits for isolated pages to be put back, which will never happen, since processes that isolated them depend on the kthread making progress. This is purely a reclaimer heuristic, which kmalloc users are not aware of. My point is that, in contrast to userspace processes, it is dangerous to throttle kthreads in the reclaimer, because they might be responsible for reclaimer progress (e.g. performing writeback). Regarding side effects of this patch. Well, there aren't many kthreads out there, so I don't believe this can put the system under the risk of thrashing because of isolating too many reclaimable pages. Thanks, Vladimir > > > PF_KTHREAD looks like a big hammer to me that will solve only one > > potential problem... > > This problem can result in processes hanging forever. Any ideas how this > could be fixed in a better way? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf callchain: Add order support for libunwind DWARF unwinder
Commit-ID: cb1dc22dce6e54dbd1eac213c9216e1aa57084da
Gitweb: http://git.kernel.org/tip/cb1dc22dce6e54dbd1eac213c9216e1aa57084da
Author: Jiri Olsa
AuthorDate: Wed, 18 Nov 2015 08:52:47 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 23 Nov 2015 18:30:41 -0300
perf callchain: Add order support for libunwind DWARF unwinder
As reported by Milian, currently for DWARF unwind (both libdw and
libunwind) we display callchain in callee order only.
Adding the support to follow callchain order setup to libunwind DWARF
unwinder, so we could get following output for report:
$ perf record --call-graph dwarf ls
...
$ perf report --no-children --stdio
39.26% ls libc-2.21.so [.] __strcoll_l
|
---__strcoll_l
mpsort_with_tmp
mpsort_with_tmp
sort_files
main
__libc_start_main
_start
0
$ perf report -g caller --no-children --stdio
...
39.26% ls libc-2.21.so [.] __strcoll_l
|
---0
_start
__libc_start_main
main
sort_files
mpsort_with_tmp
mpsort_with_tmp
__strcoll_l
Based-on-patch-by: Milian Wolff
Reported-and-Tested-by: Milian Wolff
Signed-off-by: Jiri Olsa
Tested-by: Arnaldo Carvalho de Melo
Tested-by: Wang Nan
Cc: David Ahern
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link: http://lkml.kernel.org/r/20151118075247.ga5...@krava.brq.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/unwind-libunwind.c | 47 --
1 file changed, 30 insertions(+), 17 deletions(-)
diff --git a/tools/perf/util/unwind-libunwind.c
b/tools/perf/util/unwind-libunwind.c
index 0ae8844..3c258a0 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -615,34 +615,47 @@ static int get_entries(struct unwind_info *ui,
unwind_entry_cb_t cb,
void *arg, int max_stack)
{
u64 val;
+ unw_word_t ips[max_stack];
unw_addr_space_t addr_space;
unw_cursor_t c;
- int ret;
+ int ret, i = 0;
ret = perf_reg_value(&val, &ui->sample->user_regs, PERF_REG_IP);
if (ret)
return ret;
- ret = entry(val, ui->thread, cb, arg);
- if (ret)
- return -ENOMEM;
+ ips[i++] = (unw_word_t) val;
- if (--max_stack == 0)
- return 0;
-
- addr_space = thread__priv(ui->thread);
- if (addr_space == NULL)
- return -1;
+ /*
+* If we need more than one entry, do the DWARF
+* unwind itself.
+*/
+ if (max_stack - 1 > 0) {
+ addr_space = thread__priv(ui->thread);
+ if (addr_space == NULL)
+ return -1;
+
+ ret = unw_init_remote(&c, addr_space, ui);
+ if (ret)
+ display_error(ret);
+
+ while (!ret && (unw_step(&c) > 0) && i < max_stack) {
+ unw_get_reg(&c, UNW_REG_IP, &ips[i]);
+ ++i;
+ }
- ret = unw_init_remote(&c, addr_space, ui);
- if (ret)
- display_error(ret);
+ max_stack = i;
+ }
- while (!ret && (unw_step(&c) > 0) && max_stack--) {
- unw_word_t ip;
+ /*
+* Display what we got based on the order setup.
+*/
+ for (i = 0; i < max_stack && !ret; i++) {
+ int j = i;
- unw_get_reg(&c, UNW_REG_IP, &ip);
- ret = ip ? entry(ip, ui->thread, cb, arg) : 0;
+ if (callchain_param.order == ORDER_CALLER)
+ j = max_stack - i - 1;
+ ret = ips[j] ? entry(ips[j], ui->thread, cb, arg) : 0;
}
return ret;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/2] ALSA: compress: Add procfs info file for compressed nodes
On Wed, Nov 25, 2015 at 01:00:22PM +, Richard Fitzgerald wrote: > This updates the compress core code to create an 'info' file under procfs > for each compressed node, like the PCM core does for PCM nodes. > > Based off Takashi's for-next Looks good to me.. Acked-by: Vinod Koul -- ~Vinod -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf callchain: Move initial entry call into get_entries function
Commit-ID: b26b218a1e9c5815cb8964e180b7fba3cd9bd509
Gitweb: http://git.kernel.org/tip/b26b218a1e9c5815cb8964e180b7fba3cd9bd509
Author: Jiri Olsa
AuthorDate: Tue, 17 Nov 2015 16:05:37 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 23 Nov 2015 18:30:10 -0300
perf callchain: Move initial entry call into get_entries function
Moving initial entry call into get_entries function so all entries
processing is on one place. It will be useful for next change that adds
ordering logic.
Signed-off-by: Jiri Olsa
Tested-by: Milian Wolff
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1447772739-18471-2-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/unwind-libunwind.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/tools/perf/util/unwind-libunwind.c
b/tools/perf/util/unwind-libunwind.c
index c83832b..0ae8844 100644
--- a/tools/perf/util/unwind-libunwind.c
+++ b/tools/perf/util/unwind-libunwind.c
@@ -614,10 +614,22 @@ void unwind__finish_access(struct thread *thread)
static int get_entries(struct unwind_info *ui, unwind_entry_cb_t cb,
void *arg, int max_stack)
{
+ u64 val;
unw_addr_space_t addr_space;
unw_cursor_t c;
int ret;
+ ret = perf_reg_value(&val, &ui->sample->user_regs, PERF_REG_IP);
+ if (ret)
+ return ret;
+
+ ret = entry(val, ui->thread, cb, arg);
+ if (ret)
+ return -ENOMEM;
+
+ if (--max_stack == 0)
+ return 0;
+
addr_space = thread__priv(ui->thread);
if (addr_space == NULL)
return -1;
@@ -640,24 +652,17 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
struct thread *thread,
struct perf_sample *data, int max_stack)
{
- u64 ip;
struct unwind_info ui = {
.sample = data,
.thread = thread,
.machine = thread->mg->machine,
};
- int ret;
if (!data->user_regs.regs)
return -EINVAL;
- ret = perf_reg_value(&ip, &data->user_regs, PERF_REG_IP);
- if (ret)
- return ret;
-
- ret = entry(ip, thread, cb, arg);
- if (ret)
- return -ENOMEM;
+ if (max_stack <= 0)
+ return -EINVAL;
- return --max_stack > 0 ? get_entries(&ui, cb, arg, max_stack) : 0;
+ return get_entries(&ui, cb, arg, max_stack);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf test: Add callchain order setup for DWARF unwinder test
Commit-ID: 8dc0564d809e3903834950e2d12f6d1d2fcff708
Gitweb: http://git.kernel.org/tip/8dc0564d809e3903834950e2d12f6d1d2fcff708
Author: Jiri Olsa
AuthorDate: Tue, 17 Nov 2015 16:05:39 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 23 Nov 2015 18:31:01 -0300
perf test: Add callchain order setup for DWARF unwinder test
Adding callchain order setup for DWARF unwinder test. The test now runs
unwinder for both callee and caller orders.
Signed-off-by: Jiri Olsa
Tested-by: Milian Wolff
Cc: David Ahern
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: Wang Nan
Link:
http://lkml.kernel.org/r/1447772739-18471-4-git-send-email-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/tests/dwarf-unwind.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/tools/perf/tests/dwarf-unwind.c b/tools/perf/tests/dwarf-unwind.c
index 01f0b61..b2357e8 100644
--- a/tools/perf/tests/dwarf-unwind.c
+++ b/tools/perf/tests/dwarf-unwind.c
@@ -51,6 +51,12 @@ static int unwind_entry(struct unwind_entry *entry, void
*arg)
"krava_1",
"test__dwarf_unwind"
};
+ /*
+* The funcs[MAX_STACK] array index, based on the
+* callchain order setup.
+*/
+ int idx = callchain_param.order == ORDER_CALLER ?
+ MAX_STACK - *cnt - 1 : *cnt;
if (*cnt >= MAX_STACK) {
pr_debug("failed: crossed the max stack value %d\n", MAX_STACK);
@@ -63,8 +69,10 @@ static int unwind_entry(struct unwind_entry *entry, void
*arg)
return -1;
}
- pr_debug("got: %s 0x%" PRIx64 "\n", symbol, entry->ip);
- return strcmp((const char *) symbol, funcs[(*cnt)++]);
+ (*cnt)++;
+ pr_debug("got: %s 0x%" PRIx64 ", expecting %s\n",
+symbol, entry->ip, funcs[idx]);
+ return strcmp((const char *) symbol, funcs[idx]);
}
__attribute__ ((noinline))
@@ -105,8 +113,16 @@ static int compare(void *p1, void *p2)
/* Any possible value should be 'thread' */
struct thread *thread = *(struct thread **)p1;
- if (global_unwind_retval == -INT_MAX)
+ if (global_unwind_retval == -INT_MAX) {
+ /* Call unwinder twice for both callchain orders. */
+ callchain_param.order = ORDER_CALLER;
+
global_unwind_retval = unwind_thread(thread);
+ if (!global_unwind_retval) {
+ callchain_param.order = ORDER_CALLEE;
+ global_unwind_retval = unwind_thread(thread);
+ }
+ }
return p1 - p2;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf config: Add initial man page
Commit-ID: 7d6852432acb3b09fc3ec45dd65421d34eebe3b5 Gitweb: http://git.kernel.org/tip/7d6852432acb3b09fc3ec45dd65421d34eebe3b5 Author: Taeung Song AuthorDate: Sun, 22 Nov 2015 19:11:56 +0900 Committer: Arnaldo Carvalho de Melo CommitDate: Mon, 23 Nov 2015 18:31:25 -0300 perf config: Add initial man page Add perf-config document to describe the perf configuration and a 'list’ subcommand. Signed-off-by: Taeung Song Cc: Jiri Olsa Cc: Namhyung Kim Link: http://lkml.kernel.org/r/63ad9b57-7b8c-46f8-8f18-0ffeb9a6a...@gmail.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/perf/Documentation/perf-config.txt | 103 +++ 1 file changed, 103 insertions(+) diff --git a/tools/perf/Documentation/perf-config.txt b/tools/perf/Documentation/perf-config.txt new file mode 100644 index 000..b9ca1e3 --- /dev/null +++ b/tools/perf/Documentation/perf-config.txt @@ -0,0 +1,103 @@ +perf-config(1) +== + +NAME + +perf-config - Get and set variables in a configuration file. + +SYNOPSIS + +[verse] +'perf config' -l | --list + +DESCRIPTION +--- +You can manage variables in a configuration file with this command. + +OPTIONS +--- + +-l:: +--list:: + Show current config variables, name and value, for all sections. + +CONFIGURATION FILE +-- + +The perf configuration file contains many variables to change various +aspects of each of its tools, including output, disk usage, etc. +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. + +Syntax +~~ + +The file consist of sections. A section starts with its name +surrounded by square brackets and continues till the next section +begins. Each variable must be in a section, and have the form +'name = value', for example: + + [section] + name1 = value1 + name2 = value2 + +Section names are case sensitive and can contain any characters except +newline (double quote `"` and backslash have to be escaped as `\"` and `\\`, +respectively). Section headers can't span multiple lines. + +Example +~~~ + +Given a $HOME/.perfconfig like this: + +# +# This is the config file, and +# a '#' and ';' character indicates a comment +# + + [colors] + # Color variables + top = red, default + medium = green, default + normal = lightgray, default + selected = white, lightgray + code = blue, default + addr = magenta, default + root = white, blue + + [tui] + # Defaults if linked with libslang + report = on + annotate = on + top = on + + [buildid] + # Default, disable using /dev/null + dir = ~/.debug + + [annotate] + # Defaults + hide_src_code = false + use_offset = true + jump_arrows = true + show_nr_jumps = false + + [help] + # Format can be man, info, web or html + format = man + autocorrect = 0 + + [ui] + show-headers = true + + [call-graph] + # fp (framepointer), dwarf + record-mode = fp + print-type = graph + order = caller + sort-key = function + +SEE ALSO + +linkperf:perf[1] -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf tools: Add 'perf config' command
Commit-ID: 30862f2c5725c46afcfab5af710fdf5163bf0f81
Gitweb: http://git.kernel.org/tip/30862f2c5725c46afcfab5af710fdf5163bf0f81
Author: Taeung Song
AuthorDate: Tue, 17 Nov 2015 22:53:21 +0900
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 23 Nov 2015 18:31:24 -0300
perf tools: Add 'perf config' command
The perf configuration file contains many variables to change various
aspects of each of its tools, including output, disk usage, etc.
But looking at the state of configuration is difficult and there's no
documentation about config variables except for the variables in
perfconfig.example exist.
So this patch adds a 'perf-config' command with a '--list' option.
perf config [options]
display current perf config variables.
# perf config -l | --list
Signed-off-by: Taeung Song
Acked-by: Namhyung Kim
Cc: Jiri Olsa
Link:
http://lkml.kernel.org/r/1447768424-17327-1-git-send-email-treeze.tae...@gmail.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/Build| 1 +
tools/perf/builtin-config.c | 66 +
tools/perf/builtin.h| 1 +
tools/perf/command-list.txt | 1 +
tools/perf/perf.c | 1 +
5 files changed, 70 insertions(+)
diff --git a/tools/perf/Build b/tools/perf/Build
index 7223745..2c7aaf2 100644
--- a/tools/perf/Build
+++ b/tools/perf/Build
@@ -1,5 +1,6 @@
perf-y += builtin-bench.o
perf-y += builtin-annotate.o
+perf-y += builtin-config.o
perf-y += builtin-diff.o
perf-y += builtin-evlist.o
perf-y += builtin-help.o
diff --git a/tools/perf/builtin-config.c b/tools/perf/builtin-config.c
new file mode 100644
index 000..427ea7a
--- /dev/null
+++ b/tools/perf/builtin-config.c
@@ -0,0 +1,66 @@
+/*
+ * builtin-config.c
+ *
+ * Copyright (C) 2015, Taeung Song
+ *
+ */
+#include "builtin.h"
+
+#include "perf.h"
+
+#include "util/cache.h"
+#include "util/parse-options.h"
+#include "util/util.h"
+#include "util/debug.h"
+
+static const char * const config_usage[] = {
+ "perf config [options]",
+ NULL
+};
+
+enum actions {
+ ACTION_LIST = 1
+} actions;
+
+static struct option config_options[] = {
+ OPT_SET_UINT('l', "list", &actions,
+"show current config variables", ACTION_LIST),
+ OPT_END()
+};
+
+static int show_config(const char *key, const char *value,
+ void *cb __maybe_unused)
+{
+ if (value)
+ printf("%s=%s\n", key, value);
+ else
+ printf("%s\n", key);
+
+ return 0;
+}
+
+int cmd_config(int argc, const char **argv, const char *prefix __maybe_unused)
+{
+ int ret = 0;
+
+ argc = parse_options(argc, argv, config_options, config_usage,
+PARSE_OPT_STOP_AT_NON_OPTION);
+
+ switch (actions) {
+ case ACTION_LIST:
+ if (argc) {
+ pr_err("Error: takes no arguments\n");
+ parse_options_usage(config_usage, config_options, "l",
1);
+ } else {
+ ret = perf_config(show_config, NULL);
+ if (ret < 0)
+ pr_err("Nothing configured, "
+ "please check your ~/.perfconfig
file\n");
+ }
+ break;
+ default:
+ usage_with_options(config_usage, config_options);
+ }
+
+ return ret;
+}
diff --git a/tools/perf/builtin.h b/tools/perf/builtin.h
index 3688ad2..3f871b5 100644
--- a/tools/perf/builtin.h
+++ b/tools/perf/builtin.h
@@ -17,6 +17,7 @@ extern int cmd_annotate(int argc, const char **argv, const
char *prefix);
extern int cmd_bench(int argc, const char **argv, const char *prefix);
extern int cmd_buildid_cache(int argc, const char **argv, const char *prefix);
extern int cmd_buildid_list(int argc, const char **argv, const char *prefix);
+extern int cmd_config(int argc, const char **argv, const char *prefix);
extern int cmd_diff(int argc, const char **argv, const char *prefix);
extern int cmd_evlist(int argc, const char **argv, const char *prefix);
extern int cmd_help(int argc, const char **argv, const char *prefix);
diff --git a/tools/perf/command-list.txt b/tools/perf/command-list.txt
index 00fcaf8..acc3ea7 100644
--- a/tools/perf/command-list.txt
+++ b/tools/perf/command-list.txt
@@ -9,6 +9,7 @@ perf-buildid-cache mainporcelain common
perf-buildid-list mainporcelain common
perf-data mainporcelain common
perf-diff mainporcelain common
+perf-configmainporcelain common
perf-evlistmainporcelain common
perf-injectmainporcelain common
perf-kmem mainporcelain common
diff --git a/tools/perf/perf.c b/tools/perf/perf.c
index 3d4c7c0..4bee53c 100644
--- a/tools/perf/perf.c
+++ b/tools/perf/perf.c
@@ -39,6 +39,7 @@ struct cmd_struct {
static struct cmd_struct
[tip:perf/core] perf callchain: Add order support for libdw DWARF unwinder
Commit-ID: 8bd508b001629a5d836987d9a0702a6bfc4fc705
Gitweb: http://git.kernel.org/tip/8bd508b001629a5d836987d9a0702a6bfc4fc705
Author: Jiri Olsa
AuthorDate: Thu, 19 Nov 2015 14:01:19 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 23 Nov 2015 18:31:13 -0300
perf callchain: Add order support for libdw DWARF unwinder
As reported by Milian, currently for DWARF unwind (both libdw and
libunwind) we display callchain in callee order only.
Adding the support to follow callchain order setup to libdw DWARF
unwinder, so we could get following output for report:
$ perf record --call-graph dwarf ls
...
$ perf report --no-children --stdio
21.12% ls libc-2.21.so [.] __strcoll_l
|
---__strcoll_l
mpsort_with_tmp
mpsort_with_tmp
mpsort_with_tmp
sort_files
main
__libc_start_main
_start
$ perf report --stdio --no-children -g caller
21.12% ls libc-2.21.so [.] __strcoll_l
|
---_start
__libc_start_main
main
sort_files
mpsort_with_tmp
mpsort_with_tmp
mpsort_with_tmp
__strcoll_l
Reported-and-Tested-by: Milian Wolff
Signed-off-by: Jiri Olsa
Tested-by: Wang Nan
Cc: David Ahern
Cc: Jan Kratochvil
Cc: Jiri Olsa
Cc: Namhyung Kim
Cc: Peter Zijlstra
Link: http://lkml.kernel.org/r/20151119130119.ga26...@krava.brq.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/unwind-libdw.c | 53 ++
tools/perf/util/unwind-libdw.h | 2 ++
2 files changed, 40 insertions(+), 15 deletions(-)
diff --git a/tools/perf/util/unwind-libdw.c b/tools/perf/util/unwind-libdw.c
index 2dcfe9a..db8142b 100644
--- a/tools/perf/util/unwind-libdw.c
+++ b/tools/perf/util/unwind-libdw.c
@@ -11,6 +11,7 @@
#include
#include "event.h"
#include "perf_regs.h"
+#include "callchain.h"
static char *debuginfo_path;
@@ -52,25 +53,28 @@ static int report_module(u64 ip, struct unwind_info *ui)
return __report_module(&al, ip, ui);
}
+/*
+ * Store all entries within entries array,
+ * we will process it after we finish unwind.
+ */
static int entry(u64 ip, struct unwind_info *ui)
{
- struct unwind_entry e;
+ struct unwind_entry *e = &ui->entries[ui->idx++];
struct addr_location al;
if (__report_module(&al, ip, ui))
return -1;
- e.ip = ip;
- e.map = al.map;
- e.sym = al.sym;
+ e->ip = ip;
+ e->map = al.map;
+ e->sym = al.sym;
pr_debug("unwind: %s:ip = 0x%" PRIx64 " (0x%" PRIx64 ")\n",
al.sym ? al.sym->name : "''",
ip,
al.map ? al.map->map_ip(al.map, ip) : (u64) 0);
-
- return ui->cb(&e, ui->arg);
+ return 0;
}
static pid_t next_thread(Dwfl *dwfl, void *arg, void **thread_argp)
@@ -168,7 +172,7 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
struct perf_sample *data,
int max_stack)
{
- struct unwind_info ui = {
+ struct unwind_info *ui, ui_buf = {
.sample = data,
.thread = thread,
.machine= thread->mg->machine,
@@ -177,35 +181,54 @@ int unwind__get_entries(unwind_entry_cb_t cb, void *arg,
.max_stack = max_stack,
};
Dwarf_Word ip;
- int err = -EINVAL;
+ int err = -EINVAL, i;
if (!data->user_regs.regs)
return -EINVAL;
- ui.dwfl = dwfl_begin(&offline_callbacks);
- if (!ui.dwfl)
+ ui = zalloc(sizeof(ui_buf) + sizeof(ui_buf.entries[0]) * max_stack);
+ if (!ui)
+ return -ENOMEM;
+
+ *ui = ui_buf;
+
+ ui->dwfl = dwfl_begin(&offline_callbacks);
+ if (!ui->dwfl)
goto out;
err = perf_reg_value(&ip, &data->user_regs, PERF_REG_IP);
if (err)
goto out;
- err = report_module(ip, &ui);
+ err = report_module(ip, ui);
if (err)
goto out;
- if (!dwfl_attach_state(ui.dwfl, EM_NONE, thread->tid, &callbacks, &ui))
+ if (!dwfl_attach_state(ui->dwfl, EM_NONE, thread->tid, &callbacks, ui))
goto out;
- err = dwfl_getthread_frames(ui.dwfl, thread->tid, frame_callback, &ui);
+ err = dwfl_getthread_frames(ui->dwfl, thread->tid, frame_callback, ui);
- if (err && !ui.max_stack)
+ if (err && !ui->max_stack)
err = 0;
+ /*
+* Display what we got based on the order setup.
+*/
+ for (i = 0; i < ui->idx && !err; i++) {
+ int j = i;
+
+ if (callchain_param.order == ORDER_
Re: [PATCH V3 net-next 3/5] net:hns: Add Hip06 "TSO(TCP Segment Offload)" support HNS Driver
On 11/22/2015 8:49 AM, Yuval Mintz wrote:
+static void hns_ae_set_tso_stats(struct hnae_handle *handle, int
+enable) {
+ struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
+
+ hns_ppe_set_tso_enable(ppe_cb, enable); }
Style issues?
I could not see the code style issue menioned above in earlier submitted
patch. Looks like I am misssing something here!
+static void hns_ae_set_tso_stats(struct hnae_handle *handle, int enable)
+{
+ struct hns_ppe_cb *ppe_cb = hns_get_ppe_cb(handle);
+
+ hns_ppe_set_tso_enable(ppe_cb, enable);
+}
+
+void hns_ppe_set_tso_enable(struct hns_ppe_cb *ppe_cb, u32 value) {
+ dsaf_set_dev_bit(ppe_cb, PPEV2_CFG_TSO_EN_REG, 0, !!value); }
+
Likewise
Same in above case. Hope I am not missing anything.
#include "hns_dsaf_ppe.h"
+void hns_ppe_set_tso_enable(struct hns_ppe_cb *ppe_cb, u32 value)
+{
+ dsaf_set_dev_bit(ppe_cb, PPEV2_CFG_TSO_EN_REG, 0, !!value);
+}
+
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] perf callchain: Add missing parent_val initialization
Commit-ID: 646a6e846c4dc3812c614fd061603b6db5b8d380
Gitweb: http://git.kernel.org/tip/646a6e846c4dc3812c614fd061603b6db5b8d380
Author: Jiri Olsa
AuthorDate: Sat, 21 Nov 2015 11:23:55 +0100
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 23 Nov 2015 18:31:25 -0300
perf callchain: Add missing parent_val initialization
Adding missing parent_val callchain_node initialization.
It's causing segfault in perf top:
$ sudo perf top -g
perf: Segmentation fault
backtrace
free_callchain_node(+0x29) in perf [0x4a4b3e]
free_callchain(+0x29) in perf [0x4a5a83]
hist_entry__delete(+0x126) in perf [0x4c6649]
hists__delete_entry(+0x6e) in perf [0x4c66dc]
hists__decay_entries(+0x7d) in perf [0x4c6776]
perf_top__sort_new_samples(+0x7c) in perf [0x436a78]
hist_browser__run(+0xf2) in perf [0x507760]
perf_evsel__hists_browse(+0x1da) in perf [0x507c8d]
perf_evlist__tui_browse_hists(+0x3e) in perf [0x5088cf]
display_thread_tui(+0x7f) in perf [0x437953]
start_thread(+0xc5) in libpthread-2.21.so [0x7f7068fbb555]
__clone(+0x6d) in libc-2.21.so [0x7f7066fc3b9d]
[0x0]
Reported-and-Tested-by: Arnaldo Carvalho de Melo
Signed-off-by: Jiri Olsa
Acked-by: Namhyung Kim
Cc: Masami Hiramatsu
Cc: Wang Nan
Fixes: 4b3a3212233a ("perf hists browser: Support flat callchains")
Link: http://lkml.kernel.org/r/20151121102355.GA17313@krava.local
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/perf/util/callchain.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/perf/util/callchain.h b/tools/perf/util/callchain.h
index 6e9b5f2..8ac8f043 100644
--- a/tools/perf/util/callchain.h
+++ b/tools/perf/util/callchain.h
@@ -143,6 +143,7 @@ extern __thread struct callchain_cursor callchain_cursor;
static inline void callchain_init(struct callchain_root *root)
{
INIT_LIST_HEAD(&root->node.val);
+ INIT_LIST_HEAD(&root->node.parent_val);
root->node.parent = NULL;
root->node.hit = 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib traceevent: Fix output of %llu for 64 bit values read on 32 bit machines
Commit-ID: 32abc2ede536aae52978d6c0a8944eb1df14f460
Gitweb: http://git.kernel.org/tip/32abc2ede536aae52978d6c0a8944eb1df14f460
Author: Steven Rostedt
AuthorDate: Mon, 16 Nov 2015 17:25:16 -0500
Committer: Arnaldo Carvalho de Melo
CommitDate: Mon, 23 Nov 2015 19:17:23 -0300
tools lib traceevent: Fix output of %llu for 64 bit values read on 32 bit
machines
When a long value is read on 32 bit machines for 64 bit output, the
parsing needs to change "%lu" into "%llu", as the value is read
natively.
Unfortunately, if "%llu" is already there, the code will add another "l"
to it and fail to parse it properly.
Signed-off-by: Steven Rostedt
Acked-by: Namhyung Kim
Cc: sta...@vger.kernel.org
Link: http://lkml.kernel.org/r/20151116172516.4b79b...@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo
---
tools/lib/traceevent/event-parse.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/tools/lib/traceevent/event-parse.c
b/tools/lib/traceevent/event-parse.c
index 2a912df..68276f3 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -4968,13 +4968,12 @@ static void pretty_print(struct trace_seq *s, void
*data, int size, struct event
sizeof(long) != 8) {
char *p;
- ls = 2;
/* make %l into %ll */
- p = strchr(format, 'l');
- if (p)
+ if (ls == 1 && (p = strchr(format,
'l')))
memmove(p+1, p, strlen(p)+1);
else if (strcmp(format, "%p") == 0)
strcpy(format, "0x%llx");
+ ls = 2;
}
switch (ls) {
case -2:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools lib bpf: Don' t do a feature check when cleaning
Commit-ID: d8ad6a15cc3a364de6c8010378adc3fb06ce3ff1 Gitweb: http://git.kernel.org/tip/d8ad6a15cc3a364de6c8010378adc3fb06ce3ff1 Author: Wang Nan AuthorDate: Tue, 24 Nov 2015 13:36:07 + Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 25 Nov 2015 16:38:13 -0300 tools lib bpf: Don't do a feature check when cleaning Before this patch libbpf always do feature check even when cleaning. For example: $ cd kernel/tools/lib/bpf $ make Auto-detecting system features: ...libelf: [ on ] ... bpf: [ on ] CC libbpf.o CC bpf.o LD libbpf-in.o LINK libbpf.a LINK libbpf.so $ make clean CLEANlibbpf CLEANcore-gen $ make clean Auto-detecting system features: ...libelf: [ on ] ... bpf: [ on ] CLEANlibbpf CLEANcore-gen $ Although the first 'make clean' doesn't show feature check result, it still does the check. No output because check result is similar to FEATURE-DUMP.libbpf. This patch uses same method as perf to turn off feature checking when 'make clean'. Reported-and-Tested-by: Arnaldo Carvalho de Melo Signed-off-by: Wang Nan Cc: Alexei Starovoitov Cc: Jiri Olsa Cc: Masami Hiramatsu Cc: Zefan Li Cc: pi3or...@163.com Link: http://lkml.kernel.org/r/1448372181-151723-3-git-send-email-wangn...@huawei.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/lib/bpf/Makefile | 10 ++ 1 file changed, 10 insertions(+) diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile index a3caaf3..636e3dd 100644 --- a/tools/lib/bpf/Makefile +++ b/tools/lib/bpf/Makefile @@ -71,7 +71,17 @@ FEATURE_DISPLAY = libelf bpf INCLUDES = -I. -I$(srctree)/tools/include -I$(srctree)/arch/$(ARCH)/include/uapi -I$(srctree)/include/uapi FEATURE_CHECK_CFLAGS-bpf = $(INCLUDES) +check_feat := 1 +NON_CHECK_FEAT_TARGETS := clean TAGS tags cscope help +ifdef MAKECMDGOALS +ifeq ($(filter-out $(NON_CHECK_FEAT_TARGETS),$(MAKECMDGOALS)),) + check_feat := 0 +endif +endif + +ifeq ($(check_feat),1) include $(srctree)/tools/build/Makefile.feature +endif export prefix libdir src obj -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:perf/core] tools build: Clean CFLAGS and LDFLAGS for fixdep
Commit-ID: 5725dd8fa888b4dcdff58241f9d3d3ac42a048e2 Gitweb: http://git.kernel.org/tip/5725dd8fa888b4dcdff58241f9d3d3ac42a048e2 Author: Wang Nan AuthorDate: Tue, 24 Nov 2015 13:36:06 + Committer: Arnaldo Carvalho de Melo CommitDate: Wed, 25 Nov 2015 16:36:36 -0300 tools build: Clean CFLAGS and LDFLAGS for fixdep Sometimes passing variables to tools/build is dangerous. For example, on my platform there is a gcc problem (gcc 4.8.1): It passes the stackprotector-all feature check: $ gcc -fstack-protector-all -c ./test.c $ echo $? 0 But requires LDFLAGS support if separate compiling and linking: $ gcc -fstack-protector-all -c ./test.c $ gcc ./test.o ./test.o: In function `main': test.c:(.text+0xb): undefined reference to `__stack_chk_guard' test.c:(.text+0x21): undefined reference to `__stack_chk_guard' collect2: error: ld returned 1 exit status $ gcc -fstack-protector-all ./test.o $ echo $? 0 $ gcc ./test.o -lssp $ echo $? 0 $ In this environment building perf throws an error: $ make BUILD: Doing 'make -j24' parallel build config/Makefile:344: No libunwind found. Please install libunwind-dev[el] >= 1.1 and/or set LIBUNWIND_DIR config/Makefile:403: No libaudit.h found, disables 'trace' tool, please install audit-libs-devel or libaudit-dev config/Makefile:418: slang not found, disables TUI support. Please install slang-devel or libslang-dev config/Makefile:432: GTK2 not found, disables GTK2 support. Please install gtk2-devel or libgtk2.0-dev config/Makefile:564: No bfd.h/libbfd found, please install binutils-dev[el]/zlib-static/libiberty-dev to gain symbol demangling config/Makefile:606: No numa.h found, disables 'perf bench numa mem' benchmark, please install numactl-devel/libnuma-devel/libnuma-dev CC fixdep.o LD fixdep-in.o LINK fixdep fixdep-in.o: In function `parse_dep_file': /kernel/tools/build/fixdep.c:47: undefined reference to `__stack_chk_guard' /kernel/tools/build/fixdep.c:117: undefined reference to `__stack_chk_guard' fixdep-in.o: In function `main': /kernel-hydrogen/tools/build/fixdep.c:156: undefined reference to `__stack_chk_guard' /kernel/tools/build/fixdep.c:168: undefined reference to `__stack_chk_guard' collect2: error: ld returned 1 exit status make[2]: *** [fixdep] Error 1 make[1]: *** [fixdep] Error 2 make: *** [all] Error 2 This is because the CFLAGS used in building perf pollutes the CFLAGS used for fixdep, passing -fstack-protector-all to buiold fixdep which is obviously not required. Since fixdep is a small host side tool, we should keep its CFLAGS/LDFLAGS simple and clean. This patch clears the CFLAGS and LDFLAGS passed when building fixdep, so such gcc problem won't block the perf build process. Signed-off-by: Wang Nan Acked-by: Jiri Olsa Cc: Alexei Starovoitov Cc: Masami Hiramatsu Cc: Zefan Li Cc: pi3or...@163.com Link: http://lkml.kernel.org/r/1448372181-151723-2-git-send-email-wangn...@huawei.com Signed-off-by: Arnaldo Carvalho de Melo --- tools/build/Makefile.include | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include index 4e09ad6..6254760 100644 --- a/tools/build/Makefile.include +++ b/tools/build/Makefile.include @@ -4,7 +4,7 @@ ifdef CROSS_COMPILE fixdep: else fixdep: - $(Q)$(MAKE) -C $(srctree)/tools/build fixdep + $(Q)$(MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= fixdep endif .PHONY: fixdep -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ASoC: hdac_hdmi: convert num_nodes to int
On Thu, 26 Nov 2015 09:08:19 +0100,
Sudip Mukherjee wrote:
>
> All uses of num_nodes are considering it as a signed integer and that is
> very much clear when we try to save the error value in it and later try
> to compare it with less than 0.
No. The point is that the value checked *there* has to be int, not
the value used for the success case. Just have a temporary value,
e.g. int num_nodes, assign there, check it, then assign the value to
codec->num_nodes field. The num_nodes field itself is obviously an
unsigned.
Takashi
>
> Signed-off-by: Sudip Mukherjee
> ---
> include/sound/hdaudio.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/sound/hdaudio.h b/include/sound/hdaudio.h
> index e2b712c..c5fad14 100644
> --- a/include/sound/hdaudio.h
> +++ b/include/sound/hdaudio.h
> @@ -71,7 +71,7 @@ struct hdac_device {
>unsigned int flags, unsigned int *res);
>
> /* widgets */
> - unsigned int num_nodes;
> + int num_nodes;
> hda_nid_t start_nid, end_nid;
>
> /* misc flags */
> --
> 1.9.1
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink+0x4b/0x50()
Vegard Nossum writes: > On 11/25/2015 10:54 PM, OGAWA Hirofumi wrote: >> Vegard Nossum writes: >> >>> On 11/23/2015 11:21 PM, Richard Weinberger wrote: Am 23.11.2015 um 08:55 schrieb Vegard Nossum: > With the attached vfat disk image (fuzzed), I get the following WARNING: > > WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink+0x4b/0x50() > > [...] > >> >> Can you try this one? >> > > That seems to fix the problem here, thanks! > > The last potential issue I'm seeing (completely unrelated to your patch) > is this: > > [ 340.61] VFS: Lookup of '1' in vfat loop0 would have caused loop > [ 354.36] d_splice_alias: 1104 callbacks suppressed > [ 354.36] VFS: Lookup of '1' in vfat loop0 would have caused loop > > Is that worth investigating closer? It looks like corruption detected with ratelimited printk (at vfs level. dir is hardlink of ancestor). IOW, it looks like intended behavior. Thanks. -- OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] Save SMBIOS Type 9 System Slots during DMI Scan
On Thu, 26 Nov 2015 02:02:52 -0600, Jordan Hargrave wrote:
> On Wed, Nov 25, 2015 at 5:47 AM, Jean Delvare wrote:
> > On Wed, 18 Nov 2015 16:02:14 -0600, Jordan Hargrave wrote:
> > > +static void __init dmi_save_system_slot(const struct dmi_header *dm)
> > > +{
> > > + const char *name;
> > > + const u8 *d = (u8*)dm;
> > > +
> > > + if (dm->type == DMI_ENTRY_SYSTEM_SLOT && dm->length >= 0x11) {
> >
> > The first half of the test will always succeed so it can be omitted.
> > OTOH you do not check the value of d + 0x07 (current usage.) As I
> > understand it, you should only consider slots which are in use, so
> > where *(d + 0x07) == 0x04?
>
> Unfortunately BIOS often get 'usage' wrong. And I'd like to keep all slots
> recorded if user hotplugs PCIe card.
OK, then please add a comment saying so.
I'm curious how the BIOS can assign a device number and function when
there is no card in the slot. I'm also curious how multi-function
cards are handled. I suppose that only the first function has a DMI
record?
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink+0x4b/0x50()
Vegard Nossum writes:
> On 11/25/2015 10:54 PM, OGAWA Hirofumi wrote:
>> Vegard Nossum writes:
>>
>>> On 11/23/2015 11:21 PM, Richard Weinberger wrote:
Am 23.11.2015 um 08:55 schrieb Vegard Nossum:
> With the attached vfat disk image (fuzzed), I get the following WARNING:
>
> WARNING: CPU: 0 PID: 913 at fs/inode.c:275 drop_nlink+0x4b/0x50()
>
> [...]
>
>>
>> Can you try this one?
>>
>
> That seems to fix the problem here, thanks!
Andrew, please queue this up for next chance.
Thanks.
--
OGAWA Hirofumi
[PATCH] fat: Add simple validation for directory inode
This detects simple corruption cases of directory, and try to avoid
further damage to user data.
And performance impact of this validation should be very low, or not
measurable.
Reported-by: Vegard Nossum
Tested-by: Vegard Nossum
Signed-off-by: OGAWA Hirofumi
---
fs/fat/inode.c | 22 ++
1 file changed, 22 insertions(+)
diff -puN fs/fat/inode.c~fat-validate-dir fs/fat/inode.c
--- linux/fs/fat/inode.c~fat-validate-dir 2015-11-26 06:31:39.666959958
+0900
+++ linux-hirofumi/fs/fat/inode.c 2015-11-26 06:31:39.670959945 +0900
@@ -449,6 +449,24 @@ static int fat_calc_dir_size(struct inod
return 0;
}
+static int fat_validate_dir(struct inode *dir)
+{
+ struct super_block *sb = dir->i_sb;
+
+ if (dir->i_nlink < 2) {
+ /* Directory should have "."/".." entries at least. */
+ fat_fs_error(sb, "corrupted directory (invalid entries)");
+ return -EIO;
+ }
+ if (MSDOS_I(dir)->i_start == 0 ||
+ MSDOS_I(dir)->i_start == MSDOS_SB(sb)->root_cluster) {
+ /* Directory should point valid cluster. */
+ fat_fs_error(sb, "corrupted directory (invalid i_start)");
+ return -EIO;
+ }
+ return 0;
+}
+
/* doesn't deal with root inode */
int fat_fill_inode(struct inode *inode, struct msdos_dir_entry *de)
{
@@ -475,6 +493,10 @@ int fat_fill_inode(struct inode *inode,
MSDOS_I(inode)->mmu_private = inode->i_size;
set_nlink(inode, fat_subdirs(inode));
+
+ error = fat_validate_dir(inode);
+ if (error < 0)
+ return error;
} else { /* not a directory */
inode->i_generation |= 1;
inode->i_mode = fat_make_mode(sbi, de->attr,
_
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ARM: dts: dra72-evm: Mark uart1 rxd as wakeup capable
Uart1 rxd is wakeup capable on DRA72 EVM. Hence, mark rxd line as
wakeup capable. This is similar to commit 66b0436977e2c ("ARM: dts:
dra7-evm: Mark uart1 rxd as wakeup capable") for DRA74 EVM.
Signed-off-by: Vignesh R
---
arch/arm/boot/dts/dra72-evm.dts | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm/boot/dts/dra72-evm.dts b/arch/arm/boot/dts/dra72-evm.dts
index d6104d5f0c01..8bf36b0b3c33 100644
--- a/arch/arm/boot/dts/dra72-evm.dts
+++ b/arch/arm/boot/dts/dra72-evm.dts
@@ -478,6 +478,8 @@
&uart1 {
status = "okay";
+ interrupts-extended = <&crossbar_mpu GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>,
+ <&dra7_pmx_core 0x3e0>;
};
&elm {
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [Resend: PATCH v2 0/3] Fix rcar-pcie for arm64
HI Bjorn,
On 25 November 2015 16:41, Bjorn Helgaas wrote:
> Hi Phil,
>
> On Wed, Nov 25, 2015 at 03:30:36PM +, Phil Edworthy wrote:
> > The first patches fixes the build problem
>
> I'm trying to figure out if v4.4 has a build problem we need to fix.
> If I understand correctly, "PCI: rcar: Convert to DT resource parsing
> API" doesn't fix a build problem in the current tree; rather, it
> removes a dependency on ARM so that we can build it on ARM64.
v4.4 doesn't have a build problem because commit 7c537c67d2e4 ensures
it doesn't get built on arm64. If we revert this commit, then there is a
build failure as the pci_ioremap_io() function is not available on arm64.
That's the build failure which "PCI: rcar: Convert to DT resource parsing API"
fixes.
> > , and the second patch reverts the
> > patch that removed the driver from arm64 builds. The final patch add a
> > compat
> > string for the r8a7795 (arm64) device.
> >
> > Tested on arm Koelsch board, all ok.
> >
> > Tested on arm64 Salvator-X board using renesas-drivers-2015-10-27-v4.3-rc7
> from
> > git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git with
> PCI
> > next merged.
> > Apart from patches to add the PCIe clock and DT nodes, it also needs this
> > fix:
> > ("PCI: MSI: Only use the generic MSI layer when domain is hierarchical")
>
> I assume you mean this one from Marc: https://lkml.org/lkml/2015/11/23/388
> (Was that posted to linux-pci? I don't see it in patchwork or my
> linux-pci archives, so I hadn't seen it yet.)
Ok, yes that's the patch.
> How exactly is that related to this series? If I merge these before
> Marc's change, do we have a tree that builds for arm64 but doesn't
> work?
Correct.
> What about the PCIe clock and DT changes you mention? Is there a
> reason to keep them separate? Would it be feasible to include the DT
> changes in the same patch as the driver change that uses those
> changes?
The approach for all other drivers has been to keep these separate. There
are no changes to the dt bindings, it's just adding the node to the new
device and board, so there is no problem with ordering of these patches.
Thanks
Phil
> Bjorn
>
> > Resent with whole series marked as v2 and acks, etc added.
> >
> > Harunobu Kurokawa (1):
> > PCI: pcie-rcar: Add support for R-Car H3.
> >
> > Phil Edworthy (2):
> > PCI: rcar: Convert to DT resource parsing API
> > Revert "PCI: rcar: Build pcie-rcar.c only on ARM"
> >
> > Documentation/devicetree/bindings/pci/rcar-pci.txt | 3 +-
> > drivers/pci/host/Kconfig | 3 +-
> > drivers/pci/host/pcie-rcar.c | 117
> > +
> > 3 files changed, 77 insertions(+), 46 deletions(-)
> >
> > --
> > 2.5.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/1] platform: goldfish: pipe: add devicetree bindings
On Wed, Nov 25, 2015 at 02:24:16PM -0600, Rob Herring wrote: > On Wed, Nov 25, 2015 at 11:59:37AM -0800, Jin Qian wrote: > > From: Greg Hackmann > > > > Signed-off-by: Greg Hackmann > > (cherry picked from commit 3c56d07eb796066530e93a40e74dea3bc59bf4cf) > > Signed-off-by: Jin Qian > > --- > > Documentation/devicetree/bindings/goldfish/pipe.txt | 17 + > > drivers/platform/goldfish/goldfish_pipe.c | 10 +- > > 2 files changed, 26 insertions(+), 1 deletion(-) > > create mode 100644 Documentation/devicetree/bindings/goldfish/pipe.txt > > > > diff --git a/Documentation/devicetree/bindings/goldfish/pipe.txt > > b/Documentation/devicetree/bindings/goldfish/pipe.txt > > new file mode 100644 > > index 000..6d3801e > > --- /dev/null > > +++ b/Documentation/devicetree/bindings/goldfish/pipe.txt > > @@ -0,0 +1,17 @@ > > +Android Goldfish QEMU Pipe > > + > > +Andorid pipe virtual device generated by android emulator. > > The binding may be trivial, but there's a bigger question of whether > this is the right long term direction. For example is upstream QEMU > going to take all the Android pipe stuff? Couldn't virtio be used here > as the transport? > The Android Pipe is not a very likely candidate for upstream QEMU, no. We are working on a TCG implementation of virtio-vsock (http://qemu-project.org/Features/VirtioVsock) which we think should be a suitable drop-in replacement for the Android pipe. We have yet to measure performance differences between the two, especially in the context of 3D graphics, though. But I wonder if that should really block this from being merged? The support may not be in QEMU but it's in the Android emulator and it would be a less broken implementation with these patches in the kernel than without, I think. -Christoffer -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] mm: hugetlb: call huge_pte_alloc() only if ptep is null
>
> Currently at the beginning of hugetlb_fault(), we call huge_pte_offset()
> and check whether the obtained *ptep is a migration/hwpoison entry or not.
> And if not, then we get to call huge_pte_alloc(). This is racy because the
> *ptep could turn into migration/hwpoison entry after the huge_pte_offset()
> check. This race results in BUG_ON in huge_pte_alloc().
>
> We don't have to call huge_pte_alloc() when the huge_pte_offset() returns
> non-NULL, so let's fix this bug with moving the code into else block.
>
> Note that the *ptep could turn into a migration/hwpoison entry after
> this block, but that's not a problem because we have another !pte_present
> check later (we never go into hugetlb_no_page() in that case.)
>
> Fixes: 290408d4a250 ("hugetlb: hugepage migration core")
> Signed-off-by: Naoya Horiguchi
> Cc: [2.6.36+]
> ---
Acked-by: Hillf Danton
> mm/hugetlb.c |8
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git next-20151123/mm/hugetlb.c next-20151123_patched/mm/hugetlb.c
> index 1101ccd..6ad5e91 100644
> --- next-20151123/mm/hugetlb.c
> +++ next-20151123_patched/mm/hugetlb.c
> @@ -3696,12 +3696,12 @@ int hugetlb_fault(struct mm_struct *mm, struct
> vm_area_struct *vma,
> } else if (unlikely(is_hugetlb_entry_hwpoisoned(entry)))
> return VM_FAULT_HWPOISON_LARGE |
> VM_FAULT_SET_HINDEX(hstate_index(h));
> + } else {
> + ptep = huge_pte_alloc(mm, address, huge_page_size(h));
> + if (!ptep)
> + return VM_FAULT_OOM;
> }
>
> - ptep = huge_pte_alloc(mm, address, huge_page_size(h));
> - if (!ptep)
> - return VM_FAULT_OOM;
> -
> mapping = vma->vm_file->f_mapping;
> idx = vma_hugecache_offset(h, vma, address);
>
> --
> 1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] perf top: Fix freeze on --call-graph flat/folded
On Thu, Nov 26, 2015 at 04:08:18PM +0900, Namhyung Kim wrote:
> The callchain rbtree is rebuilt periodically, so it needs to
> reinitialize the root everytime. Otherwise it can be stuck in the
> rbtree insertion with stale pointers.
>
> Signed-off-by: Namhyung Kim
> ---
> tools/perf/util/callchain.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index fc3b1e0d09ee..564377d2bebf 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -290,6 +290,7 @@ static void
> sort_chain_flat(struct rb_root *rb_root, struct callchain_root *root,
> u64 min_hit, struct callchain_param *param __maybe_unused)
> {
> + *rb_root = RB_ROOT;
it seems ok, but I did not find how this could be called twice?
the only sort I can see is done within:
__hists__insert_output_entry
do we allow resorting of the callchains?
thanks,
jirka
> __sort_chain_flat(rb_root, &root->node, min_hit);
> }
>
> --
> 2.6.2
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] pinctrl: mediatek: add pinctrl/GPIO/EINT driver for mt2701
MT2701 pinctrl/eint are similar to mt8127, mt8135 and mt8173, add support for mt2701 using mediatek common pinctrl driver. Biao Huang (4): dt-bindings: mediatek: Modify pinctrl bindings for mt2701 pinctrl: dt bindings: Add pinfunc header file for mt2701 pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701 arm: dts: Add pinctrl/GPIO/EINT node for mt2701 Erin Lo (1): ARM: mediatek: Add MT2701 config options for mediatek SoCs. .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |9 +- arch/arm/boot/dts/mt2701-pinfunc.h | 713 ++ arch/arm/boot/dts/mt2701.dtsi | 19 + arch/arm/mach-mediatek/Kconfig |4 + drivers/pinctrl/mediatek/Kconfig |6 + drivers/pinctrl/mediatek/Makefile |1 + drivers/pinctrl/mediatek/pinctrl-mt2701.c | 571 + drivers/pinctrl/mediatek/pinctrl-mtk-common.c |7 + drivers/pinctrl/mediatek/pinctrl-mtk-common.h |3 + drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h | 2323 10 files changed, 3652 insertions(+), 4 deletions(-) create mode 100644 arch/arm/boot/dts/mt2701-pinfunc.h create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2701.c create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] arm: dts: Add pinctrl/GPIO/EINT node for mt2701
Add pinctrl and GPIO node to mt2701.dtsi
Signed-off-by: Biao Huang
---
arch/arm/boot/dts/mt2701.dtsi | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index dc02f76..bd88ae9 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -17,6 +17,7 @@
#include
#include
#include "skeleton64.dtsi"
+#include "mt2701-pinfunc.h"
/ {
compatible = "mediatek,mt2701";
@@ -99,6 +100,24 @@
#reset-cells = <1>;
};
+ pio: pinctrl@10005000 {
+ compatible = "mediatek,mt2701-pinctrl";
+ reg = <0 0x1000b000 0 0x1000>;
+ mediatek,pctl-regmap = <&syscfg_pctl_a>;
+ pins-are-numbered;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupts = ,
+;
+ };
+
+ syscfg_pctl_a: syscfg@10005000 {
+ compatible = "mediatek,mt2701-pctl-a-syscfg", "syscon";
+ reg = <0 0x10005000 0 0x1000>;
+ };
+
watchdog: watchdog@10007000 {
compatible = "mediatek,mt2701-wdt",
"mediatek,mt6589-wdt";
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] pinctrl: mediatek: Add Pinctrl/GPIO/EINT driver for mt2701
Add mt2701 support using mediatek common pinctrl driver.
MT2701 have some special pins need an extra setting register
than other ICs, so adding this support to common code.
Signed-off-by: Biao Huang
---
drivers/pinctrl/mediatek/Kconfig |6 +
drivers/pinctrl/mediatek/Makefile |1 +
drivers/pinctrl/mediatek/pinctrl-mt2701.c | 571 ++
drivers/pinctrl/mediatek/pinctrl-mtk-common.c |7 +
drivers/pinctrl/mediatek/pinctrl-mtk-common.h |3 +
drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h | 2323 +
6 files changed, 2911 insertions(+)
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mt2701.c
create mode 100644 drivers/pinctrl/mediatek/pinctrl-mtk-mt2701.h
diff --git a/drivers/pinctrl/mediatek/Kconfig b/drivers/pinctrl/mediatek/Kconfig
index 02f6f92..13e9939 100644
--- a/drivers/pinctrl/mediatek/Kconfig
+++ b/drivers/pinctrl/mediatek/Kconfig
@@ -9,6 +9,12 @@ config PINCTRL_MTK_COMMON
select OF_GPIO
# For ARMv7 SoCs
+config PINCTRL_MT2701
+ bool "Mediatek MT2701 pin control" if COMPILE_TEST && !MACH_MT2701
+ depends on OF
+ default MACH_MT2701
+ select PINCTRL_MTK_COMMON
+
config PINCTRL_MT8135
bool "Mediatek MT8135 pin control" if COMPILE_TEST && !MACH_MT8135
depends on OF
diff --git a/drivers/pinctrl/mediatek/Makefile
b/drivers/pinctrl/mediatek/Makefile
index eb923d6..da30314 100644
--- a/drivers/pinctrl/mediatek/Makefile
+++ b/drivers/pinctrl/mediatek/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_PINCTRL_MTK_COMMON) += pinctrl-mtk-common.o
# SoC Drivers
+obj-$(CONFIG_PINCTRL_MT2701) += pinctrl-mt2701.o
obj-$(CONFIG_PINCTRL_MT8135) += pinctrl-mt8135.o
obj-$(CONFIG_PINCTRL_MT8127) += pinctrl-mt8127.o
obj-$(CONFIG_PINCTRL_MT8173) += pinctrl-mt8173.o
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt2701.c
b/drivers/pinctrl/mediatek/pinctrl-mt2701.c
new file mode 100644
index 000..da372e9
--- /dev/null
+++ b/drivers/pinctrl/mediatek/pinctrl-mt2701.c
@@ -0,0 +1,571 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Biao Huang
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pinctrl-mtk-common.h"
+#include "pinctrl-mtk-mt2701.h"
+
+/**
+ * struct mtk_spec_pinmux_set
+ * - For special pins' mode setting
+ * @pin: The pin number.
+ * @offset: The offset of extra setting register.
+ * @bit: The bit of extra setting register.
+ */
+struct mtk_spec_pinmux_set {
+ unsigned short pin;
+ unsigned short offset;
+ unsigned char bit;
+};
+
+#define MTK_PINMUX_SPEC(_pin, _offset, _bit) \
+ { \
+ .pin = _pin,\
+ .offset = _offset, \
+ .bit = _bit,\
+ }
+
+static const struct mtk_drv_group_desc mt2701_drv_grp[] = {
+ /* 0E4E8SR 4/8/12/16 */
+ MTK_DRV_GRP(4, 16, 1, 2, 4),
+ /* 0E2E4SR 2/4/6/8 */
+ MTK_DRV_GRP(2, 8, 1, 2, 2),
+ /* E8E4E2 2/4/6/8/10/12/14/16 */
+ MTK_DRV_GRP(2, 16, 0, 2, 2)
+};
+
+static const struct mtk_pin_drv_grp mt2701_pin_drv[] = {
+ MTK_PIN_DRV_GRP(0, 0xf50, 0, 1),
+ MTK_PIN_DRV_GRP(1, 0xf50, 0, 1),
+ MTK_PIN_DRV_GRP(2, 0xf50, 0, 1),
+ MTK_PIN_DRV_GRP(3, 0xf50, 0, 1),
+ MTK_PIN_DRV_GRP(4, 0xf50, 0, 1),
+ MTK_PIN_DRV_GRP(5, 0xf50, 0, 1),
+ MTK_PIN_DRV_GRP(6, 0xf50, 0, 1),
+ MTK_PIN_DRV_GRP(7, 0xf50, 4, 1),
+ MTK_PIN_DRV_GRP(8, 0xf50, 4, 1),
+ MTK_PIN_DRV_GRP(9, 0xf50, 4, 1),
+ MTK_PIN_DRV_GRP(10, 0xf50, 8, 1),
+ MTK_PIN_DRV_GRP(11, 0xf50, 8, 1),
+ MTK_PIN_DRV_GRP(12, 0xf50, 8, 1),
+ MTK_PIN_DRV_GRP(13, 0xf50, 8, 1),
+ MTK_PIN_DRV_GRP(14, 0xf50, 12, 0),
+ MTK_PIN_DRV_GRP(15, 0xf50, 12, 0),
+ MTK_PIN_DRV_GRP(16, 0xf60, 0, 0),
+ MTK_PIN_DRV_GRP(17, 0xf60, 0, 0),
+ MTK_PIN_DRV_GRP(18, 0xf60, 4, 0),
+ MTK_PIN_DRV_GRP(19, 0xf60, 4, 0),
+ MTK_PIN_DRV_GRP(20, 0xf60, 4, 0),
+ MTK_PIN_DRV_GRP(21, 0xf60, 4, 0),
+ MTK_PIN_DRV_GRP(22, 0xf60, 8, 0),
+ MTK_PIN_DRV_GRP(23, 0xf60, 8, 0),
+ MTK_PIN_DRV_GRP(24, 0xf60, 8, 0),
+ MTK_PIN_DRV_GRP(25, 0xf60, 8, 0),
+ MTK_PIN_DRV_GRP(26, 0xf60, 8, 0),
+ MTK_PIN_DRV_GRP(27, 0xf60, 12, 0),
+ MTK_PIN_DRV_GRP(28, 0xf60, 12, 0),
+ MTK_PIN_DRV_GRP(29, 0xf60, 12, 0),
+ MTK_PIN_DRV_GRP(30, 0xf60, 0, 0),
+ MTK_PIN_DRV_GRP(31, 0xf60, 0, 0),
[PATCH 1/5] ARM: mediatek: Add MT2701 config options for mediatek SoCs.
From: Erin Lo The upcoming MTK pinctrl driver have a big pin table for each SoC and we don't want to bloat the kernel binary if we don't need it. Add config options so we can build for one SoC only. Add MT2701. Signed-off-by: Erin Lo --- arch/arm/mach-mediatek/Kconfig |4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig index aeece17..37dd438 100644 --- a/arch/arm/mach-mediatek/Kconfig +++ b/arch/arm/mach-mediatek/Kconfig @@ -9,6 +9,10 @@ menuconfig ARCH_MEDIATEK if ARCH_MEDIATEK +config MACH_MT2701 + bool "MediaTek MT2701 SoCs support" + default ARCH_MEDIATEK + config MACH_MT6589 bool "MediaTek MT6589 SoCs support" default ARCH_MEDIATEK -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] pinctrl: dt bindings: Add pinfunc header file for mt2701
Add pinfunc header file, mt2701 related dts will include it Signed-off-by: Biao Huang --- arch/arm/boot/dts/mt2701-pinfunc.h | 713 1 file changed, 713 insertions(+) create mode 100644 arch/arm/boot/dts/mt2701-pinfunc.h diff --git a/arch/arm/boot/dts/mt2701-pinfunc.h b/arch/arm/boot/dts/mt2701-pinfunc.h new file mode 100644 index 000..64cebf6 --- /dev/null +++ b/arch/arm/boot/dts/mt2701-pinfunc.h @@ -0,0 +1,713 @@ +/* + * Copyright (c) 2015 MediaTek Inc. + * Author: Biao Huang + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + */ + +#ifndef __DTS_MT2701_PINFUNC_H +#define __DTS_MT2701_PINFUNC_H + +#include + +#define MT2701_PIN_0_PWRAP_SPI0_MI__FUNC_GPIO0 (MTK_PIN_NO(0) | 0) +#define MT2701_PIN_0_PWRAP_SPI0_MI__FUNC_PWRAP_SPIDO (MTK_PIN_NO(0) | 1) +#define MT2701_PIN_0_PWRAP_SPI0_MI__FUNC_PWRAP_SPIDI (MTK_PIN_NO(0) | 2) + +#define MT2701_PIN_1_PWRAP_SPI0_MO__FUNC_GPIO1 (MTK_PIN_NO(1) | 0) +#define MT2701_PIN_1_PWRAP_SPI0_MO__FUNC_PWRAP_SPIDI (MTK_PIN_NO(1) | 1) +#define MT2701_PIN_1_PWRAP_SPI0_MO__FUNC_PWRAP_SPIDO (MTK_PIN_NO(1) | 2) + +#define MT2701_PIN_2_PWRAP_INT__FUNC_GPIO2 (MTK_PIN_NO(2) | 0) +#define MT2701_PIN_2_PWRAP_INT__FUNC_PWRAP_INT (MTK_PIN_NO(2) | 1) + +#define MT2701_PIN_3_PWRAP_SPI0_CK__FUNC_GPIO3 (MTK_PIN_NO(3) | 0) +#define MT2701_PIN_3_PWRAP_SPI0_CK__FUNC_PWRAP_SPICK_I (MTK_PIN_NO(3) | 1) + +#define MT2701_PIN_4_PWRAP_SPI0_CSN__FUNC_GPIO4 (MTK_PIN_NO(4) | 0) +#define MT2701_PIN_4_PWRAP_SPI0_CSN__FUNC_PWRAP_SPICS_B_I (MTK_PIN_NO(4) | 1) + +#define MT2701_PIN_5_PWRAP_SPI0_CK2__FUNC_GPIO5 (MTK_PIN_NO(5) | 0) +#define MT2701_PIN_5_PWRAP_SPI0_CK2__FUNC_PWRAP_SPICK2_I (MTK_PIN_NO(5) | 1) +#define MT2701_PIN_5_PWRAP_SPI0_CK2__FUNC_ANT_SEL1 (MTK_PIN_NO(5) | 5) + +#define MT2701_PIN_6_PWRAP_SPI0_CSN2__FUNC_GPIO6 (MTK_PIN_NO(6) | 0) +#define MT2701_PIN_6_PWRAP_SPI0_CSN2__FUNC_PWRAP_SPICS2_B_I (MTK_PIN_NO(6) | 1) +#define MT2701_PIN_6_PWRAP_SPI0_CSN2__FUNC_ANT_SEL0 (MTK_PIN_NO(6) | 5) +#define MT2701_PIN_6_PWRAP_SPI0_CSN2__FUNC_DBG_MON_A_0 (MTK_PIN_NO(6) | 7) + +#define MT2701_PIN_7_SPI1_CSN__FUNC_GPIO7 (MTK_PIN_NO(7) | 0) +#define MT2701_PIN_7_SPI1_CSN__FUNC_SPI1_CS (MTK_PIN_NO(7) | 1) +#define MT2701_PIN_7_SPI1_CSN__FUNC_KCOL0 (MTK_PIN_NO(7) | 4) +#define MT2701_PIN_7_SPI1_CSN__FUNC_DBG_MON_B_12 (MTK_PIN_NO(7) | 7) + +#define MT2701_PIN_8_SPI1_MI__FUNC_GPIO8 (MTK_PIN_NO(8) | 0) +#define MT2701_PIN_8_SPI1_MI__FUNC_SPI1_MI (MTK_PIN_NO(8) | 1) +#define MT2701_PIN_8_SPI1_MI__FUNC_SPI1_MO (MTK_PIN_NO(8) | 2) +#define MT2701_PIN_8_SPI1_MI__FUNC_KCOL1 (MTK_PIN_NO(8) | 4) +#define MT2701_PIN_8_SPI1_MI__FUNC_DBG_MON_B_13 (MTK_PIN_NO(8) | 7) + +#define MT2701_PIN_9_SPI1_MO__FUNC_GPIO9 (MTK_PIN_NO(9) | 0) +#define MT2701_PIN_9_SPI1_MO__FUNC_SPI1_MO (MTK_PIN_NO(9) | 1) +#define MT2701_PIN_9_SPI1_MO__FUNC_SPI1_MI (MTK_PIN_NO(9) | 2) +#define MT2701_PIN_9_SPI1_MO__FUNC_EXT_FRAME_SYNC (MTK_PIN_NO(9) | 3) +#define MT2701_PIN_9_SPI1_MO__FUNC_KCOL2 (MTK_PIN_NO(9) | 4) +#define MT2701_PIN_9_SPI1_MO__FUNC_DBG_MON_B_14 (MTK_PIN_NO(9) | 7) + +#define MT2701_PIN_10_RTC32K_CK__FUNC_GPIO10 (MTK_PIN_NO(10) | 0) +#define MT2701_PIN_10_RTC32K_CK__FUNC_RTC32K_CK (MTK_PIN_NO(10) | 1) + +#define MT2701_PIN_11_WATCHDOG__FUNC_GPIO11 (MTK_PIN_NO(11) | 0) +#define MT2701_PIN_11_WATCHDOG__FUNC_WATCHDOG (MTK_PIN_NO(11) | 1) + +#define MT2701_PIN_12_SRCLKENA__FUNC_GPIO12 (MTK_PIN_NO(12) | 0) +#define MT2701_PIN_12_SRCLKENA__FUNC_SRCLKENA (MTK_PIN_NO(12) | 1) + +#define MT2701_PIN_13_SRCLKENAI__FUNC_GPIO13 (MTK_PIN_NO(13) | 0) +#define MT2701_PIN_13_SRCLKENAI__FUNC_SRCLKENAI (MTK_PIN_NO(13) | 1) + +#define MT2701_PIN_14_URXD2__FUNC_GPIO14 (MTK_PIN_NO(14) | 0) +#define MT2701_PIN_14_URXD2__FUNC_URXD2 (MTK_PIN_NO(14) | 1) +#define MT2701_PIN_14_URXD2__FUNC_UTXD2 (MTK_PIN_NO(14) | 2) +#define MT2701_PIN_14_URXD2__FUNC_SRCCLKENAI2 (MTK_PIN_NO(14) | 5) +#define MT2701_PIN_14_URXD2__FUNC_DBG_MON_B_30 (MTK_PIN_NO(14) | 7) + +#define MT2701_PIN_15_UTXD2__FUNC_GPIO15 (MTK_PIN_NO(15) | 0) +#define MT2701_PIN_15_UTXD2__FUNC_UTXD2 (MTK_PIN_NO(15) | 1) +#define MT2701_PIN_15_UTXD2__FUNC_URXD2 (MTK_PIN_NO(15) | 2) +#define MT2701_PIN_15_UTXD2__FUNC_DBG_MON_B_31 (MTK_PIN_NO(15) | 7) + +#define MT2701_PIN_18_PCM_CLK__FUNC_GPIO18 (MTK_PIN_NO(18) | 0) +#define MT2701_PIN_18_PCM_CLK__FUNC_PCM_CLK0 (MTK_PIN_NO(18) | 1) +#define MT2701_PIN_18_PCM_CLK__FUNC_MRG_CLK (MTK_PIN_NO(18) | 2) +#define MT2701_PIN_18_PCM_CLK__FUNC_MM_TEST_CK (MTK_PIN_NO(18) | 4) +#define MT2701_PIN_18_PCM_CLK__FUNC_CONN_DSP_JCK (MTK_PIN_NO(18) | 5) +#define MT2701_PIN_18_PCM_CLK__FUNC_WCN_PCM_CLKO (MTK_PIN_NO(18) | 6) +#define MT2701_PIN_18
Re: [PATCH 3/3] perf callchain: Honor hide_unresolved
On Thu, Nov 26, 2015 at 04:08:20PM +0900, Namhyung Kim wrote: > If user requested to hide unresolved entries, skip unresolved callchains > as well as hist entries. > > Signed-off-by: Namhyung Kim Acked-by: Jiri Olsa thanks, jirka -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms
Hi Lee, On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones wrote: > ST's platforms often have multiple co-processors (usually ST40s or ST231s) > on-board. This provides the Linux-side infrastructure to flash and boot > them successfully. > > This set has been tested on an STiH410-B2120. It would be nice if you could get at least one Reviewed-by tag coming outside of ST (e.g., Suman or Bjorn who are actively using and improving remoteproc). > arch/arm/boot/dts/stih407-family.dtsi | 70 + Since this is outside of remoteproc, please have it Acked, preferably by ARM DT maintainer (Olof?). Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] dt-bindings: mediatek: Modify pinctrl bindings for mt2701
Signed-off-by: Biao Huang --- .../devicetree/bindings/pinctrl/pinctrl-mt65xx.txt |9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt index 0480bc3..ca6a27a 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt @@ -4,10 +4,11 @@ The Mediatek's Pin controller is used to control SoC pins. Required properties: - compatible: value should be one of the following. -(a) "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. -(b) "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. -(c) "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. -(d) "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl. +(a) "mediatek,mt2701-pinctrl", compatible with mt2701 pinctrl. +(b) "mediatek,mt6397-pinctrl", compatible with mt6397 pinctrl. +(c) "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. +(d) "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. +(e) "mediatek,mt8127-pinctrl", compatible with mt8127 pinctrl. - pins-are-numbered: Specify the subnodes are using numbered pinmux to specify pins. - gpio-controller : Marks the device node as a gpio controller. -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] crypto: AES CBC multi-buffer glue code
On Tue, Nov 24, 2015 at 10:30:06AM -0800, Tim Chen wrote: > > On the decrypt path, we don't need to use multi-buffer algorithm > as aes-cbc decrypt can be parallelized inherently on a single > request. So most of the time the outer layer algorithm > cbc_mb_async_ablk_decrypt can bypass mcryptd and > invoke mb_aes_cbc_decrypt synchronously > to do aes_cbc_dec when fpu is available. > This avoids the overhead of going through mcryptd. Hence > the use of blkcipher on the inner layer. For the mcryptd > path, we will complete a decrypt request in one shot so > blkcipher usage should be fine. I think there is a misunderstanding here. Just because you're using/exporting through the ablkcipher interface doesn't mean that you are asynchrounous. For example, all blkcipher algorithms can be accessed through the ablkcipher interface and they of course remain synchrounous. So I don't see how using an ablkcipher in the inner layer changes anything at all. You can still return immediately and not bother with completion functions when you are synchrounous. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6] clk: add CS2000 Fractional-N driver
Hi again
ping again ?
> ping ?
>
> >
> > From: Kuninori Morimoto
> >
> > This patch adds CS2000 Fractional-N driver as clock provider.
> >
> > Signed-off-by: Kuninori Morimoto
> > ---
> > v5 -> v6
> >
> > - remove redundant variable from each functions
> > - multi line code become one line
> > - end of comment has dot
> > - cs2000_wait_pll_lock() returns -ETIMEDOUT instead of -EIO
> > - removed explicit casting from ratio function
> > - removed magic number
> >
> > .../devicetree/bindings/clock/cs2000-cp.txt| 22 +
> > drivers/clk/Kconfig| 6 +
> > drivers/clk/Makefile | 1 +
> > drivers/clk/clk-cs2000-cp.c| 509
> > +
> > 4 files changed, 538 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/clock/cs2000-cp.txt
> > create mode 100644 drivers/clk/clk-cs2000-cp.c
> >
> > diff --git a/Documentation/devicetree/bindings/clock/cs2000-cp.txt
> > b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
> > new file mode 100644
> > index 000..54e6df0
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
> > @@ -0,0 +1,22 @@
> > +CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
> > +
> > +Required properties:
> > +
> > +- compatible: "cirrus,cs2000-cp"
> > +- reg: The chip select number on the I2C bus
> > +- clocks: common clock binding for CLK_IN, XTI/REF_CLK
> > +- clock-names: CLK_IN : clk_in, XTI/REF_CLK : ref_clk
> > +- #clock-cells:must be <0>
> > +
> > +Example:
> > +
> > +&i2c2 {
> > + ...
> > + cs2000: clk_multiplier@4f {
> > + #clock-cells = <0>;
> > + compatible = "cirrus,cs2000-cp";
> > + reg = <0x4f>;
> > + clocks = <&rcar_sound 0>, <&x12_clk>;
> > + clock-names = "clk_in", "ref_clk";
> > + };
> > +};
> > diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> > index a1fa611..b8c347f 100644
> > --- a/drivers/clk/Kconfig
> > +++ b/drivers/clk/Kconfig
> > @@ -116,6 +116,12 @@ config COMMON_CLK_CDCE925
> > Given a target output frequency, the driver will set the PLL and
> > divider to best approximate the desired output.
> >
> > +config COMMON_CLK_CS2000_CP
> > + tristate "Clock driver for CS2000 Fractional-N Clock Synthesizer &
> > Clock Multiplier"
> > + depends on I2C
> > + help
> > + If you say yes here you get support for the CS2000 clock multiplier.
> > +
> > config COMMON_CLK_S2MPS11
> > tristate "Clock driver for S2MPS1X/S5M8767 MFD"
> > depends on MFD_SEC_CORE
> > diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
> > index 366350a..86afe50 100644
> > --- a/drivers/clk/Makefile
> > +++ b/drivers/clk/Makefile
> > @@ -21,6 +21,7 @@ obj-$(CONFIG_MACH_ASM9260)+= clk-asm9260.o
> > obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)+= clk-axi-clkgen.o
> > obj-$(CONFIG_ARCH_AXXIA) += clk-axm5516.o
> > obj-$(CONFIG_COMMON_CLK_CDCE706) += clk-cdce706.o
> > +obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
> > obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
> > obj-$(CONFIG_ARCH_EFM32) += clk-efm32gg.o
> > obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
> > diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
> > new file mode 100644
> > index 000..cc90d87
> > --- /dev/null
> > +++ b/drivers/clk/clk-cs2000-cp.c
> > @@ -0,0 +1,509 @@
> > +/*
> > + * CS2000 -- CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock
> > Multiplier
> > + *
> > + * Copyright (C) 2015 Renesas Electronics Corporation
> > + * Kuninori Morimoto
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2 as
> > + * published by the Free Software Foundation.
> > + */
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define CH_MAX 4
> > +#define RATIO_REG_SIZE 4
> > +
> > +#define DEVICE_ID 0x1
> > +#define DEVICE_CTRL0x2
> > +#define DEVICE_CFG10x3
> > +#define DEVICE_CFG20x4
> > +#define GLOBAL_CFG 0x5
> > +#define Ratio_Add(x, nth) (6 + (x * 4) + (nth))
> > +#define Ratio_Val(x, nth) ((x >> (24 - (8 * nth))) & 0xFF)
> > +#define Val_Ratio(x, nth) ((x & 0xFF) << (24 - (8 * nth)))
> > +#define FUNC_CFG1 0x16
> > +#define FUNC_CFG2 0x17
> > +
> > +/* DEVICE_ID */
> > +#define REVISION_MASK (0x7)
> > +#define REVISION_B2_B3 (0x4)
> > +#define REVISION_C1(0x6)
> > +
> > +/* DEVICE_CTRL */
> > +#define PLL_UNLOCK (1 << 7)
> > +
> > +/* DEVICE_CFG1 */
> > +#define RSEL(x)(((x) & 0x3) << 3)
> > +#define RSEL_MASK RSEL(0x3)
> > +#define ENDEV1 (0x1)
> > +
> > +/* GLOBAL_CFG */
> > +#define ENDEV2 (0x1)
> > +
> > +#define CH_SIZE_ERR(ch)((ch < 0) ||
[PATCH] firmware: dmi_scan: Optimize dmi_save_extended_devices
Calling dmi_string_nosave isn't cheap, so avoid calling it twice in a
row for the same string.
Signed-off-by: Jean Delvare
Cc: Jordan Hargrave
Cc: Narendra K
---
drivers/firmware/dmi_scan.c |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
--- linux-4.3.orig/drivers/firmware/dmi_scan.c 2015-11-25 20:32:26.565009189
+0100
+++ linux-4.3/drivers/firmware/dmi_scan.c 2015-11-26 09:44:34.242605581
+0100
@@ -345,15 +345,17 @@ static void __init dmi_save_dev_onboard(
static void __init dmi_save_extended_devices(const struct dmi_header *dm)
{
+ const char *name;
const u8 *d = (u8 *) dm + 5;
/* Skip disabled device */
if ((*d & 0x80) == 0)
return;
+ name = dmi_string_nosave(dm, *(d - 1));
dmi_save_dev_onboard(*(d+1), *(u16 *)(d+2), *(d+4), *(d+5),
-dmi_string_nosave(dm, *(d-1)));
- dmi_save_one_device(*d & 0x7f, dmi_string_nosave(dm, *(d - 1)));
+name);
+ dmi_save_one_device(*d & 0x7f, name);
}
static void __init count_mem_devices(const struct dmi_header *dm, void *v)
--
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware: dmi_scan: Fix dmi_find_device description
The description of dmi_find_device was apparently copied from a similar function in a different subsystem, but the parameter names were not adjusted as needed. Signed-off-by: Jean Delvare Cc: Andrey Panin --- drivers/firmware/dmi_scan.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-4.3.orig/drivers/firmware/dmi_scan.c 2015-11-26 09:41:45.032767005 +0100 +++ linux-4.3/drivers/firmware/dmi_scan.c 2015-11-26 09:41:54.205975102 +0100 @@ -871,7 +871,7 @@ EXPORT_SYMBOL(dmi_name_in_vendors); * @from: previous device found in search, or %NULL for new search. * * Iterates through the list of known onboard devices. If a device is - * found with a matching @vendor and @device, a pointer to its device + * found with a matching @type and @name, a pointer to its device * structure is returned. Otherwise, %NULL is returned. * A new search is initiated by passing %NULL as the @from argument. * If @from is not %NULL, searches continue from next device. -- Jean Delvare SUSE L3 Support -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] printk: do cond_resched() between lines while outputting to consoles
Hello, On Wed 25-11-15 12:02:17, Tejun Heo wrote: > On Wed, Nov 25, 2015 at 10:05:22AM +0100, Jan Kara wrote: > > So did you particularly have an issue during console registration? Because > > Yeap, we're seeing a small ratio of machines falling head over hills > during IPMI serial console registration. Pumping out the messages > collected prior to registration takes too long triggering softlockup > warning on all forty something CPUs which pile a metric ton of > messages atop. From then on, softlockup / rcu stall warnings repeat > themselves. Some machines recover after >10mins of doing that. The > log is hillarious to look at afterward. OK, then feel free to add my: Acked-by: Jan Kara > > at least our customers mostly have issues during heavy use of ordinary > > printk (e.g. during boot or when hardware gets probed) and your change > > doesn't affect that case. That being said if you really hit a case where > > Hah, that must be a lot of messages being printk'd. Yes, it is. They have ~1000 SCSI devices attached (250 disks, each over 4 paths) and similar stuff. But also doing sysrq-t on a large machine generates enough output to kill the machine... > > your patch helps, then I have no problem with it (you can add my Acked-by). > > > > At Kernel Summit I spoke with Linus and Andrew regarding printk softlockups > > and we ended up with a decision that we decouple queueing into kernel > > ringbuffer from the actual printing into console which would happen from > > kthread / workqueue. Then the lockups would be solved by printing to > > console happening from schedulable context and printk() as such being > > independent from console speed. We only have to have some special cases > > there for crashes so that messages get printed synchronously in that case. > > Yeah, we'd prolly want to make the behavior contingent on the time > taken and so on. At any rate, even with workqueue-deferred dumping, > this patch would still be necessary for non-preemptible kernels; > otherwise, there's no cond_resched() in printing path right now. Yup. Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
* PaX Team wrote: > On 25 Nov 2015 at 10:13, Mathias Krause wrote: > > > I myself had some educating experience seeing my machine triple fault > > when resuming from a S3 sleep. The root cause was a variable that was > > annotated __read_only but that was (unnecessarily) modified during CPU > > bring-up phase. Debugging that kind of problems is sort of a PITA, you > > could imagine. ( Sidenote: I don't think a ro-faults typically result in triple faults, but yeah, even having a regular oops (followed by a hang or reboot) during such an undebuggable state of the system is a major PITA. ) > actually the kernel could silently recover from this given how the page fault > handler could easily determine that the fault address fell into the > data..read_only section and just silently undo the read-only property, log > the > event to dmesg and retry the faulting access. So a safer method would be to decode the faulting instruction, to skip it by fixing up the return RIP and to log the event. It would be mostly equivalent to trying to write to ROM (which get ignored as well), so it's a recoverable (and debuggable) event. We have all the necessary code in place in the kprobes code, see arch/x86/lib/insn.c, it's a simplified x86 decoder that knows about instruction length (but not about semantics). Simple skipping plus setting arithmetic flags to init value should be enough I think: I don't think we use fancy instructions to write to ro variables, such as PUSH/POP with other side effects. If such instructions exist we could minimally extend the decoder to do those fixups as well - in addition to double checking that we skip simple instructions only with no side effects. Can you see any fragility in such a technique? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Improve spinlock performance by moving work to one core
Run thread.c with clean kernel 4.3.0-rc4, perf top -G also indicates
cache_flusharray and cache_alloc_refill functions spend 25.6% time
on queued_spin_lock_slowpath totally. it means the compared data
from our spinlock-test.patch is reliable.
Thanks
Ling
2015-11-26 11:49 GMT+08:00 Ling Ma :
> Hi Longman,
>
> All compared data is from the below operation in spinlock-test.patch:
>
> +#if ORG_QUEUED_SPINLOCK
> + org_queued_spin_lock((struct qspinlock *)&pa.n->list_lock);
> + refill_fn(&pa);
> + org_queued_spin_unlock((struct qspinlock *)&pa.n->list_lock);
> +#else
> + new_spin_lock((struct nspinlock *)&pa.n->list_lock, refill_fn, &pa);
> +#endif
>
> and
>
> +#if ORG_QUEUED_SPINLOCK
> + org_queued_spin_lock((struct qspinlock *)&pa.n->list_lock);
> + flusharray_fn(&pa);
> + org_queued_spin_unlock((struct qspinlock *)&pa.n->list_lock);
> +#else
> + new_spin_lock((struct nspinlock *)&pa.n->list_lock, flusharray_fn,
> &pa);
> +#endif
>
> So the result is correct and fair.
>
> Yes, we updated the code in include/asm-generic/qspinlock.h to
> simplified modification and avoid kernel crash,
> for example there are 10 lock scenarios to use new spin lock,
> because bottle-neck is only from one or two scenarios, we only modify them,
> other lock scenarios will continue to use the lock in qspinlock.h, we
> must modify the code,
> otherwise the operation will be hooked in the queued and never be waken up.
>
> Thanks
> Ling
>
>
>
> 2015-11-26 3:05 GMT+08:00 Waiman Long :
>> On 11/23/2015 04:41 AM, Ling Ma wrote:
>>> Hi Longman,
>>>
>>> Attachments include user space application thread.c and kernel patch
>>> spinlock-test.patch based on kernel 4.3.0-rc4
>>>
>>> we run thread.c with kernel patch, test original and new spinlock
>>> respectively,
>>> perf top -G indicates thread.c cause cache_alloc_refill and
>>> cache_flusharray functions to spend ~25% time on original spinlock,
>>> after introducing new spinlock in two functions, the cost time become ~22%.
>>>
>>> The printed data also tell us the new spinlock improves performance
>>> by about 15%( 93841765576 / 81036259588) on E5-2699V3
>>>
>>> Appreciate your comments.
>>>
>>>
>>
>> I saw that you make the following changes in the code:
>>
>> static __always_inline void queued_spin_lock(struct qspinlock *lock)
>> {
>> u32 val;
>> -
>> +repeat:
>> val = atomic_cmpxchg(&lock->val, 0, _Q_LOCKED_VAL);
>> if (likely(val == 0))
>> return;
>> - queued_spin_lock_slowpath(lock, val);
>> + goto repeat;
>> + //queued_spin_lock_slowpath(lock, val);
>> }
>>
>>
>> This effectively changes the queued spinlock into an unfair byte lock.
>> Without a pause to moderate the cmpxchg() call, that is especially bad
>> for performance. Is the performance data above refers to the unfair byte
>> lock versus your new spinlock?
>>
>> Cheers,
>> Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] iio: ina2xx: add support for TI INA2xx Power Monitors
On 25/11/2015 13:20, Peter Meerwald-Stadler wrote:
in SOFTWARE buffer mode, a kthread will capture the active scan_elements
into a kfifo, then compute the remaining time until the next capture tick
and do an active wait (udelay).
minor comments below
Thanks Peter! All fixed in next iteration.
M.
...
+config INA2XX_IIO
+ tristate "Texas Instruments INA2xx Power Monitors IIO driver"
+ depends on I2C
+ select REGMAP_I2C
+ select IIO_BUFFER
+ help
+ Say yes here to build support for TI INA2xx familly Power Monitors.
family
+
+ Note that this is not the existing hwmon interface for this device.
this message not very clear
removed. This was fuel to discuss the RFC.
...
+
+/*
+ * INA2XX registers definition
+ */
+/* common register definitions */
comment style; do we need both?
removed one.
+
+/*Integration Time for VShunt */
time
ok
+ int itb; /* Bus voltage integration time uS */
+ int its; /* Shunt voltage integration tim uS */
time
ok
ge_shift)
+ * chip->config->bus_voltage_lsb;
+ *val = *uval/100;
whitespace around / please
ok
+
+static unsigned int ina226_set_average(struct ina2xx_chip_info *chip,
retval should have type int
indeed!
+static const int ina226_conv_time_tab[] = { 140, 204, 332, 588, 1100,
+ 2116, 4156, 8244};
maybe whitespace before }
ok
+}
+
+static unsigned int ina226_set_its(struct ina2xx_chip_info *chip,
retval should have type int
ok
+ return 0;
+}
+
drop dup newline
ok
+
+/*Sampling Freq is a consequence of the integration times of the V channels.*/
whitespace after /* and before */ please
ok
+#define INA2XX_CHAN_VOLTAGE(_index, _address) { \
+ .type = IIO_VOLTAGE, \
+ .address = _address, \
+ .indexed = 1, \
+ .channel = (_index), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_INT_TIME), \
+ .scan_index = (_index), \
+ .scan_type = { \
+ .sign = 'u', \
+ .realbits = 16, \
+ .storagebits = 16, \
+ .endianness = IIO_BE, \
+ } \
+}
+
drop dup newline
ok
+}
+
+/* frequencies matching the cummulated integration times for vshunt and vbus */
cumulated
wrong comment anyway, fixed.
+* Set current LSB to 1mA, shunt is in uOhms
+* (equation 13 in datasheet). We hardcode a Current_LSB
+* of 1.0 x10-6. The only remaining parameter is RShunt
full stop
ok
+ mutex_destroy(&chip->state_lock);
needed?
removed.
+
+ iio_device_unregister(indio_dev);
not needed since devm_iio_device_register() is used
ok
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] usb: devio: Add ioctl to disallow detaching kernel USB drivers.
On Wed, Nov 25, 2015 at 12:45:34PM -0300, Emilio López wrote:
> From: Reilly Grant
>
> The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
> relinquish the ability to issue other ioctls that may interfere with
> other processes and drivers that have claimed an interface on the
> device.
>
> Signed-off-by: Reilly Grant
> Reviewed-by: Jorge Lucangeli Obes
> Reviewed-by: Kees Cook
> [emilio.lopez: fix build for v4.4-rc2 and adjust patch title prefix]
> Signed-off-by: Emilio López
>
> ---
>
> drivers/usb/core/devio.c | 50
> +++
> include/uapi/linux/usbdevice_fs.h | 1 +
> 2 files changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> index 38ae877c..a5ccc50 100644
> --- a/drivers/usb/core/devio.c
> +++ b/drivers/usb/core/devio.c
> @@ -77,6 +77,7 @@ struct usb_dev_state {
> unsigned long ifclaimed;
> u32 secid;
> u32 disabled_bulk_eps;
> + bool privileges_dropped;
> };
>
> struct async {
> @@ -878,7 +879,7 @@ static int usbdev_open(struct inode *inode, struct file
> *file)
> int ret;
>
> ret = -ENOMEM;
> - ps = kmalloc(sizeof(struct usb_dev_state), GFP_KERNEL);
> + ps = kzalloc(sizeof(struct usb_dev_state), GFP_KERNEL);
> if (!ps)
> goto out_free_ps;
>
> @@ -911,11 +912,8 @@ static int usbdev_open(struct inode *inode, struct file
> *file)
> INIT_LIST_HEAD(&ps->async_pending);
> INIT_LIST_HEAD(&ps->async_completed);
> init_waitqueue_head(&ps->wait);
> - ps->discsignr = 0;
> ps->disc_pid = get_pid(task_pid(current));
> ps->cred = get_current_cred();
> - ps->disccontext = NULL;
> - ps->ifclaimed = 0;
The above changes seem to be not related with this change.
> security_task_getsecid(current, &ps->secid);
> smp_wmb();
> list_add_tail(&ps->list, &dev->filelist);
> @@ -1215,6 +1213,35 @@ static int proc_connectinfo(struct usb_dev_state *ps,
> void __user *arg)
>
> static int proc_resetdevice(struct usb_dev_state *ps)
> {
> + if (ps->privileges_dropped) {
> + struct usb_host_config *actconfig = ps->dev->actconfig;
> +
> + /* Don't touch the device if any interfaces are claimed. It
> + * could interfere with other drivers' operations and this
> + * process has dropped its privileges to do such things.
> + */
> + if (actconfig) {
> + int i;
> +
> + for (i = 0; i < actconfig->desc.bNumInterfaces; ++i) {
> + if (usb_interface_claimed(
> + actconfig->interface[i])) {
> + dev_warn(&ps->dev->dev,
> + "usbfs: interface %d claimed by"
> + " %s while '%s'"
> + " resets device\n",
> + actconfig->interface[i]
> + ->cur_altsetting
> + ->desc.bInterfaceNumber,
The length of line is 80 characters
> + actconfig->interface[i]
> + ->dev.driver->name,
> + current->comm);
> + return -EACCES;
> + }
> + }
> + }
> + }
> +
> return usb_reset_device(ps->dev);
> }
>
> @@ -1922,6 +1949,9 @@ static int proc_ioctl(struct usb_dev_state *ps, struct
> usbdevfs_ioctl *ctl)
> struct usb_interface*intf = NULL;
> struct usb_driver *driver = NULL;
>
> + if (ps->privileges_dropped)
> + return -EACCES;
> +
> /* alloc buffer */
> size = _IOC_SIZE(ctl->ioctl_code);
> if (size > 0) {
> @@ -2084,6 +2114,9 @@ static int proc_disconnect_claim(struct usb_dev_state
> *ps, void __user *arg)
> sizeof(dc.driver)) == 0)
> return -EBUSY;
>
> + if (ps->privileges_dropped)
> + return -EACCES;
> +
> dev_dbg(&intf->dev, "disconnect by usbfs\n");
> usb_driver_release_interface(driver, intf);
> }
> @@ -2130,6 +2163,12 @@ static int proc_free_streams(struct usb_dev_state *ps,
> void __user *arg)
> return r;
> }
>
> +static int proc_drop_privileges(struct usb_dev_state *ps)
> +{
> + ps->privileges_dropped = true;
> + return 0;
> +}
> +
> /*
> * NOTE: All requests here that have interface numbers as parameters
> * are assuming that somehow the configuration has been prevented from
> @@ -2318,6 +2357,9 @@ static long usbdev_do_ioctl(struct file *file, unsigned
> in
Re: [PATCH] remoteproc: report error if resource table doesn't exist
Hi Stefan, On Sat, Aug 29, 2015 at 4:08 AM, Stefan Agner wrote: > Currently, if the resource table is completely missing in the > firmware, powering up the remoteproc fails silently. Add a message > indicating that the resource table is missing in the firmware. > > Signed-off-by: Stefan Agner Applied to remoteproc-next, thanks. > This also opens up a more general question: Is it mandatory to have > a resource table in the firmware? The implementation we have today does require it, but that's just because this is what we had to support so far. > Theoretically a remoteproc could > also work completely independent, all what would be used from the > remoteproc framework is the loading and starting capabilities... Sure. Feel free to add support for your hardware as needed. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] arm: boot: store ATAGs structure into DT "/chosen/linux,atags" entry
On Wednesday 25 November 2015 20:19:21 Frank Rowand wrote: > > Or populate /proc/atags only for the ones that need it from machine > > specific init_early? > > This is circling back to the first comment from Russell King where > he suggested a legacy file for the N900 which calls save_atags(): > > Are the ATAGs at a fixed address on the N900? Can that be handled in > some kind of legacy file for the N900 which calls save_atags() on it, so > we don't end up introducing yet more stuff that we have to maintain into > the distant future? If not, what about copying a known working atag > structure into a legacy file for the N900? > > It seems to me that patches 1, 2, 4, and 5 could be replaced by this > approach. Hi Frank, in this case I will ask my question again: It is possible to read atags from that legacy file. And if yes how? I was not thinking about this approach because somebody in past wrote that this is not possible... -- Pali Rohár pali.ro...@gmail.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf tools: Always give options even it not compiled
On 2015/11/26 16:05, Wangnan (F) wrote:
On 2015/11/20 18:54, 平松雅巳 / HIRAMATU，MASAMI wrote:
From: Wang Nan [mailto:wangn...@huawei.com]
This patch keeps options of perf builtins same in all condition. If the
option is disabled because of compiling options, users should be
notified.
This patch does it by introducing a series of new option macros, flags
and field in struct options. For those options disabled by compiling,
OPT_NOTBUILT_NOARG, OPT_NOTBUILT_OPTARG and OPT_NOTBUILT can be used
to record the help messages and the reason why not built them.
Options in 'perf record' and 'perf probe' are fixed by those new
macros.
Hmm, OK, I agree the reason why this is useful. Could you reconsider
the implementation, because just cloning the code is ugly and not
maintainable?
It will be better if we can replace OPT_BOOLEAN with;
OPT_DEPENDS(HAVE_DWARF_SUPPORT, BOOLEAN, '\0', "no-inlines",
&probe_conf.no_inlines, ...
This may be done by following macros ;
#define OPTMSG_HAVE_DWARF_SUPPORT "NO_DWARF"
#ifdef HAVE_DWARF_SUPPORT
#define OPTVAL_HAVE_DWARF_SUPPORT 1
#else
#define OPTVAL_HAVE_DWARF_SUPPORT 0
#endif
#define __OPT_DEPENDS(val, msg, opt, ...)\
{.type = OPTION_NEXT_DEPENDS, .value = (void *)val, .data = msg,
}, opt(__VA_ARGS__)
#define _OPT_DEPENDS(val, msg, opt, ...)\
__OPT_DEPENDS(val, msg, opt, __VA_ARGS__)
#define OPT_DEPENDS(flag, opt, ...)\
_OPT_DEPENDS(OPTVAL_ ## flag, OPTMSG_ ## flag, OPT_ ## opt,
__VA_ARGS__)
And if the parser find OPTION_NEXT_DEPENDS and .value != NULL, it
skips next entry.
That would be good, but don't forget we have a options__order() which
reorder the options array. To archive our goal I think we must preprocess
the options array to 'merge' information in the OPTION_NEXT_DEPENDS into
the real option it decorates.
Doing such merging in parse_options_subcommand() is natually but require
removing all
'const' decorators from struct options. Too much code changing for such
a small
feature...
Will think another solution...
Thank you.
Thank you,
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 0/7] perf/core improvements and fixes
On Thu, Nov 26, 2015 at 09:12:37AM +0100, Ingo Molnar wrote:
SNIP
> fixdep: error opening depfile: ./.plugin_hrtimer.o.d: No such file or
> directory
> /home/mingo/tip/tools/build/Makefile.build:77: recipe for target
> 'plugin_hrtimer.o' failed
> make[3]: *** [plugin_hrtimer.o] Error 2
> Makefile:189: recipe for target 'plugin_hrtimer-in.o' failed
> make[2]: *** [plugin_hrtimer-in.o] Error 2
> Makefile.perf:414: recipe for target 'libtraceevent_plugins' failed
> make[1]: *** [libtraceevent_plugins] Error 2
> make[1]: *** Waiting for unfinished jobs
> CC plugin_kvm.o
> CC builtin-sched.o
> CC plugin_mac80211.o
> LD plugin_kmem-in.o
> CC util/help.o
>
> Can you reproduce it by adding 'sleep 1' (or 'sleep 2') to the end of
> util/PERF-VERSION-GEN? (See the patch attached further below.)
>
> The failure is sporadic even with the 'sleep 1' hack - I get a build failure
> 1 out
> of 3 times maybe:
>
> triton:~/tip/tools/perf> while : ; do echo -n "$(date) "; make clean install
> >/tmp/FAIL.log 2>&1 && echo pass || { echo 'FAIL!'; break; } done
> Thu Nov 26 09:07:12 CET 2015 pass
> Thu Nov 26 09:07:23 CET 2015 FAIL!
>
> Interestingly it does not reproduce if I use '>FAIL.log' - I need to output
> the
> log into tmpfs - maybe the extra VFS synchronization if logging to the same
> filesystem where the build occurs hides the race?
>
> With V=1 it takes a lot longer to reproduce:
>
> triton:~/tip/tools/perf> while : ; do echo -n "$(date) "; make clean install
> V=1 >/tmp/FAIL.log 2>&1 && echo pass || { echo 'FAIL!'; break; } done
> Thu Nov 26 09:08:08 CET 2015 pass
> Thu Nov 26 09:08:20 CET 2015 pass
> Thu Nov 26 09:08:32 CET 2015 pass
> Thu Nov 26 09:08:43 CET 2015 pass
> Thu Nov 26 09:08:55 CET 2015 pass
> Thu Nov 26 09:09:06 CET 2015 pass
> Thu Nov 26 09:09:17 CET 2015 pass
> Thu Nov 26 09:09:29 CET 2015 pass
> Thu Nov 26 09:09:41 CET 2015 FAIL!
so far no luck on my side.. from quick check over the fail log
it seems the patch I sent yesterday could help:
http://lkml.iu.edu/hypermail/linux/kernel/1511.3/00186.html
I'll have more detailed check on your fail log,
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH][v7] x86, suspend: Save/restore extra MSR registers for suspend
* Chen Yu wrote:
> A bug was reported that on certain Broadwell platforms, after resuming from
> S3,
> the CPU is running at an anomalously low speed.
>
> It turns out that the BIOS has modified the value of the THERM_CONTROL
> register
> during S3, and changed it from 0 to 0x10, thus enabled clock modulation(bit4),
> but with undefined CPU Duty Cycle(bit1:3) - which causes the problem.
>
> Here is a simple scenario to reproduce the issue:
>
> 1. Boot up the system
> 2. Get MSR 0x19a, it should be 0
> 3. Put the system into sleep, then wake it up
> 4. Get MSR 0x19a, it shows 0x10, while it should be 0
>
> Although some BIOSen want to change the CPU Duty Cycle during S3, in our case
> we
> don't want the BIOS to do any modification.
>
> Fix this issue by introducing a more generic x86 framework to save/restore
> specified MSR registers(THERM_CONTROL in this case) for suspend/resume. This
> allows us to fix similar bugs in a much simpler way in the future.
>
> When the kernel wants to protect certain MSRs during suspending, we simply
> add a
> quirk entry in msr_save_dmi_table, and customize the MSR registers inside the
> quirk callback, for example:
>
> u32 msr_id_need_to_save[] = {MSR_ID0, MSR_ID1, MSR_ID2...};
>
> and the quirk mechanism ensures that, once resumed from suspend, the MSRs
> indicated by these IDs will be restored to their original, pre-suspend values.
>
> Since both 64-bit and 32-bit kernels are affected, this patch covers the
> common
> 64/32-bit suspend/resume code path. And because the MSRs specified by the user
> might not be available or readable in any situation, we use rdmsrl_safe() to
> safely save these MSRs.
>
> Reported-and-tested-by: Marcin Kaszewski
> Acked-by: Rafael J. Wysocki
> Acked-by: Pavel Machek
> Signed-off-by: Chen Yu
> ---
> v7:
> - Use the improved version of changelog, and
>modify the patch according to:
>https://patchwork.kernel.org/patch/7637861/
> ---
> arch/x86/include/asm/msr.h| 10 +
> arch/x86/include/asm/suspend_32.h | 1 +
> arch/x86/include/asm/suspend_64.h | 1 +
> arch/x86/power/cpu.c | 94
> +++
> 4 files changed, 106 insertions(+)
Ok, this version looks mostly good - I've applied it with some other minor
edits
to field and variable naming. Please double check the end result that you'll
see
in the tip-bot notification email once I've pushed it out after some testing.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms
On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote: > On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones wrote: > > ST's platforms often have multiple co-processors (usually ST40s or ST231s) > > on-board. This provides the Linux-side infrastructure to flash and boot > > them successfully. > > > > This set has been tested on an STiH410-B2120. > > It would be nice if you could get at least one Reviewed-by tag coming > outside of ST (e.g., Suman or Bjorn who are actively using and > improving remoteproc). If you require reviews by these guys, shouldn't they be Maintainers? > > arch/arm/boot/dts/stih407-family.dtsi | 70 + > > Since this is outside of remoteproc, please have it Acked, preferably > by ARM DT maintainer (Olof?). The bindings have already been Acked by Rob. So long as the DTS(I) files conform to them, there should be no issue. Please be aware that the DTS(I) changes are applied to this set for your information only and are not to be applied through the RemoteProc tree. The usual process to which we conform is that Maxime (the STi Maintainer) will apply the DT changes *after* the main driver has been applied, in this case by you. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/2] leds: rt5033: Add RT5033 Flash led device driver
On Wed, 25 Nov 2015, Ingi Kim wrote:
> This patch adds device driver of Richtek RT5033 PMIC.
> The RT5033 Flash LED Circuit is designed for one or two LEDs driving
> for torch and strobe applications, it provides an I2C software command
> to trigger the torch and strobe operation.
>
> Each of LED outputs can contorl a separate LED sharing their setting,
> and can be connected together for a single connected LED.
> One LED is represented by one child node.
>
> Signed-off-by: Ingi Kim
> ---
> drivers/leds/Kconfig | 8 +
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-rt5033.c | 541
> +
> include/linux/mfd/rt5033-private.h | 51
Acked-by: Lee Jones
> 4 files changed, 601 insertions(+)
> create mode 100644 drivers/leds/leds-rt5033.c
>
> diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
> index b1ab8bd..f41ac9b 100644
> --- a/drivers/leds/Kconfig
> +++ b/drivers/leds/Kconfig
> @@ -345,6 +345,14 @@ config LEDS_PCA963X
> LED driver chip accessed via the I2C bus. Supported
> devices include PCA9633 and PCA9634
>
> +config LEDS_RT5033
> + tristate "LED support for RT5033 PMIC"
> + depends on LEDS_CLASS_FLASH && OF
> + depends on MFD_RT5033
> + help
> + This option enables support for on-chip LED driver on
> + RT5033 PMIC.
> +
> config LEDS_WM831X_STATUS
> tristate "LED support for status LEDs on WM831x PMICs"
> depends on LEDS_CLASS
> diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
> index e9d53092..77cfad5 100644
> --- a/drivers/leds/Makefile
> +++ b/drivers/leds/Makefile
> @@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE) +=
> leds-cobalt-qube.o
> obj-$(CONFIG_LEDS_COBALT_RAQ)+= leds-cobalt-raq.o
> obj-$(CONFIG_LEDS_SUNFIRE) += leds-sunfire.o
> obj-$(CONFIG_LEDS_PCA9532) += leds-pca9532.o
> +obj-$(CONFIG_LEDS_RT5033)+= leds-rt5033.o
> obj-$(CONFIG_LEDS_GPIO_REGISTER) += leds-gpio-register.o
> obj-$(CONFIG_LEDS_GPIO) += leds-gpio.o
> obj-$(CONFIG_LEDS_LP3944)+= leds-lp3944.o
> diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
> new file mode 100644
> index 000..256df74
> --- /dev/null
> +++ b/drivers/leds/leds-rt5033.c
> @@ -0,0 +1,541 @@
> +/*
> + * led driver for RT5033
> + *
> + * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
> + * Ingi Kim
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define RT5033_LED_FLASH_TIMEOUT_MIN 64000
> +#define RT5033_LED_FLASH_TIMEOUT_STEP32000
> +#define RT5033_LED_FLASH_BRIGHTNESS_MIN 5
> +#define RT5033_LED_FLASH_BRIGHTNESS_MAX_1CH 60
> +#define RT5033_LED_FLASH_BRIGHTNESS_MAX_2CH 80
> +#define RT5033_LED_FLASH_BRIGHTNESS_STEP 25000
> +#define RT5033_LED_TORCH_BRIGHTNESS_MIN 12500
> +#define RT5033_LED_TORCH_BRIGHTNESS_STEP 12500
> +
> +#define FLED1_IOUT (BIT(0))
> +#define FLED2_IOUT (BIT(1))
> +
> +enum rt5033_fled {
> + FLED1,
> + FLED2,
> +};
> +
> +struct rt5033_sub_led {
> + enum rt5033_fled fled_id;
> + struct led_classdev_flash fled_cdev;
> +
> + u32 flash_brightness;
> + u32 flash_timeout;
> +};
> +
> +/* RT5033 Flash led platform data */
> +struct rt5033_led {
> + struct device *dev;
> + struct mutex lock;
> + struct regmap *regmap;
> + struct rt5033_sub_led sub_leds[2];
> +
> + u32 current_flash_timeout;
> + u32 current_flash_brightness;
> +
> + bool iout_joint;
> + u8 fled_mask;
> + u8 current_iout;
> +};
> +
> +struct rt5033_led_config_data {
> + const char *label[2];
> + u32 flash_max_microamp[2];
> + u32 flash_max_timeout[2];
> + u32 torch_max_microamp[2];
> + u32 num_leds;
> +};
> +
> +static u8 rt5033_torch_brightness_to_reg(u32 ua)
> +{
> + return (ua - RT5033_LED_TORCH_BRIGHTNESS_MIN) /
> + RT5033_LED_TORCH_BRIGHTNESS_STEP;
> +}
> +
> +static u8 rt5033_flash_brightness_to_reg(u32 ua)
> +{
> + return (ua - RT5033_LED_FLASH_BRIGHTNESS_MIN) /
> + RT5033_LED_FLASH_BRIGHTNESS_STEP;
> +}
> +
> +static u8 rt5033_flash_timeout_to_reg(u32 us)
> +{
> + return (us - RT5033_LED_FLASH_TIMEOUT_MIN) /
> + RT5033_LED_FLASH_TIMEOUT_STEP;
> +}
> +
> +static struct rt5033_sub_led *flcdev_to_sub_led(
> + struct led_classdev_flash *fled_cdev)
> +{
> + return container_of(fled_cdev, struct rt5033_sub_led, fled_cdev);
> +}
> +
> +static struct rt5033_led *sub_led_to_led(struct rt5033_sub_led *sub_led)
> +{
> + return container_of(sub_led, struct rt5033_led,
> +
Re: [PATCH] x86: mm: clean up probe_memory_block_size()
* Seth Jennings wrote:
> The cumulative effect of bdee237c and 982792c7 is some pretty convoluted
> code. This commit has no (intended) functional change; just seeks to
> simplify and make the code more understandable.
>
> The whole section with the "tail size" doesn't seem to be reachable,
> since both the >= 64GB and < 64GB case return, so it was removed.
>
> This commit also adds code back for the UV case since it seemed to just
> go away without reason in bdee237c and might lead to unexpected change
> in behavior.
>
> Signed-off-by: Seth Jennings
> ---
> arch/x86/mm/init_64.c | 22 ++
> 1 file changed, 6 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
> index ec081fe..a83c470 100644
> --- a/arch/x86/mm/init_64.c
> +++ b/arch/x86/mm/init_64.c
> @@ -52,6 +52,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "mm_internal.h"
> @@ -1194,26 +1195,15 @@ int kern_addr_valid(unsigned long addr)
>
> static unsigned long probe_memory_block_size(void)
> {
> + unsigned long bz = MIN_MEMORY_BLOCK_SIZE;
>
> + /* if system is UV or has 64GB of RAM or more, use large blocks */
> + if (is_uv_system() || ((max_pfn << PAGE_SHIFT) >= (64UL << 30))) {
> pr_info("Using 2GB memory block size for large-memory
> system\n");
> + bz = 2UL << 30; /* 2GB */
> }
>
> + pr_debug("memory block size : %ldMB\n", bz >> 20);
>
> return bz;
> }
So why keep 'bz' at all? Just return with the right value and be done with it.
'bz' is just an unnecessary confusion factor.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/2] leds: rt5033: Add RT5033 Flash led device driver
On Thu, 26 Nov 2015, Ingi Kim wrote:
> On 2015년 11월 26일 00:13, Jacek Anaszewski wrote:
> > Hi Ingi,
> >
> > Thanks for the update.
> >
> > On 11/25/2015 11:22 AM, Ingi Kim wrote:
> >> This patch adds device driver of Richtek RT5033 PMIC.
> >> The RT5033 Flash LED Circuit is designed for one or two LEDs driving
> >> for torch and strobe applications, it provides an I2C software command
> >> to trigger the torch and strobe operation.
> >>
> >> Each of LED outputs can contorl a separate LED sharing their setting,
> >
> > s/contorl/control/
> >
>
> Oh, I see, Thanks
>
> >> and can be connected together for a single connected LED.
> >> One LED is represented by one child node.
> >>
> >> Signed-off-by: Ingi Kim
> >> ---
> >> drivers/leds/Kconfig | 8 +
> >> drivers/leds/Makefile | 1 +
> >> drivers/leds/leds-rt5033.c | 541
> >> +
> >> include/linux/mfd/rt5033-private.h | 51
> >> 4 files changed, 601 insertions(+)
> >> create mode 100644 drivers/leds/leds-rt5033.c
[...]
> >> diff --git a/include/linux/mfd/rt5033-private.h
> >> b/include/linux/mfd/rt5033-private.h
> >> index 1b63fc2..b20c7e4 100644
> >> --- a/include/linux/mfd/rt5033-private.h
> >> +++ b/include/linux/mfd/rt5033-private.h
> >> @@ -93,6 +93,57 @@ enum rt5033_reg {
> >> #define RT5033_RT_CTRL1_UUG_MASK0x02
> >> #define RT5033_RT_HZ_MASK0x01
> >>
> >> +/* RT5033 FLED Function1 register */
> >> +#define RT5033_FLED_FUNC1_MASK0x97
> >
> > Bitmask should define group of bits that control single
> > functionality. There is no point in defining a bit mask
> > for the whole register width.
> >
>
> Thanks, I'll remove it.
>
> >> +#define RT5033_FLED_EN_LEDCS10x01
> >> +#define RT5033_FLED_EN_LEDCS20x02
> >> +#define RT5033_FLED_STRB_SEL0x04
> >> +#define RT5033_FLED_PINCTRL0x10
> >> +#define RT5033_FLED_RESET0x80
> >> +
> >> +/* RT5033 FLED Function2 register */
> >> +#define RT5033_FLED_FUNC2_MASK0x81
> >
> > Ditto.
> >
>
> Thanks,
>
> >> +#define RT5033_FLED_ENFLED0x01
> >> +#define RT5033_FLED_SREG_STRB0x80
> >> +
> >> +/* RT5033 FLED Strobe Control1 */
> >> +#define RT5033_FLED_STRBCTRL1_MASK0xFF
> >
> > Ditto.
> >
>
> Thanks,
>
> >> +#define RT5033_FLED_STRBCTRL1_TM_CUR_MAX0xE0
> >> +#define RT5033_FLED_STRBCTRL1_FL_CUR_DEF0x0D
> >> +#define RT5033_FLED_STRBCTRL1_FL_CUR_MAX0x1F
> >
> > Don't mix value constraints with bitmask .
> > You don't use above MAX and DEF macros in the driver, but
> > instead you define following set of macros in leds-rt5033.c:
> >
> > #define RT5033_LED_FLASH_TIMEOUT_MIN64000
> > #define RT5033_LED_FLASH_TIMEOUT_STEP 32000
> > #define RT5033_LED_FLASH_BRIGHTNESS_MIN 5
> > #define RT5033_LED_FLASH_BRIGHTNESS_MAX_1CH 60
> > #define RT5033_LED_FLASH_BRIGHTNESS_MAX_2CH 80
> > #define RT5033_LED_FLASH_BRIGHTNESS_STEP25000
> > #define RT5033_LED_TORCH_BRIGHTNESS_MIN 12500
> > #define RT5033_LED_TORCH_BRIGHTNESS_STEP12500
> >
> > These can be moved to this file, but below bit field
> > definitions.
> >
> > Besides, you could add bitmasks for "Timeout Current Level"
> > adn "Fled Strobe Current" bitfields, that are documented
> > for this register.
> >
>
> Thanks, I understand.
> I'll change it
>
> >> +
> >> +/* RT5033 FLED Strobe Control2 */
> >> +#define RT5033_FLED_STRBCTRL2_MASK0x3F
> >> +#define RT5033_FLED_STRBCTRL2_TM_DEF0x0F
> >> +#define RT5033_FLED_STRBCTRL2_TM_MAX0x3F
> >
> > Insted of the above three please just add bitmask definition for the
> > "FLED Strobe Timeout" bits.
> >
>
> Thanks, I'll change it
>
> >> +/* RT5033 FLED Control1 */
> >> +#define RT5033_FLED_CTRL1_MASK0xF7
> >> +#define RT5033_FLED_CTRL1_TORCH_CUR_DEF0x20
> >> +#define RT5033_FLED_CTRL1_TORCH_CUR_MAX0xF0
> >> +#define RT5033_FLED_CTRL1_LBP_DEF0x02
> >> +#define RT5033_FLED_CTRL1_LBP_MAX0x07
> >
> > Similarly, just add bitmask definitions for "FLED Torch Current"
> > and "LPB".
> >
>
> Thanks, I'll change it
>
> >> +/* RT5033 FLED Control2 */
> >> +#define RT5033_FLED_CTRL2_MASK0xFF
> >
> > This bitmask is useless.
> >
>
> Thanks,
>
> >> +#define RT5033_FLED_CTRL2_VMID_DEF0x37
> >
> > Please remove this.
> >
>
> Thanks,
>
> >> +#define RT5033_FLED_CTRL2_VMID_MAX0x3F
> >
> > Rename MAX to MASK.
> >
>
> Thanks, I'll change it.
>
> >> +#define RT5033_FLED_CTRL2_TRACK_ALIVE0x40
> >> +#define RT5033_FLED_CTRL2_MID_TRACK0x80
> >> +
> >> +/* RT5033 FLED Control4 */
> >> +#define RT5033_FLED_CTRL4_MASK0xE0
> >> +#define RT5033_FLED_CTRL4_RESV0x14
> >> +#define RT5033_FLED_CTRL4_VTRREG_DEF0x40
> >
> > Above three are useless.
> >
>
> Thanks,
>
> >> +#define RT5033_FLED_CTRL4_VTRREG_MAX0x60
> >
> > Rename DEF to MASK.
> >
>
> Thanks,
>
> >> +#define
Re: [PATCH v3] mfd: cros ec: Lock the SPI bus while holding chipselect
On Wed, 25 Nov 2015, Nicolas Boichat wrote:
> cros_ec_cmd_xfer_spi and cros_ec_pkt_xfer_spi generally work like
> this:
> - Pull CS down (active), wait a bit, then send a command
> - Wait for response (multiple requests)
> - Wait a while, pull CS up (inactive)
>
> These operations, individually, lock the SPI bus, but there is
> nothing preventing the SPI framework from interleaving messages
> intended for other devices as the bus is unlocked in between.
>
> This is a problem as the EC expects CS to be held low for the
> whole duration.
>
> Solution: Lock the SPI bus during the whole transaction, to make
> sure that no other messages can be interleaved.
>
> Signed-off-by: Nicolas Boichat
> ---
>
> v2: Move bus_unlock earlier in the functions.
> v3: Remove comments.
>
> Applies on top on linux-next/master (20151124)
>
> drivers/mfd/cros_ec_spi.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c
> index 6a0f6ec..d6af52d 100644
> --- a/drivers/mfd/cros_ec_spi.c
> +++ b/drivers/mfd/cros_ec_spi.c
> @@ -113,7 +113,7 @@ static int terminate_request(struct cros_ec_device
> *ec_dev)
> trans.delay_usecs = ec_spi->end_of_msg_delay;
> spi_message_add_tail(&trans, &msg);
>
> - ret = spi_sync(ec_spi->spi, &msg);
> + ret = spi_sync_locked(ec_spi->spi, &msg);
>
> /* Reset end-of-response timer */
> ec_spi->last_transfer_ns = ktime_get_ns();
> @@ -147,7 +147,7 @@ static int receive_n_bytes(struct cros_ec_device *ec_dev,
> u8 *buf, int n)
>
> spi_message_init(&msg);
> spi_message_add_tail(&trans, &msg);
> - ret = spi_sync(ec_spi->spi, &msg);
> + ret = spi_sync_locked(ec_spi->spi, &msg);
> if (ret < 0)
> dev_err(ec_dev->dev, "spi transfer failed: %d\n", ret);
>
> @@ -391,10 +391,10 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device
> *ec_dev,
> }
>
> rx_buf = kzalloc(len, GFP_KERNEL);
> - if (!rx_buf) {
> - ret = -ENOMEM;
> - goto exit;
> - }
> + if (!rx_buf)
> + return -ENOMEM;
> +
> + spi_bus_lock(ec_spi->spi->master);
>
> /*
>* Leave a gap between CS assertion and clocking of data to allow the
> @@ -414,7 +414,7 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device
> *ec_dev,
> trans.len = len;
> trans.cs_change = 1;
> spi_message_add_tail(&trans, &msg);
> - ret = spi_sync(ec_spi->spi, &msg);
> + ret = spi_sync_locked(ec_spi->spi, &msg);
>
> /* Get the response */
> if (!ret) {
> @@ -440,6 +440,9 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device
> *ec_dev,
> }
>
> final_ret = terminate_request(ec_dev);
> +
> + spi_bus_unlock(ec_spi->spi->master);
> +
> if (!ret)
> ret = final_ret;
> if (ret < 0)
> @@ -520,10 +523,10 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
> *ec_dev,
> }
>
> rx_buf = kzalloc(len, GFP_KERNEL);
> - if (!rx_buf) {
> - ret = -ENOMEM;
> - goto exit;
> - }
> + if (!rx_buf)
> + return -ENOMEM;
> +
> + spi_bus_lock(ec_spi->spi->master);
>
> /* Transmit phase - send our message */
> debug_packet(ec_dev->dev, "out", ec_dev->dout, len);
> @@ -534,7 +537,7 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
> *ec_dev,
> trans.cs_change = 1;
> spi_message_init(&msg);
> spi_message_add_tail(&trans, &msg);
> - ret = spi_sync(ec_spi->spi, &msg);
> + ret = spi_sync_locked(ec_spi->spi, &msg);
>
> /* Get the response */
> if (!ret) {
> @@ -560,6 +563,9 @@ static int cros_ec_cmd_xfer_spi(struct cros_ec_device
> *ec_dev,
> }
>
> final_ret = terminate_request(ec_dev);
> +
> + spi_bus_unlock(ec_spi->spi->master);
> +
> if (!ret)
> ret = final_ret;
> if (ret < 0)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf record: Add snapshot mode support for perf's regular events
* Wangnan (F) wrote: > > > On 2015/11/25 20:20, Peter Zijlstra wrote: > >On Wed, Nov 25, 2015 at 05:44:00PM +0800, Wangnan (F) wrote: > >> > >>On 2015/11/25 17:27, Peter Zijlstra wrote: > >>>On Tue, Nov 24, 2015 at 10:00:31PM +0800, Yunlong Song wrote: > In our patch, we create and maintain a user space ring buffer to store > perf's tracing info, instead of directly writing to perf.data file as > before. In snapshot mode, only a SIGUSR2 signal can trigger perf to dump > the tracing info currently stored in the user space ring buffer to > perf.data file. > >>>I would very much like to first fix the perf overwrite mode: see > >>>lkml.kernel.org/r/20151023151205.gw11...@twins.programming.kicks-ass.net > >>I think they can be done in parallel. We can first do something with > >>tracking events and perf's output file, and wait for kernel level > >>overwrite mode fixed, then decide whether to implement perf's own > >>ringbuffer. > >That seems backwards; why would you ever want to endlessly copy the > >events if you're not going to use them? > > I agree that we need to fixing overwrite mode. However, user space ringbuffer > can be more flexible. for example, dynamically shrinking and expansion. It > would > be hard in kernel I think, and I'm not sure how much flexibility we need. > Doing > things in kernel always more difficult than in userspace. > > But yes, we can do that userspace ring buffer when we really need it. At very > first we can start working on perf side and assume overwrite mode is ready. I don't think Peter asked for much: pick up the patch he has already written and use it, to have an even lower overhead always-enabled background tracing mode of perf. Resizing shouldn't be much of an issue with existing features: if events start overflowing or some other threshold for dynamic increase of the ring-buffer is met then the daemon should open a new set of events with a larger ring-buffer, and close the old events once the new tracing ring-buffer is up and running. Use event multiplexing to output all interesting events into the same single (per CPU) ring-buffer. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 0/1] ioctl to disallow detaching kernel USB drivers
On 11/25/2015 04:45 PM, Emilio López wrote: Hi everyone, This patch introduces a new ioctl, USBDEVFS_DROP_PRIVILEGES, to voluntarily forgo the ability to issue ioctls which may interfere with other users of the USB device. This feature allows a privileged process (in the case of Chrome OS, permission_broker) to open a USB device node and then drop a number of capabilities that are considered "privileged". We had the same idea in Tizen but for now we didn't have time to implement it. These privileges include the ability to reset the device if there are other users (most notably a kernel driver) or to disconnect a kernel driver from the device. The file descriptor can then be passed to an unprivileged process. And how about switching configuration? This can be also harmful even if the are no other users for any interface in this configuration. (Just imagine the situation in which only second config contains an HID function and when app switch configuration it is activated without user knowing about this;)) This is useful for granting a process access to a device with multiple functions. It won't be able to use its access to one function to disrupt or take over control of another function. I run through your code and as far as I understand above is not exactly true. Your patch allows only to prevent userspace from accessing interfaces which has kernel drivers, there is no way to stop an application from taking control over all free interfaces. Let's say that your device has 3 interfaces. First of them has a kernel driver but second and third doesn't. You have 2 apps. One should communicate using second interface and another one third. But first app is malicious and it claims all free interfaces of received device (your patch doesn't prevent this). And when second app starts it is unable to do anything with the device because all interfaces are taken. How would you like to handle this? Moreover I'm not convinced to this patch as it hardcodes the *policy* in kernel code. Generally our approach (with passing fd from broker to unprivileged process) was similar but we found out that if we would like to do this correctly there is much more things to filter than in this patch. We had two main ideas: - implement some LSM hooks in ioctls() but this leads to a lot of additional callbacks in lsm ops struct which even now is very big. But as a benefit we would get a very flexible policy consistent with other system policies - split single usb device node into multiple files which could represent single endpoins only for io and separate control file for privileged but it's quite a lot of work and I don't know if any one is going to accept such a change Best regards, -- Krzysztof Opasiak Samsung R&D Institute Poland Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] usb: devio: Add ioctl to disallow detaching kernel USB drivers.
On Thu, Nov 26, 2015 at 04:59:25PM +0800, Peter Chen wrote:
> On Wed, Nov 25, 2015 at 12:45:34PM -0300, Emilio López wrote:
> > From: Reilly Grant
> >
> > The new USBDEVFS_DROP_PRIVILEGES ioctl allows a process to voluntarily
> > relinquish the ability to issue other ioctls that may interfere with
> > other processes and drivers that have claimed an interface on the
> > device.
> >
> > Signed-off-by: Reilly Grant
> > Reviewed-by: Jorge Lucangeli Obes
> > Reviewed-by: Kees Cook
> > [emilio.lopez: fix build for v4.4-rc2 and adjust patch title prefix]
> > Signed-off-by: Emilio López
> >
> > ---
> >
> > drivers/usb/core/devio.c | 50
> > +++
> > include/uapi/linux/usbdevice_fs.h | 1 +
> > 2 files changed, 47 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/usb/core/devio.c b/drivers/usb/core/devio.c
> > index 38ae877c..a5ccc50 100644
> > --- a/drivers/usb/core/devio.c
> > +++ b/drivers/usb/core/devio.c
> > @@ -77,6 +77,7 @@ struct usb_dev_state {
> > unsigned long ifclaimed;
> > u32 secid;
> > u32 disabled_bulk_eps;
> > + bool privileges_dropped;
> > };
> >
> > struct async {
> > @@ -878,7 +879,7 @@ static int usbdev_open(struct inode *inode, struct file
> > *file)
> > int ret;
> >
> > ret = -ENOMEM;
> > - ps = kmalloc(sizeof(struct usb_dev_state), GFP_KERNEL);
> > + ps = kzalloc(sizeof(struct usb_dev_state), GFP_KERNEL);
> > if (!ps)
> > goto out_free_ps;
> >
> > @@ -911,11 +912,8 @@ static int usbdev_open(struct inode *inode, struct
> > file *file)
> > INIT_LIST_HEAD(&ps->async_pending);
> > INIT_LIST_HEAD(&ps->async_completed);
> > init_waitqueue_head(&ps->wait);
> > - ps->discsignr = 0;
> > ps->disc_pid = get_pid(task_pid(current));
> > ps->cred = get_current_cred();
> > - ps->disccontext = NULL;
> > - ps->ifclaimed = 0;
>
> The above changes seem to be not related with this change.
>
It is though. They added a new struct member and thought that now it
was cleaner to use kzalloc() instead of initializing the new member to
zero.
> > security_task_getsecid(current, &ps->secid);
> > smp_wmb();
> > list_add_tail(&ps->list, &dev->filelist);
> > @@ -1215,6 +1213,35 @@ static int proc_connectinfo(struct usb_dev_state
> > *ps, void __user *arg)
> >
> > static int proc_resetdevice(struct usb_dev_state *ps)
> > {
> > + if (ps->privileges_dropped) {
> > + struct usb_host_config *actconfig = ps->dev->actconfig;
> > +
> > + /* Don't touch the device if any interfaces are claimed. It
> > +* could interfere with other drivers' operations and this
> > +* process has dropped its privileges to do such things.
> > +*/
> > + if (actconfig) {
> > + int i;
> > +
> > + for (i = 0; i < actconfig->desc.bNumInterfaces; ++i) {
> > + if (usb_interface_claimed(
> > + actconfig->interface[i])) {
> > + dev_warn(&ps->dev->dev,
> > + "usbfs: interface %d claimed by"
> > + " %s while '%s'"
> > + " resets device\n",
> > + actconfig->interface[i]
> > + ->cur_altsetting
> > + ->desc.bInterfaceNumber,
>
> The length of line is 80 characters
>
> > + actconfig->interface[i]
> > + ->dev.driver->name,
> > + current->comm);
> > + return -EACCES;
> > + }
> > + }
> > + }
> > + }
Yeah. Better to flip this around:
static int proc_resetdevice(struct usb_dev_state *ps)
{
struct usb_host_config *actconfig = ps->dev->actconfig;
struct usb_interface *interface;
int i;
if (ps->privileges_dropped && actconfig) {
for (i = 0; i < actconfig->desc.bNumInterfaces; ++i) {
interface = actconfig->interface[i];
if (usb_interface_claimed(interface)) {
dev_warn(&ps->dev->dev,
"usbfs: interface %d claimed by %s
while '%s' resets device\n",
interface->cur_altsetting->desc.bInterfaceNumber,
interface->dev.driver->name,
current->comm);
return -EACCES;
}
}
}
return usb_reset_device(ps->dev);
}
It still goes over the 80 character limit, but that's cleaner
Re: QUEUE_FLAG_NO_SG_MERGE and non-block-mq
On Thu, Nov 26, 2015 at 4:13 PM, Hannes Reinecke wrote: > Hi all, > > while investigating the crash in scsi_lib.c I found a rather curious > behaviour for QUEUE_FLAG_NO_SG_MERGE. > > While the flag is evaluated in blk_recalc_rq_segments and > blk_recount_segments (resulting in nr_phys_segments being > computed based on that flag) it is completely ignored > during blk_rq_map_sg() or the actual merging itself. Yes, I guess Jens introduced the flag for decreasing CPU consumption when comuputing segments, but it is still ignored by blk_rq_map_sg(), but it may not be used by some drivers. After bio splitting is introduced, the flag is also ignored when computing segments. > > This typically shouldn't be an issue, seeing that with > QUEUE_FLAG_NO_SG_MERGE nr_phys_segments will always be > larger than the actual segment count. > > However, it still makes me wonder: > What is the point of having a QUEUE_FLAG_NO_SG_MERGE > which doesn't work as advertised? > Or, to be precise, which only works for blk-mq? > Should we make it work for non-block-mq, too? Thanks bio splitting, this flag has little effect on performance now, so I think it can be removed if Jens has no objection. Thanks, > > > Cheers, > > Hannes > -- > Dr. Hannes ReineckezSeries & Storage > h...@suse.de +49 911 74053 688 > SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg > GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton > HRB 21284 (AG Nürnberg) > -- > To unsubscribe from this list: send the line "unsubscribe linux-scsi" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf record: Add snapshot mode support for perf's regular events
On 2015/11/26 17:19, Ingo Molnar wrote: * Wangnan (F) wrote: On 2015/11/25 20:20, Peter Zijlstra wrote: On Wed, Nov 25, 2015 at 05:44:00PM +0800, Wangnan (F) wrote: On 2015/11/25 17:27, Peter Zijlstra wrote: On Tue, Nov 24, 2015 at 10:00:31PM +0800, Yunlong Song wrote: In our patch, we create and maintain a user space ring buffer to store perf's tracing info, instead of directly writing to perf.data file as before. In snapshot mode, only a SIGUSR2 signal can trigger perf to dump the tracing info currently stored in the user space ring buffer to perf.data file. I would very much like to first fix the perf overwrite mode: see lkml.kernel.org/r/20151023151205.gw11...@twins.programming.kicks-ass.net I think they can be done in parallel. We can first do something with tracking events and perf's output file, and wait for kernel level overwrite mode fixed, then decide whether to implement perf's own ringbuffer. That seems backwards; why would you ever want to endlessly copy the events if you're not going to use them? I agree that we need to fixing overwrite mode. However, user space ringbuffer can be more flexible. for example, dynamically shrinking and expansion. It would be hard in kernel I think, and I'm not sure how much flexibility we need. Doing things in kernel always more difficult than in userspace. But yes, we can do that userspace ring buffer when we really need it. At very first we can start working on perf side and assume overwrite mode is ready. I don't think Peter asked for much: pick up the patch he has already written and use it, to have an even lower overhead always-enabled background tracing mode of perf. Resizing shouldn't be much of an issue with existing features: if events start overflowing or some other threshold for dynamic increase of the ring-buffer is met then the daemon should open a new set of events with a larger ring-buffer, and close the old events once the new tracing ring-buffer is up and running. Use event multiplexing to output all interesting events into the same single (per CPU) ring-buffer. Thank you for your reply. We'll start looking Peter's patch and try to find what should we do to make it upstream faster. Could you please kindly give some hints? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] powerpc: tracing: don't trace hcalls on offline CPUs
On Thu, 2015-11-26 at 11:15 +0300, Denis Kirjanov wrote: > On 11/26/15, Michael Ellerman wrote: > > On Tue, 2015-11-24 at 21:23 +0300, Denis Kirjanov wrote: > > I can't get this to hit. > > > > I've got LOCKDEP=y, I've enabled the hcall tracepoints, and then I offline > > a cpu via sysfs. > I haven't tried it via sysfs. Could you share the command > so I give a try to reproduce. Either manually: $ echo 0 > /sys/devices/system/cpuN/online Or using: $ ppc64_cpu --cores-on=1 and/or $ ppc64_cpu --smt=1 Which uses sysfs. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
平时最多也就联系了三千家，全球还有十几万客户在哪里？
您好: 您还在用ali平台开发外贸客户? 还在使用展会宣传企业和产品? 你out了!!! 当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？ 行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？ 加QQ2652697913给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。 广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf record: Add snapshot mode support for perf's regular events
* Ingo Molnar wrote: > > But yes, we can do that userspace ring buffer when we really need it. At > > very > > first we can start working on perf side and assume overwrite mode is ready. > > I don't think Peter asked for much: pick up the patch he has already written > and > use it, to have an even lower overhead always-enabled background tracing mode > of > perf. > > Resizing shouldn't be much of an issue with existing features: if events > start > overflowing or some other threshold for dynamic increase of the ring-buffer > is > met then the daemon should open a new set of events with a larger > ring-buffer, > and close the old events once the new tracing ring-buffer is up and running. > > Use event multiplexing to output all interesting events into the same single > (per CPU) ring-buffer. Btw., there's another trick we could use to support ftrace-alike workflows even better: we could expose a task's active perf ring-buffers under /proc// and could make it readable. So if an overwrite-mode background tracing session is running, you don't even have to signal it to capture the ring-buffer: just open the ring-buffer fd in procfs, under /proc/XYZ/perf/ring-buffers/5.trace or so, and dump its current contents, assuming the task doing that has sufficient permissions - i.e. ptrace_may_access(). We could even pretty-print some very basic version of the records from the kernel, via /proc/XYZ/perf/ring-buffers/5.txt, to support a tooling-less tracing modes. This way perf based tracing could be supported even on systems that have no writable filesystems. I.e. in this regard perf can be made to match ftrace's tracing workflow as well - in addition to the more traditional perf profiling workflow we all love and know! Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms
On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones wrote: > On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote: >> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones wrote: >> > ST's platforms often have multiple co-processors (usually ST40s or ST231s) >> > on-board. This provides the Linux-side infrastructure to flash and boot >> > them successfully. >> > >> > This set has been tested on an STiH410-B2120. >> >> It would be nice if you could get at least one Reviewed-by tag coming >> outside of ST (e.g., Suman or Bjorn who are actively using and >> improving remoteproc). > > If you require reviews by these guys, shouldn't they be Maintainers? Additional review isn't a requirement, but it's a plus. > Please be aware that > the DTS(I) changes are applied to this set for your information only > and are not to be applied through the RemoteProc tree. The usual > process to which we conform is that Maxime (the STi Maintainer) will > apply the DT changes *after* the main driver has been applied, in this > case by you. Ok, great, so I will not take patches 5 and 6. Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mm, oom: Give __GFP_NOFAIL allocations access to memory reserves
On Wed 25-11-15 12:57:08, David Rientjes wrote:
> On Wed, 25 Nov 2015, Michal Hocko wrote:
>
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 8034909faad2..94b04c1e894a 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -2766,8 +2766,13 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int
> > order,
> > goto out;
> > }
> > /* Exhausted what can be done so it's blamo time */
> > - if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL))
> > + if (out_of_memory(&oc) || WARN_ON_ONCE(gfp_mask & __GFP_NOFAIL)) {
> > *did_some_progress = 1;
> > +
> > + if (gfp_mask & __GFP_NOFAIL)
> > + page = get_page_from_freelist(gfp_mask, order,
> > + ALLOC_NO_WATERMARKS, ac);
> > + }
> > out:
> > mutex_unlock(&oom_lock);
> > return page;
>
> Well, sure, that's one way to do it, but for cpuset users, wouldn't this
> lead to a depletion of the first system zone since you've dropped
> ALLOC_CPUSET and are doing ALLOC_NO_WATERMARKS in the same call?
Are you suggesting to do?
if (gfp_mask & __GFP_NOFAIL) {
page = get_page_from_freelist(gfp_mask, order,
ALLOC_NO_WATERMARKS|ALLOC_CPUSET, ac);
/*
* fallback to ignore cpuset if our nodes are
* depleted
*/
if (!page)
get_page_from_freelist(gfp_mask, order,
ALLOC_NO_WATERMARKS, ac);
}
I am not really sure this worth complication. __GFP_NOFAIL should be
relatively rare and nodes are rarely depeleted so much that
ALLOC_NO_WATERMARKS wouldn't be able to allocate from the first zone in
the zone list. I mean I have no problem to do the above it just sounds
overcomplicating the situation without making practical difference.
If you and others insist I can resping the patch though.
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE
A certain deceased customer left behind $ 18 million US in my bank, I seek your partnership to get this fund reply Larr.S -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 38/52] Btrfs: fix race when listing an inode's xattrs
On 11/26/2015 12:39 AM, Ben Hutchings wrote:
> On Wed, 2015-11-25 at 23:11 +, Luis Henriques wrote:
>> On Tue, Nov 24, 2015 at 10:33:59PM +, Ben Hutchings wrote:
>>> 3.2.74-rc1 review patch. If anyone has any objections, please let me know.
>>>
>>> --
>>>
>>> From: Filipe Manana
>>>
>>> commit f1cd1f0b7d1b5d4aaa5711e8f4e4898b0045cb6d upstream.
>>>
>>> When listing a inode's xattrs we have a time window where we race against
>>> a concurrent operation for adding a new hard link for our inode that makes
>>> us not return any xattr to user space. In order for this to happen, the
>>> first xattr of our inode needs to be at slot 0 of a leaf and the previous
>>> leaf must still have room for an inode ref (or extref) item, and this can
>>> happen because an inode's listxattrs callback does not lock the inode's
>>> i_mutex (nor does the VFS does it for us), but adding a hard link to an
>>> inode makes the VFS lock the inode's i_mutex before calling the inode's
>>> link callback.
>>>
>>> If we have the following leafs:
>>>
>>>Leaf X (has N items)Leaf Y
>>>
>>> [ ... (257 INODE_ITEM 0) (257 INODE_REF 256) ] [ (257 XATTR_ITEM 12345),
>>> ... ]
>>>slot N - 2 slot N - 1 slot 0
>>>
>>> The race illustrated by the following sequence diagram is possible:
>>>
>>>CPU 1 CPU 2
>>>
>>> btrfs_listxattr()
>>>
>>> searches for key (257 XATTR_ITEM 0)
>>>
>>> gets path with path->nodes[0] == leaf X
>>> and path->slots[0] == N
>>>
>>> because path->slots[0] is >=
>>> btrfs_header_nritems(leaf X), it calls
>>> btrfs_next_leaf()
>>>
>>> btrfs_next_leaf()
>>> releases the path
>>>
>>>adds key (257 INODE_REF
>>> 666)
>>>to the end of leaf X
>>> (slot N),
>>>and leaf X now has N + 1
>>> items
>>>
>>> searches for the key (257 INODE_REF 256),
>>> with path->keep_locks == 1, because that
>>> is the last key it saw in leaf X before
>>> releasing the path
>>>
>>> ends up at leaf X again and it verifies
>>> that the key (257 INODE_REF 256) is no
>>> longer the last key in leaf X, so it
>>> returns with path->nodes[0] == leaf X
>>> and path->slots[0] == N, pointing to
>>> the new item with key (257 INODE_REF 666)
>>>
>>> btrfs_listxattr's loop iteration sees that
>>> the type of the key pointed by the path is
>>> different from the type BTRFS_XATTR_ITEM_KEY
>>> and so it breaks the loop and stops looking
>>> for more xattr items
>>> --> the application doesn't get any xattr
>>> listed for our inode
>>>
>>> So fix this by breaking the loop only if the key's type is greater than
>>> BTRFS_XATTR_ITEM_KEY and skip the current key if its type is smaller.
>>>
>>> Signed-off-by: Filipe Manana
>>> [bwh: Backported to 3.2: s/found_key\.type/btrfs_key_type(\&found_key)/]
>>
>> Actually, in my backport to 3.16 I decided to keep the usage of
>> 'found_key.type' instead, as the usage of btrfs_key_type() has been
>> dropped with commit 962a298f3511 ("btrfs: kill the key type accessor
>> helpers").
> [...]
>
> OK, that makes sense. btrfs in 3.2 is pretty inconsistent about using
> btrfs_key_type() anyway.
Using the type field directly, instead of the accessor, is perfectly
safe (the field is an u8 so no worries about endianness conversions
unlike, other field of struct btrfs_key which are u64s).
>
> Ben.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] remoteproc: fix memory leak of remoteproc ida cache layers
Hi Suman, On Thu, Sep 17, 2015 at 3:29 AM, Suman Anna wrote: > The remoteproc core uses a static ida named rproc_dev_index for > assigning an automatic index number to a registered remoteproc. > The ida core may allocate some internal idr cache layers and ida > bitmap upon any ida allocation, and all these layers are truely > freed only upon the ida destruction. The rproc_dev_index ida is > not destroyed at present, leading to a memory leak when using the > remoteproc core as a module and atleast one rproc device is > registered and unregistered. > > Fix this by invoking ida_destroy() in the remoteproc core module > exit. I saw there was some discussion about this between Michael, James and Tejun whether this should be fixed in the IDA core or not. Has it been resolved? Thanks, Ohad. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf record: Add snapshot mode support for perf's regular events
* Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > > But yes, we can do that userspace ring buffer when we really need it. At > > > very first we can start working on perf side and assume overwrite mode is > > > ready. > > > > I don't think Peter asked for much: pick up the patch he has already > > written > > and use it, to have an even lower overhead always-enabled background > > tracing > > mode of perf. > > > > Resizing shouldn't be much of an issue with existing features: if events > > start > > overflowing or some other threshold for dynamic increase of the ring-buffer > > is > > met then the daemon should open a new set of events with a larger > > ring-buffer, > > and close the old events once the new tracing ring-buffer is up and running. > > > > Use event multiplexing to output all interesting events into the same > > single > > (per CPU) ring-buffer. > > Btw., there's another trick we could use to support ftrace-alike workflows > even > better: we could expose a task's active perf ring-buffers under /proc// > and > could make it readable. > > So if an overwrite-mode background tracing session is running, you don't even > have to signal it to capture the ring-buffer: just open the ring-buffer fd in > procfs, under /proc/XYZ/perf/ring-buffers/5.trace or so, and dump its current > contents, assuming the task doing that has sufficient permissions - i.e. > ptrace_may_access(). > > We could even pretty-print some very basic version of the records from the > kernel, via /proc/XYZ/perf/ring-buffers/5.txt, to support a tooling-less > tracing > modes. This way perf based tracing could be supported even on systems that > have > no writable filesystems. > > I.e. in this regard perf can be made to match ftrace's tracing workflow as > well > - in addition to the more traditional perf profiling workflow we all love and > know! Also note that if we go in this direction then with some additional changes we could also support lightweight tracing with no tooling side at all on the traced system: a simple kernel feature with a kernel thread could be added that takes a list of events from sysfs or debugfs and opens them system-wide and exposes per-cpu overwrite mode ring-buffers. Those ring-buffers can then be accessed via procfs (and/or also be exposed in parallel via debugfs). The kernel thread never actually does anything except set up the events - i.e. this is a very lightweight mode of always-on tracing. Additional debugfs toggles can be added to temporarily turn tracing on/off without closing the events - just like ftrace. Other toggles could be added, such as: 'stop tracing when the kernel has crashed, or if a specific event has occured or a condition has been met'. That way we could, among other things, capture traces on embedded systems and copy the traces to another, larger system (or NFS-mount the target system), and run perf tooling to analyze the traces on that more powerful system. But it all starts with making overwrite mode work well, and working with the kernel visible ring-buffer. That can then be exposed to user-space in very expressive ways to turn perf into a flexible system tracing subsystem as well. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/2] leds: rt5033: Add RT5033 Flash led device driver
Hi Ingi,
On 11/26/2015 09:02 AM, Ingi Kim wrote:
[...]
+torch_unlock:
+mutex_unlock(&led->lock);
+return ret;
+}
+
+static int rt5033_led_flash_brightness_set(struct led_classdev_flash
*fled_cdev,
+ u32 brightness)
+{
+struct rt5033_sub_led *sub_led = flcdev_to_sub_led(fled_cdev);
+struct rt5033_led *led = sub_led_to_led(sub_led);
+
+mutex_lock(&led->lock);
+sub_led->flash_brightness = brightness;
+mutex_unlock(&led->lock);
Mutex protection is redundant in this case. You would need it if device
state was also changed here.
Okay, I'll remove it.
BTW why flash brightness can't be written to the device here?
Flash brightness is only affected when FLED flashed (strobing).
So, I think it is better to be written in rt5033_led_flash_strobe_set function.
strobe_set op should strobe the flash ASAP, and delegating brightness
setting there extends a delay between calling strobe_set op
and actual flash strobe. If you set the brightness here, then you
wouldn't have to do that in the strobe_set op, of course unless the
the brightness is altered through the API of the other LED, in two
separate LEDs case.
+
+return 0;
+}
+
+static int rt5033_led_flash_timeout_set(struct led_classdev_flash *fled_cdev,
+u32 timeout)
+{
+struct rt5033_sub_led *sub_led = flcdev_to_sub_led(fled_cdev);
+struct rt5033_led *led = sub_led_to_led(sub_led);
+
+mutex_lock(&led->lock);
+sub_led->flash_timeout = timeout;
+mutex_unlock(&led->lock);
Ditto.
Timeout should be also written here.
If you will add regmap_write in both ops, then mutex protection will
have to be preserved, to assure consistency between registers state
and sub_led->flash_brightness and sub_led->flash_timeout state.
+#define RT5033_FLED_CTRL4_VTRREG_MAX0x60
Rename DEF to MASK.
Hmm, here it should be: Rename MAX to MASK.
--
Best Regards,
Jacek Anaszewski
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] remoteproc/wkup_m3: Use MODULE_DEVICE_TABLE to export alias
On Wed, Sep 16, 2015 at 3:32 PM, Dave Gerlach wrote: > Use MODULE_DEVICE_TABLE with wkup_m3_rproc_of_match so the module alias > is exported and the wkup_m3_rproc driver can automatically probe. > > Signed-off-by: Dave Gerlach Applied to remoteproc-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mm: warn about ALLOC_NO_WATERMARKS request failures
On Wed 25-11-15 13:01:56, David Rientjes wrote:
> On Wed, 25 Nov 2015, Michal Hocko wrote:
>
> > > > @@ -2642,6 +2644,13 @@ get_page_from_freelist(gfp_t gfp_mask, unsigned
> > > > int order, int alloc_flags,
> > > > if (zonelist_rescan)
> > > > goto zonelist_scan;
> > > >
> > > > + /* WARN only once unless min_free_kbytes is updated */
> > > > + if (warn_alloc_no_wmarks && (alloc_flags &
> > > > ALLOC_NO_WATERMARKS)) {
> > > > + warn_alloc_no_wmarks = 0;
> > > > + WARN(1, "Memory reserves are depleted for order:%d,
> > > > mode:0x%x."
> > > > + " You might consider increasing
> > > > min_free_kbytes\n",
> > > > + order, gfp_mask);
> > > > + }
> > > > return NULL;
> > > > }
> > > >
> > >
> > > Doesn't this warn for high-order allocations prior to the first call to
> > > direct compaction whereas min_free_kbytes may be irrelevant?
> >
> > Hmm, you are concerned about high order ALLOC_NO_WATERMARKS allocation
> > which happen prior to compaction, right? I am wondering whether there
> > are reasonable chances that a compaction would make a difference if we
> > are so depleted that there is no single page with >= order.
> > ALLOC_NO_WATERMARKS with high order allocations should be rare if
> > existing at all.
> >
>
> No, I'm concerned about get_page_from_freelist() failing for an order-9
> allocation due to _fragmentation_ and then emitting this warning although
> free watermarks may be gigabytes of memory higher than min watermarks.
Hmm, should we allow ALLOC_NO_WATERMARKS for order-9 (or >
PAGE_ALLOC_COSTLY_ORDER for that matter) allocations though? What would
be the point if they are allowed to fail and so they cannot be relied on
inherently?
I can see that we might do that currently - e.g. TIF_MEMDIE might be
set while doing hugetlb page allocation but I seriously doubt that this is
intentional and probably worth fixing.
> > > Providing
> > > the order is good, but there's no indication when min_free_kbytes may be
> > > helpful from this warning.
> >
> > I am not sure I understand what you mean here.
> >
>
> You show the order of the failed allocation in your new warning. Good.
> It won't help to raise min_free_kbytes to infinity if the high-order
> allocation failed due to fragmentation. Does that make sense?
Sure this makes sense but as I've tried to argue the warning is just a
hint. It should warn that something unexpected is happening and offer
a workaround. And yes increasing min_free_kbytes helps to keep more
high order pages availble from my experience.
If the workaround doesn't help I suspect the bug report would come more
promptly. Your example about order-9 ALLOC_NO_WATERMARKS failure is more
than exaggarated IMHO.
> > > WARN() isn't even going to show the state of memory.
> >
> > I was considering to do that but it would make the code unnecessarily
> > more complex. If the allocation is allowed to fail it would dump the
> > allocation failure. The purpose of the message is to tell us that
> > reserves are not sufficient. I am not sure seeing the memory state dump
> > would help us much more.
> >
>
> If the purpsoe of the message is to tell us when reserves are
> insufficient, it doesn't achieve that purpose if allocations fail due to
> fragmentation or lowmem_reserve_ratio.
Do you have any better suggestion or you just think that warning about
depleted reserves doesn't make any sense at all?
--
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] lightnvm: handle targets when corresponding nvm device exit
The reason why I put it in the ppalist_pool is that when I wrote the
code I thought state we needed was only exiting/stopping, I didn't
want to add a variable for just a bit.
I will send you a patch base on the lasted master 4.4rc2.
2015-11-25 23:39 GMT+08:00 Matias Bjørling :
> On 11/25/2015 01:42 PM, Wenwei Tao wrote:
>>
>> block creations of new targets, remove exiting targets when
>> underlying device was gone.
>>
>> Signed-off-by: Wenwei Tao
>> ---
>> drivers/lightnvm/core.c | 127
>> ++-
>> include/linux/lightnvm.h | 3 ++
>> 2 files changed, 85 insertions(+), 45 deletions(-)
>>
>> diff --git a/drivers/lightnvm/core.c b/drivers/lightnvm/core.c
>> index 39aec3a..0b71dd2 100644
>> --- a/drivers/lightnvm/core.c
>> +++ b/drivers/lightnvm/core.c
>> @@ -33,6 +33,17 @@ static LIST_HEAD(nvm_targets);
>> static LIST_HEAD(nvm_mgrs);
>> static LIST_HEAD(nvm_devices);
>> static DECLARE_RWSEM(nvm_lock);
>> +#define NVM_EXITING1
>> +
>> +static inline int NvmExiting(struct nvm_dev *dev)
>> +{
>> + return ((unsigned long)dev->ppalist_pool & NVM_EXITING) != 0;
>> +}
>> +
>> +static inline void *ppalist_pool(struct nvm_dev *dev)
>> +{
>> + return (void *)((unsigned long)dev->ppalist_pool & ~NVM_EXITING);
>> +}
>>
>
> I think I rather want to have a state variable (so we have a state machine
> for three state. Initializing, running, and stopping.
>
> What was the reason you'll like to put it in the ppalist_pool?
>
> ps. could you rebase it on top of the latest master. Then I'll review the
> rest of it.
>
>
>> static struct nvm_tgt_type *nvm_find_target_type(const char *name)
>> {
>> @@ -74,7 +85,7 @@ EXPORT_SYMBOL(nvm_unregister_target);
>> void *nvm_dev_dma_alloc(struct nvm_dev *dev, gfp_t mem_flags,
>> dma_addr_t
>> *dma_handler)
>> {
>> - return dev->ops->dev_dma_alloc(dev->q, dev->ppalist_pool,
>> mem_flags,
>> + return dev->ops->dev_dma_alloc(dev->q, ppalist_pool(dev),
>> mem_flags,
>>
>> dma_handler);
>> }
>> EXPORT_SYMBOL(nvm_dev_dma_alloc);
>> @@ -82,7 +93,7 @@ EXPORT_SYMBOL(nvm_dev_dma_alloc);
>> void nvm_dev_dma_free(struct nvm_dev *dev, void *ppa_list,
>> dma_addr_t
>> dma_handler)
>> {
>> - dev->ops->dev_dma_free(dev->ppalist_pool, ppa_list, dma_handler);
>> + dev->ops->dev_dma_free(ppalist_pool(dev), ppa_list, dma_handler);
>> }
>> EXPORT_SYMBOL(nvm_dev_dma_free);
>>
>> @@ -206,17 +217,6 @@ static int nvm_core_init(struct nvm_dev *dev)
>> return 0;
>> }
>>
>> -static void nvm_free(struct nvm_dev *dev)
>> -{
>> - if (!dev)
>> - return;
>> -
>> - if (dev->mt)
>> - dev->mt->unregister_mgr(dev);
>> -
>> - nvm_core_free(dev);
>> -}
>> -
>> static int nvm_init(struct nvm_dev *dev)
>> {
>> struct nvmm_type *mt;
>> @@ -262,6 +262,7 @@ static int nvm_init(struct nvm_dev *dev)
>> }
>> }
>>
>> + kref_init(&dev->kref);
>> if (!ret) {
>> pr_info("nvm: no compatible manager found.\n");
>> return 0;
>> @@ -278,11 +279,47 @@ err:
>> return ret;
>> }
>>
>> -static void nvm_exit(struct nvm_dev *dev)
>> +static void nvm_remove_target(struct nvm_target *t)
>> {
>> - if (dev->ppalist_pool)
>> - dev->ops->destroy_dma_pool(dev->ppalist_pool);
>> - nvm_free(dev);
>> + struct nvm_tgt_type *tt = t->type;
>> + struct gendisk *tdisk = t->disk;
>> + struct request_queue *q = tdisk->queue;
>> +
>> + lockdep_assert_held(&nvm_lock);
>> +
>> + del_gendisk(tdisk);
>> + if (tt->exit)
>> + tt->exit(tdisk->private_data);
>> +
>> + blk_cleanup_queue(q);
>> +
>> + put_disk(tdisk);
>> +
>> + list_del(&t->list);
>> + kfree(t);
>> +}
>> +
>> +static inline void nvm_remove_targets(struct nvm_dev *dev)
>> +{
>> + struct nvm_target *t, *n;
>> +
>> + list_for_each_entry_safe(t, n, &dev->online_targets, list)
>> + nvm_remove_target(t);
>> +}
>> +
>> +static void nvm_exit(struct kref *kref)
>> +{
>> + struct nvm_dev *dev;
>> +
>> + dev = container_of(kref, struct nvm_dev, kref);
>> + if (ppalist_pool(dev))
>> + dev->ops->destroy_dma_pool(ppalist_pool(dev));
>> +
>> + if (dev->mt)
>> + dev->mt->unregister_mgr(dev);
>> +
>> + if (dev->ops->dev_remove)
>> + dev->ops->dev_remove(dev->q);
>>
>> pr_info("nvm: successfully unloaded\n");
>> }
>> @@ -344,8 +381,10 @@ void nvm_unregister(char *disk_name)
>> }
>>
>> list_del(&dev->devices);
>> + nvm_remove_targets(dev);
>> + dev->ppalist_pool += NVM_EXITING;
>> up_write(&nvm_lock);
>> - nvm_exit(dev);
>> + kref_put(&dev->kref, nvm_exit);
>> }
>> EXPORT_SYMBOL(nvm_unregister);
>>
>>
Re: [PATCH] clk: tegra: Fix bypassing of PLLs
On 25/11/15 17:48, Jon Hunter wrote: > > On 25/11/15 15:52, Tyler Baker wrote: >> On 25 November 2015 at 07:11, Thierry Reding >> wrote: >>> On Mon, Nov 23, 2015 at 03:18:59PM -0800, Tyler Baker wrote: Hi Jon, On 20 November 2015 at 07:11, Jon Hunter wrote: > The _clk_disable_pll() function will attempt to place a PLL into bypass > if the TEGRA_PLL_BYPASS is specified for the PLL and then disable the PLL > by clearing the enable bit. To place the PLL into bypass, the bypass bit > needs to be set and not cleared. Fix this by setting the bypass bit and > not clearing it. > > Signed-off-by: Jon Hunter The kernelci.org bot recently detected a jetson-tk1 boot failure[1][2] in the tegra tree. This boot failure has only been observed when booting with a multi_v7_defconfig kernel variant. The bot bisected[3] this boot failure to this commit, and I confirmed reverting it on top of the tegra for-next branch resolves the issue. The ramdisk[4] used for booting is loaded with the modules from the build. It appears to me that as the modules are being loaded in userspace by eudev the jetson-tk1 locks up. I've sifted through the console logs a bit, and found this splat to be most interesting[5]. Can you confirm this issue on your end? >>> >>> Just to close the loop on this: we've discussed this on IRC and came to >>> the conclusion that not using the bypass mode is safer (switching into >>> and out of bypass can glitch). I've dropped this patch for now and Jon >>> will be looking into a second revision of the patch which, in addition >>> to fixing bypass (the fix is legit, it just happens to break because of >>> the glitch, most likely), will also remove the BYPASS flag setting so >>> that bypass will not be used. >> >> Thanks for the update, I appreciate you guys looking into this issue. >> Please CC me on any fixes, I can re-test and give my tested-by. > > No problem. On 2nd thoughts I am wondering if there is any value in > bypassing the PLL when disabling it. I will look into this and see what > I find out. So I got some feedback saying that setting the bypass bit is not glitch-less for most PLLs and so we should avoid setting this. It may look a bit odd from reviewing the code, but it is clear to me know. So we should just drop this change. However, if you like we could add a comment to document why we are doing this. Cheers Jon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf record: Add snapshot mode support for perf's regular events
* Ingo Molnar wrote: > So if an overwrite-mode background tracing session is running, you don't even > have > to signal it to capture the ring-buffer: just open the ring-buffer fd in > procfs, > under /proc/XYZ/perf/ring-buffers/5.trace or so, and dump its current > contents, > assuming the task doing that has sufficient permissions - i.e. > ptrace_may_access(). > > We could even pretty-print some very basic version of the records from the > kernel, > via /proc/XYZ/perf/ring-buffers/5.txt, to support a tooling-less tracing > modes. > This way perf based tracing could be supported even on systems that have no > writable filesystems. With this 'cat' could be used to look at the current trace: cat /proc/XYZ/perf/ring-buffers/5.txt would result in 'perf script' alike output generated by the kernel: $ cat /proc/XYZ/perf/ring-buffers/5.txt perf 24816 63796.780079: 1 cycles:pp: 810603f8 native_write_msr_safe perf 24816 63796.780083: 1 cycles:pp: 810603f8 native_write_msr_safe perf 24816 63796.780086: 8 cycles:pp: 810603f8 native_write_msr_safe perf 24816 63796.780089: 97 cycles:pp: 810603f8 native_write_msr_safe perf 24816 63796.780092: 1237 cycles:pp: 8103450c intel_pmu_handle_irq perf 24816 63796.780094: 13879 cycles:pp: 81204f23 setup_new_exec sh 24816 63796.780104: 170378 cycles:pp: 811bc437 change_protection_range sh 24816 63796.780145: 698206 cycles:pp: 813d22d7 clear_page_c_e sh 24816 63796.780304:1145748 cycles:pp: 7f60aca20bdb _dl_addr sh 24817 63796.780400: 1 cycles:pp: 810603f8 native_write_msr_safe sh 24817 63796.780403: 1 cycles:pp: 810603f8 native_write_msr_safe sh 24817 63796.780406: 10 cycles:pp: 810603f8 native_write_msr_safe sh 24817 63796.780409:118 cycles:pp: 810603f8 native_write_msr_safe ... and you could use shell scripting to analyze it - just like with ftrace. of course this would be simplified output - and you could still access or copy the raw trace data as well, and use all the rich tooling and visualization features of full perf. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > * PaX Team wrote: > > > actually the kernel could silently recover from this given how the page > > fault > > handler could easily determine that the fault address fell into the > > data..read_only section and just silently undo the read-only property, log > > the > > event to dmesg and retry the faulting access. > > So a safer method would be to decode the faulting instruction, to skip it by > fixing up the return RIP and to log the event. It would be mostly equivalent > to > trying to write to ROM (which get ignored as well), so it's a recoverable > (and > debuggable) event. if by skipping you mean ignoring the write attempt then it's not a good idea as it has a good chance to cause unexpected behaviour down the line. e.g., imagine that the write was to a function pointer (even an entire ops structure) or a boolean that controls some important feature for after-init code. ignoring/dropping such writes could cause all kinds of logic bugs (if not worse). my somewhat related war story is that i once tried to constify machine_ops (both the struct and the variable of the same name) directly and just forced the writes in kvm/xen/etc via type casts. now i knew it was all undefined behaviour but i didn't expect gcc to take advantage of it but it did (const propagated the *initial* fptr values into the indirect calls by turning them into direct calls) and which in turn prevented proper reboots for guests (an event which obviously happens much later after init/boot to the great puzzlement of end users and myself). misusing __read_only and ignoring write attempts would effectively produce the same misbehaviour as above so i strongly advise against it. now i understand that the motivation is probably to preserve the read-only property despite wrong use of __read_only but for this i'd suggest to simply not make the silent recovery the default behaviour and enable it on the kernel command line only. after all, this is expected to be a reproducible problem and affected users can just reboot (in fact, they'd be advised to) when it happens and get a proper report that they could then send back to lkml. i also don't expect this to be a frequent problem as __read_only will have to be handled carefully in every case and not just at the time of adding it to a variable but also later during code evolution. as i suggested in the constify plugin thread earlier, use of __read_only should be tied to compile time checking of all uses of the affected variable to eliminate the entire problem of problematic writes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/9] ppc64le FTRACE_WITH_REGS implementation
On 11/25/15, Torsten Duwe wrote:
> Implement FTRACE_WITH_REGS for powerpc64, on ELF ABI v2.
> Initial work started by Vojtech Pavlik, used with permission.
>
> * arch/powerpc/kernel/entry_64.S:
> - Implement an effective ftrace_caller that works from
> within the kernel binary as well as from modules.
> * arch/powerpc/kernel/ftrace.c:
> - be prepared to deal with ppc64 ELF ABI v2, especially
> calls to _mcount that result from gcc -mprofile-kernel
> - a little more error verbosity
> * arch/powerpc/kernel/module_64.c:
> - do not save the TOC pointer on the trampoline when the
> destination is ftrace_caller. This trampoline jump happens from
> a function prologue before a new stack frame is set up, so bad
> things may happen otherwise...
> - relax is_module_trampoline() to recognise the modified
> trampoline.
>
> Signed-off-by: Torsten Duwe
> ---
> arch/powerpc/include/asm/ftrace.h | 5 +++
> arch/powerpc/kernel/entry_64.S| 77
> +++
> arch/powerpc/kernel/ftrace.c | 60 +++---
> arch/powerpc/kernel/module_64.c | 25 -
> 4 files changed, 160 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/ftrace.h
> b/arch/powerpc/include/asm/ftrace.h
> index ef89b14..50ca758 100644
> --- a/arch/powerpc/include/asm/ftrace.h
> +++ b/arch/powerpc/include/asm/ftrace.h
> @@ -46,6 +46,8 @@
> extern void _mcount(void);
>
> #ifdef CONFIG_DYNAMIC_FTRACE
> +# define FTRACE_ADDR ((unsigned long)ftrace_caller)
> +# define FTRACE_REGS_ADDR FTRACE_ADDR
> static inline unsigned long ftrace_call_adjust(unsigned long addr)
> {
> /* reloction of mcount call site is the same as the address */
> @@ -58,6 +60,9 @@ struct dyn_arch_ftrace {
> #endif /* CONFIG_DYNAMIC_FTRACE */
> #endif /* __ASSEMBLY__ */
>
> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_REGS
> +#define ARCH_SUPPORTS_FTRACE_OPS 1
> +#endif
> #endif
>
> #if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64) &&
> !defined(__ASSEMBLY__)
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 8d56b16..3309dd8 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
Linux style for comments is the C89. Please update entry_64.S
> @@ -1212,6 +1212,7 @@ _GLOBAL(_mcount)
> mtlrr0
> bctr
>
> +#ifndef CC_USING_MPROFILE_KERNEL
> _GLOBAL_TOC(ftrace_caller)
> /* Taken from output of objdump from lib64/glibc */
> mflrr3
> @@ -1233,6 +1234,82 @@ _GLOBAL(ftrace_graph_stub)
> ld r0, 128(r1)
> mtlrr0
> addir1, r1, 112
> +#else
> +_GLOBAL(ftrace_caller)
> +#if defined(_CALL_ELF) && _CALL_ELF == 2
> + mflrr0
> + bl 2f
> +2: mflrr12
> + mtlrr0
> + mr r0,r2 // save callee's TOC
> + addis r2,r12,(.TOC.-ftrace_caller-8)@ha
> + addir2,r2,(.TOC.-ftrace_caller-8)@l
> +#else
> + mr r0,r2
> +#endif
> + ld r12,LRSAVE(r1) // get caller's address
> +
> + stdur1,-SWITCH_FRAME_SIZE(r1)
> +
> + std r12, _LINK(r1)
> + SAVE_8GPRS(0,r1)
> + std r0, 24(r1) // save TOC
> + SAVE_8GPRS(8,r1)
> + SAVE_8GPRS(16,r1)
> + SAVE_8GPRS(24,r1)
> +
> + addis r3,r2,function_trace_op@toc@ha
> + addir3,r3,function_trace_op@toc@l
> + ld r5,0(r3)
> +
> + mflrr3
> + std r3, _NIP(r1)
> + std r3, 16(r1)
> + subir3, r3, MCOUNT_INSN_SIZE
> + mfmsr r4
> + std r4, _MSR(r1)
> + mfctr r4
> + std r4, _CTR(r1)
> + mfxer r4
> + std r4, _XER(r1)
> + mr r4, r12
> + addir6, r1 ,STACK_FRAME_OVERHEAD
> +
> +.globl ftrace_call
> +ftrace_call:
> + bl ftrace_stub
> + nop
> +
> + ld r3, _NIP(r1)
> + mtlrr3
> +
> + REST_8GPRS(0,r1)
> + REST_8GPRS(8,r1)
> + REST_8GPRS(16,r1)
> + REST_8GPRS(24,r1)
> +
> + addi r1, r1, SWITCH_FRAME_SIZE
> +
> + ld r12, LRSAVE(r1) // get caller's address
> + mtlrr12
> + mr r2,r0 // restore callee's TOC
> +
> +#ifdef CONFIG_FUNCTION_GRAPH_TRACER
> + stdur1, -112(r1)
> +.globl ftrace_graph_call
> +ftrace_graph_call:
> + b ftrace_graph_stub
> +_GLOBAL(ftrace_graph_stub)
> + addir1, r1, 112
> +#endif
> +
> + mflrr0 // move this LR to CTR
> + mtctr r0
> +
> + ld r0,LRSAVE(r1) // restore callee's lr at _mcount site
> + mtlrr0
> + bctr// jump after _mcount site
> +#endif /* CC_USING_MPROFILE_KERNEL */
> _GLOBAL(ftrace_stub)
> blr
> #else
> diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
> index 080c525..310137f 100644
> --- a/arch/powerpc/kernel/ftrace.c
> +++ b/arch/powerpc/kernel/ftrace.c
> @@ -61,8 +61,11 @@ ftrace_modify_code(unsigned long ip, unsigned int old,
> unsigned int new)
>
Re: [PATCH v4 06/13] drm/bridge: Add Synopsys DesignWare MIPI DSI host controller driver
On 11/26/2015 04:04 PM, Thierry Reding wrote:
On Thu, Nov 26, 2015 at 03:03:54PM +0800, Chris Zhong wrote:
Hi Thierry
Thanks for your feedback.
On 11/21/2015 12:07 AM, Thierry Reding wrote:
On Fri, Nov 20, 2015 at 04:15:32PM +0800, Chris Zhong wrote:
add Synopsys DesignWare MIPI DSI host controller driver support.
Signed-off-by: Chris Zhong
---
Changes in v4:
eliminate some warnning
Changes in v3: None
Changes in v2: None
drivers/gpu/drm/bridge/Kconfig | 11 +
drivers/gpu/drm/bridge/Makefile |1 +
drivers/gpu/drm/bridge/dw_mipi_dsi.c | 1056 ++
include/drm/bridge/dw_mipi_dsi.h | 27 +
4 files changed, 1095 insertions(+)
create mode 100644 drivers/gpu/drm/bridge/dw_mipi_dsi.c
create mode 100644 include/drm/bridge/dw_mipi_dsi.h
+struct dw_mipi_dsi {
+ struct mipi_dsi_host dsi_host;
+ struct drm_connector connector;
+ struct drm_encoder *encoder;
struct drm_bridge already has a pointer to an encoder, can't you reuse
that instead?
+ struct drm_bridge *bridge;
Typically you'd embed the bridge into the driver structure.
I'm almost done with all the modifications according to your comments.
Remaining this point I can not understand, the dsi is a pointer of
drm_bridge,
hence I can not get the bridge by container_of.
Although, the "bridge->driver_private = dsi" have done in
dw_mipi_dsi_register.
I don't understand. If you don't make bridge a pointer, but rather embed
it within the structure, then you can use container_of(), can't you? You
get it allocated automatically as part of allocating the dw_mipi_dsi
structure. See for example the ps8622 and ptn3460 bridge drivers.
Yeah, got it, thanks. :)
I am going to modify it in next version patch.
On a slightly unrelated note, I'm not sure if we discussed this already
or if it was in another thread, but why is this even a bridge driver? A
bridge is typically some IC outside of the SoC, whereas this clearly is
IP designed into the SoC. So it's really more of an encoder rather than
a bridge.
I guess you mean this thread
Re: [PATCH] regulator: tps65218: add support for LS3 current regulator
On Wed, 25 Nov 2015, Nikita Kiryanov wrote: > Add support for TPS65218 LS3 current regulator, which is capable of 4 > current input limit modes: 100, 200, 500, and 1000 uA. > > Signed-off-by: Nikita Kiryanov > Cc: Tony Lindgren > Cc: Liam Girdwood > Cc: Mark Brown > Cc: Samuel Ortiz > Cc: Lee Jones > --- > drivers/regulator/tps65218-regulator.c | 137 > + > include/linux/mfd/tps65218.h | 7 +- Acked-by: Lee Jones > include/linux/regulator/driver.h | 2 + > 3 files changed, 115 insertions(+), 31 deletions(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/9] ppc64 (le): prepare for -mprofile-kernel
On 11/25/15, Torsten Duwe wrote:
> The gcc switch -mprofile-kernel, available for ppc64 on gcc > 4.8.5,
> allows to call _mcount very early in the function, which low-level
> ASM code and code patching functions need to consider.
> Especially the link register and the parameter registers are still
> alive and not yet saved into a new stack frame.
>
> Signed-off-by: Torsten Duwe
> ---
> arch/powerpc/kernel/entry_64.S | 44
> +++--
> arch/powerpc/kernel/ftrace.c| 12 +--
> arch/powerpc/kernel/module_64.c | 13
> 3 files changed, 65 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index a94f155..8d56b16 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -1206,7 +1206,11 @@ _GLOBAL(enter_prom)
> #ifdef CONFIG_DYNAMIC_FTRACE
> _GLOBAL(mcount)
> _GLOBAL(_mcount)
> - blr
> + mflrr0
> + mtctr r0
> + ld r0,LRSAVE(r1)
> + mtlrr0
> + bctr
>
> _GLOBAL_TOC(ftrace_caller)
> /* Taken from output of objdump from lib64/glibc */
> @@ -1262,13 +1266,28 @@ _GLOBAL(ftrace_stub)
>
> #ifdef CONFIG_FUNCTION_GRAPH_TRACER
> _GLOBAL(ftrace_graph_caller)
> +#ifdef CC_USING_MPROFILE_KERNEL
> + // with -mprofile-kernel, parameter regs are still alive at _mcount
> + std r10, 104(r1)
> + std r9, 96(r1)
> + std r8, 88(r1)
> + std r7, 80(r1)
> + std r6, 72(r1)
> + std r5, 64(r1)
> + std r4, 56(r1)
> + std r3, 48(r1)
> + mfctr r4 // ftrace_caller has moved local addr here
> + std r4, 40(r1)
> + mflrr3 // ftrace_caller has restored LR from stack
> +#else
> /* load r4 with local address */
> ld r4, 128(r1)
> - subir4, r4, MCOUNT_INSN_SIZE
>
> /* Grab the LR out of the caller stack frame */
> ld r11, 112(r1)
> ld r3, 16(r11)
> +#endif
> + subir4, r4, MCOUNT_INSN_SIZE
>
> bl prepare_ftrace_return
> nop
> @@ -1277,6 +1296,26 @@ _GLOBAL(ftrace_graph_caller)
>* prepare_ftrace_return gives us the address we divert to.
>* Change the LR in the callers stack frame to this.
>*/
> +
> +#ifdef CC_USING_MPROFILE_KERNEL
> + mtlrr3
> +
> + ld r0, 40(r1)
> + mtctr r0
> + ld r10, 104(r1)
> + ld r9, 96(r1)
> + ld r8, 88(r1)
> + ld r7, 80(r1)
> + ld r6, 72(r1)
> + ld r5, 64(r1)
> + ld r4, 56(r1)
> + ld r3, 48(r1)
> +
> + addir1, r1, 112
> + mflrr0
> + std r0, LRSAVE(r1)
> + bctr
> +#else
> ld r11, 112(r1)
> std r3, 16(r11)
>
> @@ -1284,6 +1323,7 @@ _GLOBAL(ftrace_graph_caller)
> mtlrr0
> addir1, r1, 112
> blr
> +#endif
>
> _GLOBAL(return_to_handler)
> /* need to save return values */
> diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
> index 44d4d8e..080c525 100644
> --- a/arch/powerpc/kernel/ftrace.c
> +++ b/arch/powerpc/kernel/ftrace.c
> @@ -306,11 +306,19 @@ __ftrace_make_call(struct dyn_ftrace *rec, unsigned
> long addr)
>* The load offset is different depending on the ABI. For simplicity
>* just mask it out when doing the compare.
>*/
> +#ifndef CC_USING_MPROFILE_KERNEL
> if ((op[0] != 0x4808) || ((op[1] & 0x) != 0xe841)) {
> - pr_err("Unexpected call sequence: %x %x\n", op[0], op[1]);
> + pr_err("Unexpected call sequence at %p: %x %x\n",
> + ip, op[0], op[1]);
> return -EINVAL;
> }
> -
> +#else
> + /* look for patched "NOP" on ppc64 with -mprofile-kernel */
> + if (op[0] != 0x6000) {
> + pr_err("Unexpected call at %p: %x\n", ip, op[0]);
> + return -EINVAL;
> + }
> +#endif
> /* If we never set up a trampoline to ftrace_caller, then bail */
> if (!rec->arch.mod->arch.tramp) {
> pr_err("No ftrace trampoline\n");
> diff --git a/arch/powerpc/kernel/module_64.c
> b/arch/powerpc/kernel/module_64.c
> index 6838451..0819ce7 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -475,6 +475,19 @@ static unsigned long stub_for_addr(Elf64_Shdr *sechdrs,
> static int restore_r2(u32 *instruction, struct module *me)
> {
> if (*instruction != PPC_INST_NOP) {
> +#ifdef CC_USING_MPROFILE_KERNEL
> + /* -mprofile_kernel sequence starting with
> + * mflr r0; std r0, LRSAVE(r1)
> + */
> + if (instruction[-3] == 0x7c0802a6 &&
> + instruction[-2] == 0xf8010010) {
> + /* Nothing to be done here, it's an _mcount
> + * call location and r2 will have to be
> + * restored in the _mcount function.
> + */
[PATCH] gpiolib: return 0 or 1 in gpiod_get_value*() functions
Commit 79a9becda894 moved the awareness of active low state into the gpiod_get_value*() functions, but it only inverts the GPIO's raw value when it is active low. If the GPIO is active high, the gpiod_get_value*() functions return the raw value of the register, which can be any positive value. This patch does a double inversion when the GPIO is active high to make sure either a 0 or 1 is returned by these functions. Signed-off-by: Jose Diaz de Grenu de Pedro Signed-off-by: Hector Palacios --- drivers/gpio/gpiolib.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 50c4922fe53a..20f472a25b55 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -1981,9 +1981,9 @@ int gpiod_get_value(const struct gpio_desc *desc) value = _gpiod_get_raw_value(desc); if (test_bit(FLAG_ACTIVE_LOW, &desc->flags)) - value = !value; - - return value; + return !value; + else + return !!value } EXPORT_SYMBOL_GPL(gpiod_get_value); @@ -2224,9 +2224,9 @@ int gpiod_get_value_cansleep(const struct gpio_desc *desc) value = _gpiod_get_raw_value(desc); if (test_bit(FLAG_ACTIVE_LOW, &desc->flags)) - value = !value; - - return value; + return !value; + else + return !!value; } EXPORT_SYMBOL_GPL(gpiod_get_value_cansleep); -- 2.6.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arm64: restore bogomips information in /proc/cpuinfo
On Wed, 2015-11-25 at 13:09 -0500, Nicolas Pitre wrote: > But CPU MHz, when available, has the merit of not being open to > interpretation. Current MHz, maximum MHz or 'turbo' MHz? ;-) -- Tixy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 22/71] ncr5380: Eliminate selecting state
On Wed, 25 Nov 2015, Ondrej Zary wrote:
> On Wednesday 25 November 2015 04:17:09 Finn Thain wrote:
> >
> > On Tue, 24 Nov 2015, Ondrej Zary wrote:
> >
> > >
> > > Bisecting slow module initialization pointed to this commit.
> > >
> > > Before this commit (2 seconds):
> > > [ 60.317374] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> > > n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2,
> > > sg_tablesize 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3,
> > > USLEEP_SLEEP 50, options { AUTOPROBE_IRQ PSEUDO_DMA }
> > > [ 60.780715] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X
> > > 4.6 PQ: 0 ANSI: 2 CCS
> > > [ 62.606260] sd 2:0:1:0: Attached scsi generic sg1 type 0
> > >
> > >
> > > After this commit (22 seconds):
> > > [ 137.511711] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> > > n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2,
> > > sg_tablesize 128, this_id 7, flags { NCR53C400 }, USLEEP_POLL 3,
> > > USLEEP_SLEEP 50, options { AUTOPROBE_IRQ PSEUDO_DMA }
> > > [ 145.028532] clocksource: timekeeping watchdog: Marking clocksource
> > > 'tsc' as unstable because the skew is too large:
> > > [ 145.029767] clocksource: 'acpi_pm' wd_now:
> > > a49738 wd_last: f4da04 mask: ff
> > > [ 145.029828] clocksource: 'tsc' cs_now:
> > > 2ea624698e cs_last: 2c710aa17f mask:
> > > [ 145.032733] clocksource: Switched to clocksource acpi_pm
> > > [ 145.236951] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X
> > > 4.6 PQ: 0 ANSI: 2 CCS
> > > [ 159.959308] sd 2:0:1:0: Attached scsi generic sg1 type 0
> > >
> > >
> >
> > This problem doesn't show up on my hardware, and I'd like to know where
> > those 22 seconds are being spent. Would you please apply the entire series
> > and add,
> > #define NDEBUG (NDEBUG_ARBITRATION | NDEBUG_SELECTION | NDEBUG_MAIN)
> > to the top of g_NCR5380.c and send me the messages logged during modprobe?
>
> [ 397.014581] scsi host2: Generic NCR5380/NCR53C400 SCSI, io_port 0x0,
> n_io_port 0, base 0xd8000, irq 0, can_queue 16, cmd_per_lun 2, sg_tablesize
> 128, this_id 7, flags { NO_DMA_FIXUP }, options { AUTOPROBE_IRQ PSEUDO_DMA }
> [ 412.099695] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 412.103625] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 412.110503] scsi 2:0:1:0: Direct-Access QUANTUM LP240S GM240S01X 4.6
> PQ: 0 ANSI: 2 CCS
> [ 412.110892] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 412.114154] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 412.119733] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 427.198108] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 442.276586] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 457.354592] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 472.432999] STATUS_REG: 00
> BASR: 08
> ICR: 00
> MODE: 00
> [ 487.513027] sd 2:0:1:0: Attached scsi generic sg1 type 0
>
>
I see that the delay increased from 22 seconds to 90 seconds. Perhaps that
is because the remaining patches were applied.
Anyway, it seems to confirm that this delay comes from scanning the six
unused SCSI bus IDs. Each one takes 15 seconds. Could be a five second
timeout and three retries. It's hard to tell because the dsprintk()
logging didn't show up. Can you try modprobe after,
# echo 1 > /sys/module/printk/parameters/ignore_loglevel
And maybe also,
# scsi_logging_level -sS7
It seems like the 53C400 chip doesn't arbitrate like a 53C80, but that
doesn't make sense given it contains a 53C80 logic block. Perhaps some
extra initialization is needed. Which card(s) are affected?
Aside from trying to figure out why the chip behaves oddly, we could also
try to figure out whether the driver and its main loop is causing problems
for other tasks i.e. timekeeping watchdog. Does this patch make any
difference?
Index: linux/drivers/scsi/atari_NCR5380.c
===
--- linux.orig/drivers/scsi/atari_NCR5380.c 2015-11-26 15:42:01.0
+1100
+++ linux/drivers/scsi/atari_NCR5380.c 2015-11-26 15:42:04.0 +1100
@@ -925,6 +925,7 @@ static void NCR5380_main(struct work_str
container_of(work, struct NCR5380_hostdata, main_task);
struct Scsi_Host *instance = hostdata->host;
struct scsi_cmnd *cmd;
+ unsigned long deadline = jiffies + msecs_to_jiffies(10);
int done;
/*
@@ -984,9 +985,12 @@ static void NCR5380_main(struct work_str
done = 0;
}
spin_unlock_irq(&hostdata->lock);
- if (!done)
- cond_resched();
- } while (!done);
+ if (done || time_is_before_jiffies(deadline))
+ break;
+ cond_resched();
+ } while (1);
+ if (!done)
+ queue_work(hostdata->work_q, &hostdata->mai
Re: [PATCH 2/2] irqchip: add support for Sigma Designs SMP86xx interrupt controller
On 25/11/2015 13:12, Måns Rullgård wrote:
> Mason writes:
>
>>> + status_lo = intc_readl(chip, chip->ctl + IRQ_STATUS);
>>> + status_hi = intc_readl(chip, chip->ctl + IRQ_CTL_HI + IRQ_STATUS);
>>
>> In my local branch, I wrote:
>>
>> #define IRQ_CTL_LO 0
>>
>> status_lo = intc_readl(chip, chip->ctl + IRQ_CTL_LO + IRQ_STATUS);
>> status_hi = intc_readl(chip, chip->ctl + IRQ_CTL_HI + IRQ_STATUS);
>>
>> (I'm a sucker for symmetry)
>
> Nothing wrong with a little symmetry, though in this case I think the
> extra macro only confuses matters.
It's your call :-)
In my mind, the fact that the status_lo register sits at offset 0 is
just an accident. It's just that something has to sit at offset 0.
(Maybe I should tell the HW guys to put nothing at offset 0, and start
the actual register block at offset 4. /That/ would be unexpected.)
Another way to look at it is:
There are two 4-register blocks (LO and HI) each containing registers
{status,rawstat,enableset,enableclr}.
Block LO starts at offset 0x0
Block HI starts at offset 0x18
and then there are the intra offsets for the 4 registers in the block.
There! I got the bike-shedding out of my system ;-)
Regards.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1] net: stmmac: Free rx_skbufs before realloc
On 11/25/2015 4:13 PM, Giuseppe CAVALLARO wrote: Hello On 11/24/2015 7:09 PM, David Miller wrote: From: Shunqian Zheng Date: Sun, 22 Nov 2015 16:44:18 +0800 From: ZhengShunQian The init_dma_desc_rings() may realloc the rx_skbuff[] when suspend and resume. This patch free the rx_skbuff[] before reallocing memory. Signed-off-by: ZhengShunQian This isn't really the right way to fix this. I see two reasonable approaches: 1) suspend liberates the RX ring, although this approach is less desirable 2) resume doesn't try to allocate already populated RX ring entries Freeing the whole RX ring just to allocate it again immediately makes no sense at all and is wasteful work. This is a bug in this driver version that, to be honest, we fixed with the first approach on STi kernel. The patch just called the dma_free_rx_skbufs(priv) in the suspend. I can give you this patch that is tested on my side too. But! I do think we should move on second approach. Indeed, also on ST platforms, when we play with suspend states the DDR although in self-refresh the data are not lost at all. No reason to free and reallocate all in suspend/resume. I can test that and then provide another patch to this mailing list asap. I have just send the patch (directly for approach #2). Peppe Let me know. peppe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] efi/esrt: don't preformat name
On Fri, 20 Nov, at 11:30:17AM, Rasmus Villemoes wrote:
> kobject_init_and_add takes a format string+args, so there's no reason
> to do this formatting in advance.
>
> Signed-off-by: Rasmus Villemoes
> ---
> drivers/firmware/efi/esrt.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
Looks good to me. Thanks applied!
> diff --git a/drivers/firmware/efi/esrt.c b/drivers/firmware/efi/esrt.c
> index 22c5285f7705..75feb3f5829b 100644
> --- a/drivers/firmware/efi/esrt.c
> +++ b/drivers/firmware/efi/esrt.c
> @@ -167,14 +167,11 @@ static struct kset *esrt_kset;
> static int esre_create_sysfs_entry(void *esre, int entry_num)
> {
> struct esre_entry *entry;
> - char name[20];
>
> entry = kzalloc(sizeof(*entry), GFP_KERNEL);
> if (!entry)
> return -ENOMEM;
>
> - sprintf(name, "entry%d", entry_num);
> -
> entry->kobj.kset = esrt_kset;
>
> if (esrt->fw_resource_version == 1) {
> @@ -182,7 +179,7 @@ static int esre_create_sysfs_entry(void *esre, int
> entry_num)
>
> entry->esre.esre1 = esre;
> rc = kobject_init_and_add(&entry->kobj, &esre1_ktype, NULL,
> - "%s", name);
> + "entry%d", entry_num);
> if (rc) {
> kfree(entry);
> return rc;
> --
> 2.6.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.2 22/52] ALSA: hda - Disable 64bit address for Creative HDA controllers
On Thu, Nov 26, 2015 at 12:34:33AM +, Ben Hutchings wrote: > On Wed, 2015-11-25 at 23:05 +, Luis Henriques wrote: > > On Tue, Nov 24, 2015 at 10:33:59PM +, Ben Hutchings wrote: > > > 3.2.74-rc1 review patch. If anyone has any objections, please let me > > > know. > > > > > > -- > > > > > > From: Takashi Iwai > > > > > > commit cadd16ea33a938d49aee99edd4758cc76048b399 upstream. > > > > > > We've had many reports that some Creative sound cards with CA0132 > > > don't work well. Some reported that it starts working after reloading > > > the module, while some reported it starts working when a 32bit kernel > > > is used. All these facts seem implying that the chip fails to > > > communicate when the buffer is located in 64bit address. > > > > > > This patch addresses these issues by just adding AZX_DCAPS_NO_64BIT > > > flag to the corresponding PCI entries. I casually had a chance to > > > test an SB Recon3D board, and indeed this seems helping. > > > > > > Although this hasn't been tested on all Creative devices, it's safer > > > to assume that this restriction applies to the rest of them, too. So > > > the flag is applied to all Creative entries. > > > > > > Signed-off-by: Takashi Iwai > > > [bwh: Backported to 3.2: drop the change to AZX_DCAPS_PRESET_CTHDA] > > > > Is there a reason for dropping this change? Adding the > > AZX_DCAPS_NO_64BIT flag to the AZX_DCAPS_PRESET_CTHDA definition does > > seem to make sense. > [...] > > The AZX_DCAPS_PRESET_CTHDA macro was introduced in 3.5. > Doh, you're right. I was probably looking at the wrong branch. Sorry for the noise. Cheers, -- Luís > Ben. > > -- > Ben Hutchings > Unix is many things to many people, > but it's never been everything to anybody. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
use-after-free in tty_check_change
Hello,
The following program causes a use-after-free in tty_check_change:
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#include
#include
#include
#include
void *thr(void *arg)
{
int x = 0;
ioctl((int)(long)arg, TIOCGETD, &x);
return 0;
}
void tty()
{
int fd = open("/dev/ptmx", O_RDONLY|O_SYNC);
pthread_t th;
pthread_create(&th, 0, thr, (void*)(long)fd);
int x = 16;
ioctl(fd, TIOCSETD, &x);
pthread_join(th, 0);
}
int main()
{
int i;
for (i = 0; i < 10; i++) {
if (fork() == 0) {
tty();
return 0;
}
}
return 0;
}
==
BUG: KASAN: use-after-free in tty_ioctl+0x1f06/0x2140 at addr 880061aa0968
Read of size 8 by task a.out/6241
=
BUG kmalloc-16 (Not tainted): kasan: bad access detected
-
Disabling lock debugging due to kernel taint
INFO: Allocated in tty_ldisc_get.part.3+0x66/0x140 age=6 cpu=3 pid=6230
[< none >] kmem_cache_alloc_trace+0x1cf/0x220 mm/slub.c:2589
[< none >] tty_ldisc_get.part.3+0x66/0x140 drivers/tty/tty_ldisc.c:172
[< none >] tty_set_ldisc+0x83d/0xa70 drivers/tty/tty_ldisc.c:574
[< none >] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2865
[< inline >] spin_unlock include/linux/spinlock.h:347
[< inline >] ioctl_fionbio fs/ioctl.c:492
[< none >] do_vfs_ioctl+0x681/0xe40 fs/ioctl.c:572
[< none >] SyS_ioctl+0x8f/0xc0 fs/readdir.c:25
[< none >] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
INFO: Freed in tty_set_ldisc+0x4c2/0xa70 age=12 cpu=3 pid=6230
[< none >] kfree+0x199/0x1b0 mm/slub.c:3632
[< inline >] tty_ldisc_restore drivers/tty/tty_ldisc.c:493
[< none >] tty_set_ldisc+0x4c2/0xa70 drivers/tty/tty_ldisc.c:571
[< none >] tty_ioctl+0xb2a/0x2140 drivers/tty/tty_io.c:2865
[< inline >] spin_unlock include/linux/spinlock.h:347
[< inline >] ioctl_fionbio fs/ioctl.c:492
[< none >] do_vfs_ioctl+0x681/0xe40 fs/ioctl.c:572
[< none >] SyS_ioctl+0x8f/0xc0 fs/readdir.c:25
[< none >] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
INFO: Slab 0xea000186a800 objects=23 used=19 fp=0x880061aa12d0
flags=0x5fffc004080
INFO: Object 0x880061aa0968 @offset=2408 fp=0x880061aa0810
CPU: 2 PID: 6241 Comm: a.out Tainted: GB 4.4.0-rc1+ #117
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
88006db0fab8 827450f6 88003e807980
880061aa0968 880061aa 88006db0fae8 81629404
88003e807980 ea000186a800 880061aa0968 001b
Call Trace:
[] __asan_report_load8_noabort+0x3e/0x40
mm/kasan/report.c:280
[< inline >] tty_check_change drivers/tty/tty_io.c:399
[] tty_ioctl+0x1f06/0x2140 drivers/tty/tty_io.c:2831
[< inline >] spin_unlock include/linux/spinlock.h:347
[< inline >] ioctl_fionbio fs/ioctl.c:492
[] do_vfs_ioctl+0x681/0xe40 fs/ioctl.c:572
[] SyS_ioctl+0x8f/0xc0 fs/readdir.c:25
[] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
==
On commit 6ffeba9607343f15303a399bc402a538800d89d9 (Nov 24).
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] remoteproc: fix memory leak of remoteproc ida cache layers
On Thu, Nov 26, 2015 at 11:38:06AM +0200, Ohad Ben-Cohen wrote: > Hi Suman, > > On Thu, Sep 17, 2015 at 3:29 AM, Suman Anna wrote: > > The remoteproc core uses a static ida named rproc_dev_index for > > assigning an automatic index number to a registered remoteproc. > > The ida core may allocate some internal idr cache layers and ida > > bitmap upon any ida allocation, and all these layers are truely > > freed only upon the ida destruction. The rproc_dev_index ida is > > not destroyed at present, leading to a memory leak when using the > > remoteproc core as a module and atleast one rproc device is > > registered and unregistered. > > > > Fix this by invoking ida_destroy() in the remoteproc core module > > exit. > > I saw there was some discussion about this between Michael, James and > Tejun whether this should be fixed in the IDA core or not. > > Has it been resolved? > > Thanks, > Ohad. I don't think we reached any conclusions. I guess I'll merge the virtio patch as-is then. Ohad, would you like to merge 2/2? -- MST -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/9] mm, page_owner: track and print last migrate reason
On 11/25/2015 09:13 AM, Joonsoo Kim wrote:
>> +if (page_ext->last_migrate_reason != -1) {
>> +ret += snprintf(kbuf + ret, count - ret,
>> +"Page has been migrated, last migrate reason: %s\n",
>> +migrate_reason_names[page_ext->last_migrate_reason]);
>> +if (ret >= count)
>> +goto err;
>> +}
>> +
>
> migrate_reason_names is defined if CONFIG_MIGRATION is enabled so
> it would cause build failure in case of !CONFIG_MIGRATION and
> CONFIG_PAGE_OWNER.
>
> Thanks.
Ugh right, linking gives warnings... Thanks.
I think instead of adding #ifdefs here, let's move migrate_reason_names to
mm/debug.c as we gradually do with these things. Also enum
migrate_reason is defined regardless of CONFIG_MIGRATION, so match that
for migrate_reason_names as well.
--8<--
>From 7b650fd613ed382aaa6f11f4b779e883a6af10aa Mon Sep 17 00:00:00 2001
From: Vlastimil Babka
Date: Thu, 26 Nov 2015 11:31:09 +0100
Subject: mm, page_owner: track and print last migrate reason-fix
Move migrate_reason_names from mm/migrate.c to mm/debug.c so that link doesn't
warn with CONFIG_MIGRATION disabled.
---
include/linux/migrate.h | 2 +-
mm/debug.c | 11 +++
mm/migrate.c| 10 --
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index ab92a8cf4c93..8fdc033e527a 100644
--- a/include/linux/migrate.h
+++ b/include/linux/migrate.h
@@ -27,7 +27,7 @@ enum migrate_reason {
MR_TYPES
};
-/* In mm/migrate.c; also keep sync with include/trace/events/migrate.h */
+/* In mm/debug.c; also keep sync with include/trace/events/migrate.h */
extern char * migrate_reason_names[MR_TYPES];
#ifdef CONFIG_MIGRATION
diff --git a/mm/debug.c b/mm/debug.c
index d9718fc8377a..a4cd0c093ff6 100644
--- a/mm/debug.c
+++ b/mm/debug.c
@@ -9,6 +9,17 @@
#include
#include
#include
+#include
+
+char *migrate_reason_names[MR_TYPES] = {
+ "compaction",
+ "memory_failure",
+ "memory_hotplug",
+ "syscall_or_cpuset",
+ "mempolicy_mbind",
+ "numa_misplaced",
+ "cma",
+};
static const struct trace_print_flags pageflag_names[] = {
{1UL << PG_locked, "locked"},
diff --git a/mm/migrate.c b/mm/migrate.c
index 12e9ab9de446..1c11b73cd834 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -47,16 +47,6 @@
#include "internal.h"
-char *migrate_reason_names[MR_TYPES] = {
- "compaction",
- "memory_failure",
- "memory_hotplug",
- "syscall_or_cpuset",
- "mempolicy_mbind",
- "numa_misplaced",
- "cma",
-};
-
/*
* migrate_prep() needs to be called before we start compiling a list of pages
* to be migrated using isolate_lru_page(). If scheduling work on other CPUs is
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/10] Input: synaptics-rmi4: Synaptics RMI4 Driver rebased on 4.3
Hi Andrew, On Nov 25 2015 or thereabouts, Andrew Duggan wrote: > This is a new patch series which squashes all of the development > history of the RMI4 driver into patches based on functionality. The > first patch adds the core RMI4 functionality needed by all RMI4 devices > and then the additional patches add transport and function drivers for > supporting various devices. Thanks for this hard work. I did not do a full review of the series yet, but caught some general design questions that I am writing here. > > Touchpads which are currently using hid-rmi should have the same > functionality, but now knowledge of RMI is handled in the core instead I tried applying the series on top of a 4.4-rc2, and git am failed. I think it's good to keep this one in the series, but we might want to postpone its application when rmi4 hits Linus' tree so Jiri will be able to take it without conflicting with Dmitry's tree. Well, Jiri and Dmitry can sort this out :) > of in hid-rmi. These patches also provide basic finger reporting for a > wide range of RMI4 touchscreens connected to I2C and SPI busses. > However, additional work may need to be done to implement product specific > features. > > I tried to include all of the feedback I received from the previous > patches I posted. However, I did not come up with a satisfactory solution > for allowing function drivers to be built as modules. I think it is fine > to allow function drivers to be enabled or disabled in the core at build I agree. I do not like the implementation however (I know, I contributed a lot to it). How about we keep a static array of struct rmi_function_handler? If we add a .registered file in struct rmi_function_handler, we could simplify the registering/unregistering of the functions more easily by looping through the array. > time. However, if supporting function drivers as modules is a must have > for upstreaming I can continue to try to find a solution. Also, I went > ahead and removed support for polling. Thanks for removing polling. I have 2 other general concerns for rmi_bus: - interrupts: the current implementation has 2 type of interrupt handling depending on the transport driver: either generic irqs or specific ones that are triggered by the transport driver. I think it would make sense to remove the generic irq handling in rmi4_bus and let the transport driver handle it. This way, it will be easier for the transport driver to decide whether or not forwarding the interrupts to the bus. This is what is done with the HID bus for the record. The transport driver calls hid_input_report() when an irq has been processed. - suspend/resume: with the smbus implementation, we have quite some troubles with the suspend/resume part. The reason is that both the rmi_bus and the serio bus are registering to the pm subsystem and this leads to races between them. Our current solution is to disable the pm registering in rmi_bus and let the transport driver handle it at his level (which is in fine triggered by the serio pm resume actually, not its own pm registration). I wonder if having the pm functions directly in the bus is a good idea and if we should not let the transport driver handle those. We should still keep the rmi specific functions in rmi_core/bus, I am just talking about the registration of the bus to the subsystem. [just thinking out loud: maybe we encounter problems of ordering due to the fact that the bus is registered to the pm subsystem. Maybe if the device itself in the transport driver registers, there will be guarantee that the serio resume is called before the rmi_smbus one, which would solve our problems]. Cheers, Benjamin > > 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 > > .../bindings/input/rmi4/rmi_2d_sensor.txt | 55 + > .../devicetree/bindings/input/rmi4/rmi_f01.txt | 40 + > .../devicetree/bindings/input/rmi4/rmi_i2c.txt | 53 + > .../devicetree/bindings/input/rmi4/rmi_spi.txt | 57 + > .../devicetree/bindings/vendor-prefixes.txt|1 + > drivers/hid/hid-rmi.c | 922 ++--- > drivers/input/Kconfig |2 + > drivers/input/Makefile |2 + > drivers/input/rmi4/Kconfig | 94 ++ > drivers/input/rmi4/Makefile| 15 + > drive
Re: [kernel-hardening] [PATCH 0/2] introduce post-init read-only memory
* PaX Team wrote: > On 26 Nov 2015 at 9:54, Ingo Molnar wrote: > > > * PaX Team wrote: > > > > > actually the kernel could silently recover from this given how the page > > > fault > > > handler could easily determine that the fault address fell into the > > > data..read_only section and just silently undo the read-only property, > > > log the > > > event to dmesg and retry the faulting access. > > > > So a safer method would be to decode the faulting instruction, to skip it > > by > > fixing up the return RIP and to log the event. It would be mostly > > equivalent > > to trying to write to ROM (which get ignored as well), so it's a > > recoverable > > (and debuggable) event. > > if by skipping you mean ignoring the write attempt then it's not a good idea > as > it has a good chance to cause unexpected behaviour down the line. > > e.g., imagine that the write was to a function pointer (even an entire ops > structure) or a boolean that controls some important feature for after-init > code. ignoring/dropping such writes could cause all kinds of logic bugs (if > not > worse). Well, the typical case is that it's a logic bug to _do_ the write: the structure was marked readonly for a reason but some init code re-runs during suspend or so. But yes, logic bugs might trigger - but that is true in the opposite case as well, if we do the write despite it being marked readonly: > my somewhat related war story is that i once tried to constify machine_ops > (both > the struct and the variable of the same name) directly and just forced the > writes in kvm/xen/etc via type casts. now i knew it was all undefined > behaviour > but i didn't expect gcc to take advantage of it but it did (const propagated > the > *initial* fptr values into the indirect calls by turning them into direct > calls) > and which in turn prevented proper reboots for guests (an event which > obviously > happens much later after init/boot to the great puzzlement of end users and > myself). > > misusing __read_only and ignoring write attempts would effectively produce > the > same misbehaviour as above so i strongly advise against it. No, the difference to the GCC related aliasing bug is that with my technique the kernel would immediately produce a very visible kernel warning, which is a very clear sign that is wrong - and with a very clear backtrace in the warning that points right to the problematic code - which signature shows us (and users) what is wrong. So your example is not comparable at all. Plus the truly paranoid might panic/halt the system on such warnings, so for highly secure systems there's a way to not even allow the possibility of logic bugs. (at the cost of stopping the system when a bug triggers.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 7/9] mm, page_owner: dump page owner info from dump_page()
On 11/25/2015 03:58 PM, Michal Hocko wrote:
> Nice! This can be really helpful.
>
>> Signed-off-by: Vlastimil Babka
>
> Appart from a typo below, looks good to me
> Acked-by: Michal Hocko
Thanks!
> [...]
>
>> +void __dump_page_owner(struct page *page)
>> +{
>> +struct page_ext *page_ext = lookup_page_ext(page);
>> +struct stack_trace trace = {
>> +.nr_entries = page_ext->nr_entries,
>> +.entries = &page_ext->trace_entries[0],
>> +};
>> +gfp_t gfp_mask = page_ext->gfp_mask;
>> +int mt = gfpflags_to_migratetype(gfp_mask);
>> +
>> +if (!test_bit(PAGE_EXT_OWNER, &page_ext->flags)) {
>> +pr_alert("page_owner info is not active (free page?)\n");
>> +return;
>> +}
>> +;
>
> Typo?
The cat did it!
--8<--
From: Vlastimil Babka
Date: Thu, 26 Nov 2015 11:41:11 +0100
Subject: mm, page_owner: dump page owner info from dump_page()-fix
Remove stray semicolon.
---
mm/page_owner.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/page_owner.c b/mm/page_owner.c
index a81cfa0c13c3..f4acd2452c35 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -207,7 +207,7 @@ void __dump_page_owner(struct page *page)
pr_alert("page_owner info is not active (free page?)\n");
return;
}
- ;
+
pr_alert("page allocated via order %u, migratetype %s, gfp_mask 0x%x",
page_ext->order, migratetype_names[mt], gfp_mask);
dump_gfpflag_names(gfp_mask);
--
2.6.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: MPT2SAS boot fail... due to silently loosing the driver
* Martin K. Petersen wrote: > > "Peter" == Peter Zijlstra writes: > > Peter> Please either create a fake MPT2SAS config that selects the > Peter> MPT3SAS driver, or rename the whole thing to MPT23SAS such that > Peter> we at least get a relevant question on oldconfig. > > Sorry about that, Peter. > > I get bitten by oldconfig all the time so I have a script to manage all > my configs. But it it would be nice if we had a way to express config > options transitions in kbuild. > > I guess we could do something like the following and let it sit for a > release cycle to help people transition. Bit of a hack, but it worked > for me in my quick testing... > > -- > Martin K. PetersenOracle Linux Engineering > > diff --git a/drivers/scsi/mpt3sas/Kconfig b/drivers/scsi/mpt3sas/Kconfig > index 29061467cc17..901c97f1e368 100644 > --- a/drivers/scsi/mpt3sas/Kconfig > +++ b/drivers/scsi/mpt3sas/Kconfig > @@ -48,6 +48,13 @@ config SCSI_MPT3SAS > ---help--- > This driver supports PCI-Express SAS 12Gb/s Host Adapters. > > +config SCSI_MPT2SAS > + tristate > + default n > + select SCSI_MPT3SAS > + ---help--- > + Dummy config option for backwards compatiblity. So I don't think this does what you expect it to do: non-interactive options will be set to their defaults, regardless of what's in the oldconfig. So you need to make it interactive, with a short help text that explains to users that this is legacy option only, and that they should enable the MPT3SAS option if they want to configure things manually. i.e. something like: +config SCSI_MPT2SAS + tristate "Legacy MPT2SAS config option" + default n + select SCSI_MPT3SAS + ---help--- + Dummy config option for backwards compatiblity: configure the MPT3SAS + driver instead. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
