[PATCH v2 1/2] soc/fsl: add freescale dir for SOC specific drivers
From: Wang Dongsheng Some Freescale device drivers need to move to soc/, because these drivers are specific drivers. Before the soc/ to be created, the drivers had been there arch/ or drivers/misc/, but now soc/ dir is a better choice. Signed-off-by: Wang Dongsheng --- *V2* Rebase for last kernel. Resend this patch, this patch is one year ago. Sorry I haven't had the time to push this patch before. diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 96ddecb..b5c5179 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -5,5 +5,6 @@ source "drivers/soc/qcom/Kconfig" source "drivers/soc/sunxi/Kconfig" source "drivers/soc/ti/Kconfig" source "drivers/soc/versatile/Kconfig" +source "drivers/soc/fsl/Kconfig" endmenu diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 7dc7c0d..1caf1d6 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -8,3 +8,4 @@ obj-$(CONFIG_ARCH_SUNXI)+= sunxi/ obj-$(CONFIG_ARCH_TEGRA) += tegra/ obj-$(CONFIG_SOC_TI) += ti/ obj-$(CONFIG_PLAT_VERSATILE) += versatile/ +obj-$(CONFIG_FSL_SOC_DRIVERS) += fsl/ diff --git a/drivers/soc/fsl/Kconfig b/drivers/soc/fsl/Kconfig new file mode 100644 index 000..863d1ef --- /dev/null +++ b/drivers/soc/fsl/Kconfig @@ -0,0 +1,18 @@ +# +# Freescale SOC drivers +# +menuconfig FSL_SOC_DRIVERS + bool "Freescale Soc Drivers" + default n + help + Say y here to enable Freescale Soc Device Drivers support. + The Soc Drivers provides the device driver that is a specific + block or feature on Freescale platform. + +if FSL_SOC_DRIVERS + +if ARM +source "drivers/soc/fsl/Kconfig.arm" +endif + +endif diff --git a/drivers/soc/fsl/Kconfig.arm b/drivers/soc/fsl/Kconfig.arm new file mode 100644 index 000..8c90b82 --- /dev/null +++ b/drivers/soc/fsl/Kconfig.arm @@ -0,0 +1,16 @@ +# +# Freescale ARM SOC Drivers +# + +config LS1_SOC_DRIVERS + bool "LS1021A Soc Drivers" + depends on SOC_LS1021A + default n + help + Say y here to enable Freescale LS1021A Soc Device Drivers support. + The Soc Drivers provides the device driver that is a specific block + or feature on LS1021A platform. + +if LS1_SOC_DRIVERS + source "drivers/soc/fsl/ls1/Kconfig" +endif diff --git a/drivers/soc/fsl/Makefile b/drivers/soc/fsl/Makefile new file mode 100644 index 000..b4215dd --- /dev/null +++ b/drivers/soc/fsl/Makefile @@ -0,0 +1,6 @@ +# +# Makefile for Freescale Soc specific device drivers. +# + +obj-$(CONFIG_LS1_SOC_DRIVERS) += ls1/ + diff --git a/drivers/soc/fsl/ls1/Kconfig b/drivers/soc/fsl/ls1/Kconfig new file mode 100644 index 000..7556f44 --- /dev/null +++ b/drivers/soc/fsl/ls1/Kconfig @@ -0,0 +1,3 @@ +# +# LS-1 Soc drivers +# -- 2.1.0.27.g96db324 -- 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/2] soc/fsl: add ftm alarm driver for ls1021a platform
From: Wang Dongsheng
Only Ftm0 can be used when system going to deep sleep. So this driver
to support ftm0 as a wakeup source.
Signed-off-by: Wang Dongsheng
---
*V2*
Change Copyright 2014 to 2015.
diff --git a/drivers/soc/fsl/ls1/Kconfig b/drivers/soc/fsl/ls1/Kconfig
index 7556f44..e6282dc 100644
--- a/drivers/soc/fsl/ls1/Kconfig
+++ b/drivers/soc/fsl/ls1/Kconfig
@@ -1,3 +1,11 @@
#
# LS-1 Soc drivers
#
+config FTM_ALARM
+ bool "FTM alarm driver"
+ depends on SOC_LS1021A
+ default n
+ help
+ Say y here to enable FTM alarm support. The FTM alarm provides
+ alarm functions for wakeup system from deep sleep. There is only
+ one FTM can be used in ALARM(FTM 0).
diff --git a/drivers/soc/fsl/ls1/Makefile b/drivers/soc/fsl/ls1/Makefile
new file mode 100644
index 000..6299aa1
--- /dev/null
+++ b/drivers/soc/fsl/ls1/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_FTM_ALARM) += ftm_alarm.o
diff --git a/drivers/soc/fsl/ls1/ftm_alarm.c b/drivers/soc/fsl/ls1/ftm_alarm.c
new file mode 100644
index 000..f7629cd
--- /dev/null
+++ b/drivers/soc/fsl/ls1/ftm_alarm.c
@@ -0,0 +1,272 @@
+/*
+ * Freescale FlexTimer Module (FTM) Alarm driver.
+ *
+ * Copyright 2015 Freescale Semiconductor, Inc.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define FTM_SC 0x00
+#define FTM_SC_CLK_SHIFT 3
+#define FTM_SC_CLK_MASK(0x3 << FTM_SC_CLK_SHIFT)
+#define FTM_SC_CLK(c) ((c) << FTM_SC_CLK_SHIFT)
+#define FTM_SC_PS_MASK 0x7
+#define FTM_SC_TOIEBIT(6)
+#define FTM_SC_TOF BIT(7)
+
+#define FTM_SC_CLKS_FIXED_FREQ 0x02
+
+#define FTM_CNT0x04
+#define FTM_MOD0x08
+#define FTM_CNTIN 0x4C
+
+#define FIXED_FREQ_CLK 32000
+#define MAX_FREQ_DIV (1 << FTM_SC_PS_MASK)
+#define MAX_COUNT_VAL 0x
+
+static void __iomem *ftm1_base;
+static u32 alarm_freq;
+static bool big_endian;
+
+static inline u32 ftm_readl(void __iomem *addr)
+{
+ if (big_endian)
+ return ioread32be(addr);
+
+ return ioread32(addr);
+}
+
+static inline void ftm_writel(u32 val, void __iomem *addr)
+{
+ if (big_endian)
+ iowrite32be(val, addr);
+ else
+ iowrite32(val, addr);
+}
+
+static inline void ftm_counter_enable(void __iomem *base)
+{
+ u32 val;
+
+ /* select and enable counter clock source */
+ val = ftm_readl(base + FTM_SC);
+ val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+ val |= (FTM_SC_PS_MASK | FTM_SC_CLK(FTM_SC_CLKS_FIXED_FREQ));
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_counter_disable(void __iomem *base)
+{
+ u32 val;
+
+ /* disable counter clock source */
+ val = ftm_readl(base + FTM_SC);
+ val &= ~(FTM_SC_PS_MASK | FTM_SC_CLK_MASK);
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_acknowledge(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val &= ~FTM_SC_TOF;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_enable(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val |= FTM_SC_TOIE;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_irq_disable(void __iomem *base)
+{
+ u32 val;
+
+ val = ftm_readl(base + FTM_SC);
+ val &= ~FTM_SC_TOIE;
+ ftm_writel(val, base + FTM_SC);
+}
+
+static inline void ftm_reset_counter(void __iomem *base)
+{
+ /*
+* The CNT register contains the FTM counter value.
+* Reset clears the CNT register. Writing any value to COUNT
+* updates the counter with its initial value, CNTIN.
+*/
+ ftm_writel(0x00, base + FTM_CNT);
+}
+
+static u32 time_to_cycle(unsigned long time)
+{
+ u32 cycle;
+
+ cycle = time * alarm_freq;
+ if (cycle > MAX_COUNT_VAL) {
+ pr_err("Out of alarm range.\n");
+ cycle = 0;
+ }
+
+ return cycle;
+}
+
+static u32 cycle_to_time(u32 cycle)
+{
+ return cycle / alarm_freq + 1;
+}
+
+static void ftm_clean_alarm(void)
+{
+ ftm_counter_disable(ftm1_base);
+
+ ftm_writel(0x00, ftm1_base + FTM_CNTIN);
+ ftm_writel(~0UL, ftm1_base + FTM_MOD);
+
+ ftm_reset_counter(ftm1_base);
+}
+
+static int ftm_set_alarm(u64 cycle)
+{
+ ftm_irq_disable(ftm1_base);
+
+ /*
+* The counter increments until the value of MOD is reached,
+* at which point the counter is reloaded with the value of CNTIN.
+* The TOF (the overflow flag) bit is set when the FTM counter
+
Re: [PATCH v2 1/2] perf hists browser: Support horizontal scrolling with '<' and '>' key
Hi Arnaldo, On Tue, Aug 11, 2015 at 05:59:28PM -0300, Arnaldo Carvalho de Melo wrote: > Em Tue, Aug 11, 2015 at 01:15:59AM +0200, Jiri Olsa escreveu: > > On Mon, Aug 10, 2015 at 08:14:45PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Aug 11, 2015 at 01:02:56AM +0200, Jiri Olsa escreveu: > > > > On Mon, Aug 10, 2015 at 07:58:22PM -0300, Arnaldo Carvalho de Melo > > > > wrote: > > > > > > it'd really help for perf mem output, which is quite wide.. and we > > > > > > probably > > > > > > have more wide outputs, or users with narrow terminals ;-) > > > > > > I'm not going against horizontal scrolling, it is needed, sure thing, > > > > > its surprising we are doing this only now. What I am asking is this > > > > > fine > > > > > scrolling of one column per <- or -> keypress, but I really need to > > > > > try > > > > > it with things like 'perf mem', I thought that when you pressed '>', > > > > > in > > > > > this patch, it would move entire sort key columns, not just one > > > > > vertical > > > > > column one character wide, right? > > > > > yep, the whole sort column seemed more usefull, > > So, that wasn't what was implemented in Namhyung's patchkit, right? I.e. > it scrolls characters, not columns. My last patch already implemented the scrolling by columns as well as characters. > > Can you take a look at the patchkit I put together at my tree, branch: > > tmp.perf/ui_browser.horiz_scroll > > https://git.kernel.org/cgit/linux/kernel/git/acme/linux.git/log/?h=tmp.perf/ui_browser.horiz_scroll > > The last two patches do it: > > $ git log --oneline | head -2 You can simply use 'git log --oneline -2'. :) > 8a7684de198b perf hists browser: Implement horizontal scrolling > a00e506da09e perf ui browser: Optional horizontal scrolling key binding > $ > > $ git diff HEAD^^ --stat >tools/perf/ui/browser.c| 14 ++ >tools/perf/ui/browser.h| 2 +- >tools/perf/ui/browsers/hists.c | 22 +- >3 files changed, 32 insertions(+), 6 deletions(-) > $ Looks good. It's much simpler than mine and I think it's good if we decided to support only column scrolling. > > Several lines are just comments explaining some tricks due to me not > having found a counter for the number of colums somewhere and reusing > the first loop that traverses them all to do the counting. > > There are two before those that at first I thought was needed, but ended > up not using (would have to render the whole line in ui_browser to do > the scrolling at line printing time, works only for browsers where just > one call to ui_browser__printf or ui_browser__write_nstring is done, > but I ended up leaving it there anyway, to try to make the > hist_browser.c and other ui_browser implementations (annotate, etc) > independent of libslang: > > $ git log --oneline | head -4 | tail -2 > e7534e88dfa3 perf ui browser: Introduce ui_browser__printf() > 2fe0f7e4b73e perf ui browser: Introduce ui_browser__write_nstring() > $ > > Tested it with 'perf mem record -g -a' + 'perf mem report', and I liked > how it works, please check if you like it too :-) > > The <- and -> keys are reused just when the horizontal scrolling mode is > activate by setting ui_browser->columns, the hists_browser (perf report, > perf top) will continue having ENTER and ESC, as always, to > select/deselect things. Currently the help message in the hist browser says the arrows keys are used to zoom in & out and ESC is for 'exit browser'. Do you think it's ok to change the current behavior? > > If we insist we need character by character scrolling, or if we need > that move in other browser (annotate, for instance) its just a matter of > using ui_browser->horiz_scroll as a char counter and use it in the > ui_browser->refresh() calls when rendering each line. Yes, I think it's needed and it'd be great if other browsers support it. Thanks, Namhyung -- 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: linux-next: manual merge of the crypto tree with the imx-mxs tree
Herbert,
On Wed, Aug 12, 2015 at 1:18 PM, Herbert Xu wrote:
> On Wed, Aug 12, 2015 at 01:22:39PM +1000, Stephen Rothwell wrote:
>>
>> Today's linux-next merge of the crypto tree got a conflict in:
>>
>> arch/arm/configs/imx_v6_v7_defconfig
>>
>> between commit:
>>
>> 351265f46291 ("ARM: imx_v6_v7_defconfig: build in audio driver")
>>
>> from the imx-mxs tree and commit:
>>
>> ab86ca0755ec ("ARM: imx_v6_v7_defconfig: Select CAAM")
>>
>> from the crypto tree.
>>
>> I fixed it up (they both removed the same line) and can carry the fix
>> as necessary (no action is required).
Please leave i.MX architecture patches (i.MX patches under arch/arm/)
to me to handle in the future, so that we can avoid such unnecessary
merge conflict.
Shawn
--
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 v5 0/3] dra7xx: Add PM support to PCIe
On Wednesday 12 August 2015 02:22 AM, Bjorn Helgaas wrote: > On Fri, Jul 31, 2015 at 05:55:09PM +0530, Kishon Vijay Abraham I wrote: >> This series adds PM support to pci-dra7xx so that PCI clocks can be disabled >> during suspend and enabled back during resume without affecting >> PCI functionality. >> >> Changes from v4: >> *) Fixed a bug caused by sending incomplete patch. >> >> Changes from v3: >> *) Fix compilation errors when individual patches are applied >> >> Changes from v2: >> *) Used SET_SYSTEM_SLEEP_PM_OPS and SET_NOIRQ_SYSTEM_SLEEP_PM_OPS for >>populating PM ops. >> >> Changes from v1: >> *) Moved resetting and setting of MSE bit to pci-dra7xx. >> >> The comment to reset and set ISE is not done now since I don't have a card >> with IO space. Once I get to test that, I'll post a separate patch for >> handling that. >> >> Kishon Vijay Abraham I (3): >> PCI: host: pci-dra7xx: Disable pm_runtime on get_sync failure >> PCI: host: pci-dra7xx: add pm support to pci dra7xx >> PCI: host: pci-dra7xx: Idle the module by disabling MSE bit >> >> drivers/pci/host/pci-dra7xx.c | 95 >> - >> 1 file changed, 94 insertions(+), 1 deletion(-) > > Applied with Jingoo's Reviewed-by to pci/host-dra7xx for v4.3, thanks! > > I tweaked the changelogs as follows: > > > commit 0e2bdb0e7abf4b5170874e415ec42df547916dd3 > Author: Kishon Vijay Abraham I > Date: Fri Jul 31 17:55:10 2015 +0530 > > PCI: dra7xx: Disable pm_runtime on get_sync failure > > Fix the error handling when pm_runtime_get_sync() fails. > > If pm_runtime_get_sync() fails, call pm_runtime_disable() so there are no > unbalanced pm_runtime_enable() calls. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Bjorn Helgaas > Reviewed-by: Jingoo Han > > commit e52eb445ea1d97bf7fb92d2297e487a305392136 > Author: Kishon Vijay Abraham I > Date: Fri Jul 31 17:55:11 2015 +0530 > > PCI: dra7xx: Add PM support > > Add PM support to pci-dra7xx so PCI clocks can be disabled during suspend > and enabled during resume without affecting PCI functionality. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Bjorn Helgaas > Reviewed-by: Jingoo Han > > commit 389c7094ec241ee8ebe358ba10fe392018692c8c > Author: Kishon Vijay Abraham I > Date: Fri Jul 31 17:55:12 2015 +0530 > > PCI: dra7xx: Clear MSE bit during suspend so clocks will idle > > DRA7xx requires the MSE bit to be cleared to set the master in standby > mode. (In DRA7xx TRM_vE, section 24.9.4.5.2.2.1 PCIe Controller Master > Standby Behavior advises to use the clearing of the local MSE bit to set > the master in standby. Without this some of the clocks do not idle). > > Clear the MSE bit on suspend and enable it on resume. Clearing MSE bit is > required to get clocks to be idled after suspend. > > Signed-off-by: Kishon Vijay Abraham I > Signed-off-by: Sekhar Nori > Signed-off-by: Bjorn Helgaas > Reviewed-by: Jingoo Han Thanks Bjorn! -Kishon -- 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: [llvm-dev] llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On 2015/8/12 12:57, Alexei Starovoitov wrote:
On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote:
Think about a program like this:
struct strA { int a; }
struct strB { int b; }
int func() {
struct strA a;
struct strB b;
a.a = 1;
b.b = 2;
bpf_output(gettype(a), );
bpf_output(gettype(b), );
return 0;
}
BPF backend can't (and needn't) tell the difference between local
variables a and b in theory. In LLVM implementation, it filters type
information out using ComputeValueVTs(). Please have a look at
SelectionDAGBuilder::visitIntrinsicCall in
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp and
SelectionDAGBuilder::visitTargetIntrinsic in the same file. in
visitTargetIntrinsic, ComputeValueVTs acts as a barrier which strips
type information out from CallInst ("I"), and leave SDValue and SDVTList
("Ops" and "VTs") to target code. SDValue and SDVTList are wrappers of
EVT and MVT, all information we concern won't be passed here.
I think now we have 2 choices:
1. Hacking into clang, implement target specific builtin function. Now I
have worked out a ugly but workable patch which setup a builtin function:
__builtin_bpf_typeid(), which accepts local or global variable then
returns different constant for different types.
2. Implementing an LLVM intrinsic call (llvm.typeid), make it be processed
in
visitIntrinsicCall(). I think we can get something useful if it is
processed
with that function.
Yeah. You're right about pure target intrinsics.
I think llvm.typeid might work. imo it's cleaner than
doing it at clang level.
The next thing should be generating debug information to map type and
constants which issued by __builtin_bpf_typeid() or llvm.typeid. Now we
have a crazy idea that, if we limit the name of the structure to 8 bytes,
we can insert the name into a u64, then there would be no need to consider
type information in DWARF. For example, in the above sample code, gettype(a)
will issue 0x41727473 because its type is "strA". What do you think?
that's way too hacky.
I was thinking when compiling we can keep llvm ir along with .o
instead of dwarf and extract type info from there.
dwarf has names and other things that we don't need. We only
care about actual field layout of the structs.
But it probably won't be easy to parse llvm ir on perf side
instead of dwarf.
Shipping both llvm IR and .o to perf makes it harder to use. I'm
not sure whether it is a good idea. If we are unable to encode the
structure using a u64, let's still dig into dwarf.
We have another idea that we can utilize dwarf's existing feature.
For example, when __buildin_bpf_typeid() get called, define an enumerate
type in dwarf info, so you'll find:
<1><2a>: Abbrev Number: 2 (DW_TAG_enumeration_type)
<2b> DW_AT_name: (indirect string, offset: 0xec): TYPEINFO
<2f> DW_AT_byte_size : 4
<30> DW_AT_decl_file : 1
<31> DW_AT_decl_line : 3
<2><32>: Abbrev Number: 3 (DW_TAG_enumerator)
<33> DW_AT_name: (indirect string, offset: 0xcc):
__typeinfo_strA
<37> DW_AT_const_value : 2
<2><38>: Abbrev Number: 3 (DW_TAG_enumerator)
<39> DW_AT_name: (indirect string, offset: 0xdc):
__typeinfo_strB
<3d> DW_AT_const_value : 3
or this:
<3><54>: Abbrev Number: 4 (DW_TAG_variable)
<55> DW_AT_const_value : 2
<66> DW_AT_name: (indirect string, offset: 0x1e):
__typeinfo_strA
<6a> DW_AT_decl_file : 1
<6b> DW_AT_decl_line : 29
<6c> DW_AT_type: <0x72>
then from DW_AT_name and DW_AT_const_value we can do the mapping.
Drawback is that
all __typeinfo_ prefixed names become reserved.
btw, if you haven't looked at iovisor/bcc, there we're solving
similar problem differently. There we use clang rewriter, so all
structs fields are visible at this level, then we use bpf backend
in JIT mode and push bpf instructions into the kernel on the fly
completely skipping ELF and .o
For example in:
https://github.com/iovisor/bcc/blob/master/examples/distributed_bridge/tunnel.c
when you see
struct ethernet_t {
unsigned long long dst:48;
unsigned long long src:48;
unsigned inttype:16;
} BPF_PACKET_HEADER;
struct ethernet_t *ethernet = cursor_advance(cursor, sizeof(*ethernet));
... ethernet->src ...
is recognized by clang rewriter and ->src is converted to a different
C code that is sent again into clang.
So there is no need to use dwarf or patch clang/llvm. clang rewriter
has all the info.
Could you please give us further information about your clang rewriter?
I guess you need a new .so when injecting those code into kernel?
I'm not sure you can live with clang/llvm on the host where you
want to run the tracing bits, but if you can that's an easier option.
I'm not sure. Our target platform should be embedded devices like
smartphone.
Bringing full clang/llvm environment there is not acceptable.
Thank you.
--
To unsubscribe from this list:
Re: [PATCH V11 4/5] arm64: apei: implement arch_apei_get_mem_attributes()
On 11 August 2015 at 23:57, Matt Fleming wrote:
> On Sat, 08 Aug, at 10:18:52AM, Jonathan (Zhixiong) Zhang wrote:
>> From: "Jonathan (Zhixiong) Zhang"
>>
>> Table 8 of UEFI 2.5 section 2.3.6.1 defines mappings from EFI
>> memory types to MAIR attribute encodings for arm64.
>>
>> If the physical address has memory attributes defined by EFI
>> memmap as EFI_MEMORY_[UC|WC|WT], return approprate page protection
>> type according to the UEFI spec. Otherwise, return PAGE_KERNEL.
>>
>> Reviewed-by: Catalin Marinas
>> Acked-by: Hanjun Guo
>> Signed-off-by: Jonathan (Zhixiong) Zhang
>> ---
>> arch/arm64/include/asm/acpi.h | 30 ++
>> 1 file changed, 30 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
>> index 614096732839..b77a2d133da9 100644
>> --- a/arch/arm64/include/asm/acpi.h
>> +++ b/arch/arm64/include/asm/acpi.h
>> @@ -19,6 +19,11 @@
>> #include
>> #include
>>
>> +#ifdef CONFIG_ACPI_APEI
>> +#include
>> +#include
>> +#endif
>> +
>> /* Macros for consistency checks of the GICC subtable of MADT */
>> #define ACPI_MADT_GICC_LENGTH\
>> (acpi_gbl_FADT.header.revision < 6 ? 76 : 80)
>> @@ -91,4 +95,29 @@ static inline const char *acpi_get_enable_method(int cpu)
>> {
>> return acpi_psci_present() ? "psci" : NULL;
>> }
>> +
>> +#ifdef CONFIG_ACPI_APEI
>> +static inline pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr)
>> +{
>> + /*
>> + * According to "Table 8 Map: EFI memory types to AArch64 memory types"
>> + * of UEFI 2.5 section 2.3.6.1, each EFI memory type is mapped to
>> + * corresponding MAIR attribute encoding.
>> + * The EFI memory attribute advises all possible capabilities of a
>> + * memory region. We use the most efficient capability.
>> + */
>> +
>> + u64 attr;
>> +
>> + attr = efi_mem_attributes(addr);
>> + if (attr & EFI_MEMORY_WB)
>> + return PAGE_KERNEL;
>> + if (attr & EFI_MEMORY_WT)
>> + return __pgprot(PROT_NORMAL_WT);
>> + if (attr & EFI_MEMORY_WC)
>> + return __pgprot(PROT_NORMAL_NC);
>> + return __pgprot(PROT_DEVICE_nGnRnE);
>> +}
>> +#endif
>> +
>> #endif /*_ASM_ACPI_H*/
>
> Everyone happy with this change? Ard?
>
Yes, this looks fine. As long as any region that has the EFI_MEMORY_WB
attribute gets mapped as PAGE_KERNEL, we know we won't be violating
any architectural mismatched attributes constraints (since all
EFI_MEMORY_WB regions, even the occupied ones, are covered by the
kernel direct mapping as well)
For the other ones, it is merely an optimization, but arguably still
an improvement.
Reviewed-by: Ard Biesheuvel
Thanks,
Ard.
--
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] serial: max310x: Fix out of bounds access
Max310x driver supports up to 4 UART devices but array size of
"struct max310x_one" is set to 1. That leads to out of bounds
access on UART port registration.
This patch fixed it by increase the array size to 4 which is
maximum supported UART.
---
drivers/tty/serial/max310x.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/max310x.c b/drivers/tty/serial/max310x.c
index 182549f..b523552 100644
--- a/drivers/tty/serial/max310x.c
+++ b/drivers/tty/serial/max310x.c
@@ -33,6 +33,9 @@
#define MAX310X_MAJOR 204
#define MAX310X_MINOR 209
+/* Maximum supported device */
+#define MAX_DEVICE 4
+
/* MAX310X register definitions */
#define MAX310X_RHR_REG(0x00) /* RX FIFO */
#define MAX310X_THR_REG(0x00) /* TX FIFO */
@@ -273,7 +276,7 @@ struct max310x_port {
#ifdef CONFIG_GPIOLIB
struct gpio_chipgpio;
#endif
- struct max310x_one p[0];
+ struct max310x_one p[MAX_DEVICE];
};
static u8 max310x_port_read(struct uart_port *port, u8 reg)
--
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: [Qemu-devel] [PATCH 19/23] userfaultfd: activate syscall
On Tue, Aug 11, 2015 at 03:48:26PM +0200, Andrea Arcangeli wrote: > Hello Bharata, > > On Tue, Aug 11, 2015 at 03:37:29PM +0530, Bharata B Rao wrote: > > May be it is a bit late to bring this up, but I needed the following fix > > to userfault21 branch of your git tree to compile on powerpc. > > Not late, just in time. I increased the number of syscalls in earlier > versions, it must have gotten lost during a rejecting rebase, sorry. > > I applied it to my tree and it can be applied to -mm and linux-next, > thanks! > > The syscall for arm32 are also ready and on their way to the arm tree, > the testsuite worked fine there. ppc also should work fine if you > could confirm it'd be interesting, just beware that I got a typo in > the testcase: The testsuite passes on powerpc. running userfaultfd nr_pages: 2040, nr_pages_per_cpu: 170 bounces: 31, mode: rnd racing ver poll, userfaults: 80 43 23 23 15 16 12 1 2 96 13 128 bounces: 30, mode: racing ver poll, userfaults: 35 54 62 49 47 48 2 8 0 78 1 0 bounces: 29, mode: rnd ver poll, userfaults: 114 153 70 106 78 57 143 92 114 96 1 0 bounces: 28, mode: ver poll, userfaults: 96 81 5 45 83 19 98 28 1 145 23 2 bounces: 27, mode: rnd racing poll, userfaults: 54 65 60 54 45 49 1 2 1 2 71 20 bounces: 26, mode: racing poll, userfaults: 90 83 35 29 37 35 30 42 3 4 49 6 bounces: 25, mode: rnd poll, userfaults: 52 50 178 112 51 41 23 42 18 99 59 0 bounces: 24, mode: poll, userfaults: 136 101 83 260 84 29 16 88 1 6 160 57 bounces: 23, mode: rnd racing ver, userfaults: 141 197 158 183 39 49 3 52 8 3 6 0 bounces: 22, mode: racing ver, userfaults: 242 266 244 180 162 32 87 43 31 40 34 0 bounces: 21, mode: rnd ver, userfaults: 636 158 175 24 253 104 48 8 0 0 0 0 bounces: 20, mode: ver, userfaults: 531 204 225 117 129 107 11 143 76 31 1 0 bounces: 19, mode: rnd racing, userfaults: 303 169 225 145 59 219 37 0 0 0 0 0 bounces: 18, mode: racing, userfaults: 374 372 37 144 126 90 25 12 15 17 0 0 bounces: 17, mode: rnd, userfaults: 313 412 134 108 80 99 7 56 85 0 0 0 bounces: 16, mode:, userfaults: 431 58 87 167 120 113 98 60 14 8 48 0 bounces: 15, mode: rnd racing ver poll, userfaults: 41 40 25 28 37 24 0 0 0 0 180 75 bounces: 14, mode: racing ver poll, userfaults: 43 53 30 28 25 15 19 0 0 0 0 30 bounces: 13, mode: rnd ver poll, userfaults: 136 91 114 91 92 79 114 77 75 68 1 2 bounces: 12, mode: ver poll, userfaults: 92 120 114 76 153 75 132 157 83 81 10 1 bounces: 11, mode: rnd racing poll, userfaults: 50 72 69 52 53 48 46 59 57 51 37 1 bounces: 10, mode: racing poll, userfaults: 33 49 38 68 35 63 57 49 49 47 25 10 bounces: 9, mode: rnd poll, userfaults: 167 150 67 123 39 75 1 2 9 125 1 1 bounces: 8, mode: poll, userfaults: 147 102 20 87 5 27 118 14 104 40 21 28 bounces: 7, mode: rnd racing ver, userfaults: 305 254 208 74 59 96 36 14 11 7 4 5 bounces: 6, mode: racing ver, userfaults: 290 114 191 94 162 114 34 6 6 32 23 2 bounces: 5, mode: rnd ver, userfaults: 370 381 22 273 21 106 17 55 0 0 0 0 bounces: 4, mode: ver, userfaults: 328 279 179 191 74 86 95 15 13 10 0 0 bounces: 3, mode: rnd racing, userfaults: 222 215 164 70 5 20 179 0 34 3 0 0 bounces: 2, mode: racing, userfaults: 316 385 112 160 225 5 30 49 42 2 4 0 bounces: 1, mode: rnd, userfaults: 273 139 253 176 163 71 85 2 0 0 0 0 bounces: 0, mode:, userfaults: 165 212 633 13 24 66 24 27 15 0 10 1 [PASS] Regards, Bharata. -- 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/
Information on Winning prize
-- Dear Facebook Winner, We Have Received your Response and would like to congratulate you once again. You have just won yourself the sum of £800,000 (Eight Hundred Thousand British Pounds Sterling) in the ongoing Facebook 2015 Lottery Promotion. Further more your details( Facebook account) falls within our British representative office in London UK, and your prize of £800,000 will be released to you from our regional branch office in LONDON, UK. Kindly have a look at our Founders 2012 charity donation which is happening again this year and you have been selected as a lucky winner: http://www.dailymail.co.uk/news/article-2277837/Mark-Zuckerberg-wife-Americas-second-biggest-philanthropists-giving-away-nearly-half-BILLION-dollars-year.html To proceed on your claim validation, we will need to verify that you are the actual owner of this Facebook Account. This is very important as we would be using your personal information to process your payment documents and Bank draft which would be couriered safely to your residential address. Here is a copy of our verification form; please fill accordingly so as to proceed with your winning validation. Please attach a recent passport photograph if available (For identification at payment point) 1. FULL NAMES: 2. DATE OF BIRTH: 3. SEX: 4. CONTACT ADDRESS: 5. EMAIL ADDRESS: 6. TELEPHONE NUMBER: 7. OCCUPATION: If you don't want to receive these emails from Facebook in the future, please unsubscribe. Facebook, Inc., Department 415, PO Box 10005, Palo Alto, CA 94303 Please if you are not the certified owner of this Email account, do not respond to this E-mail as it will amount to impersonation which could lead to civil and criminal proceedings against you. Upon receipt of the duly requested data which is to be sent via email, you will receive the contact information of the payment office to effect the release of your claim in anyway you deem fit.For further inquiry Email: lester.g...@aol.co.uk or call +447031987991 Ms. Maria Davies Fiduciary Agent -- 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: linux-next: manual merge of the crypto tree with the imx-mxs tree
On Wed, Aug 12, 2015 at 01:22:39PM +1000, Stephen Rothwell wrote:
>
> Today's linux-next merge of the crypto tree got a conflict in:
>
> arch/arm/configs/imx_v6_v7_defconfig
>
> between commit:
>
> 351265f46291 ("ARM: imx_v6_v7_defconfig: build in audio driver")
>
> from the imx-mxs tree and commit:
>
> ab86ca0755ec ("ARM: imx_v6_v7_defconfig: Select CAAM")
>
> from the crypto tree.
>
> I fixed it up (they both removed the same line) and can carry the fix
> as necessary (no action is required).
Thanks Stephen.
--
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/
[PATCH v1] mmc: block: skip trim for some kingston eMMCs
For some mass production of kingston eMMCs which adopt Phison's
firmware will meet an unrecoverable data conrruption occasionally
if performing trim due to a firmware bug confirmed by vendor. We
found it on Intel-C3230RK platform. So we add fixup of broken trim
for it.
Signed-off-by: Shawn Lin
---
drivers/mmc/card/block.c | 11 +++
drivers/mmc/core/core.c | 3 ++-
include/linux/mmc/card.h | 2 ++
3 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index a58287e..48be57b 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -2389,6 +2389,7 @@ force_ro_fail:
#define CID_MANFID_TOSHIBA 0x11
#define CID_MANFID_MICRON 0x13
#define CID_MANFID_SAMSUNG 0x15
+#define CID_MANFID_KINGSTON0x70
static const struct mmc_fixup blk_fixups[] =
{
@@ -2422,6 +2423,7 @@ static const struct mmc_fixup blk_fixups[] =
MMC_FIXUP("MMC32G", CID_MANFID_TOSHIBA, CID_OEMID_ANY, add_quirk_mmc,
MMC_QUIRK_BLK_NO_CMD23),
+
/*
* Some Micron MMC cards needs longer data read timeout than
* indicated in CSD.
@@ -2451,6 +2453,15 @@ static const struct mmc_fixup blk_fixups[] =
MMC_FIXUP("VZL00M", CID_MANFID_SAMSUNG, CID_OEMID_ANY, add_quirk_mmc,
MMC_QUIRK_SEC_ERASE_TRIM_BROKEN),
+ /*
+* On Some Kingston eMMCs, performing trim can result in
+* unrecoverable data conrruption occasionally due to a firmware bug.
+*/
+ MMC_FIXUP("V10008", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_TRIM_BROKEN),
+ MMC_FIXUP("V10016", CID_MANFID_KINGSTON, CID_OEMID_ANY, add_quirk_mmc,
+ MMC_QUIRK_TRIM_BROKEN),
+
END_FIXUP
};
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 083cade..8bbcc42 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2251,7 +2251,8 @@ EXPORT_SYMBOL(mmc_can_erase);
int mmc_can_trim(struct mmc_card *card)
{
- if (card->ext_csd.sec_feature_support & EXT_CSD_SEC_GB_CL_EN)
+ if ((card->ext_csd.sec_feature_support & EXT_CSD_SEC_GB_CL_EN) &&
+ (!(card->quirks & MMC_QUIRK_TRIM_BROKEN)))
return 1;
return 0;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 8fcbcd1..fdd0779 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -279,6 +279,8 @@ struct mmc_card {
#define MMC_QUIRK_LONG_READ_TIME (1<<9)/* Data read time > CSD
says */
#define MMC_QUIRK_SEC_ERASE_TRIM_BROKEN (1<<10)/* Skip secure for
erase/trim */
#define MMC_QUIRK_BROKEN_IRQ_POLLING (1<<11) /* Polling SDIO_CCCR_INTx could
create a fake interrupt */
+#define MMC_QUIRK_TRIM_BROKEN (1<<12) /* Skip trim */
+
unsigned interase_size; /* erase size in sectors */
unsigned interase_shift;/* if erase unit is power 2 */
--
2.3.7
--
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 v1] mmc: block: Fix coding style issues
This patch fixes the following issues reported by checkpatch.pl:
- Missing a blank line after declarations
- line over 80 characters
- use kstrtoul instead of simple_strtoul to fix warning massage:
"simple_strtoul is obsolete, use kstrtoul instead"
- unnecessary braces {} for single statement blocks
- remove else statement to fix warning massage:
"else is not generally useful after a break or return"
- put open brace { on the previous line to fix warning massage:
"that open brace { should be on the previous line"
Signed-off-by: Shawn Lin
---
drivers/mmc/card/block.c | 62
1 file changed, 36 insertions(+), 26 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index a58287e..98b85a4 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -102,9 +102,12 @@ struct mmc_blk_data {
struct list_head part;
unsigned intflags;
-#define MMC_BLK_CMD23 (1 << 0)/* Can do SET_BLOCK_COUNT for
multiblock */
-#define MMC_BLK_REL_WR (1 << 1)/* MMC Reliable write support */
-#define MMC_BLK_PACKED_CMD (1 << 2)/* MMC packed command support */
+/* Can do SET_BLOCK_COUNT for multiblock */
+#define MMC_BLK_CMD23 (1 << 0)
+/* MMC Reliable write support */
+#define MMC_BLK_REL_WR (1 << 1)
+/* MMC packed command support */
+#define MMC_BLK_PACKED_CMD (1 << 2)
unsigned intusage;
unsigned intread_only;
@@ -186,6 +189,7 @@ static void mmc_blk_put(struct mmc_blk_data *md)
md->usage--;
if (md->usage == 0) {
int devidx = mmc_get_devidx(md->disk);
+
blk_cleanup_queue(md->queue.queue);
__clear_bit(devidx, dev_use);
@@ -240,7 +244,8 @@ static ssize_t power_ro_lock_store(struct device *dev,
EXT_CSD_BOOT_WP_B_PWR_WP_EN,
card->ext_csd.part_time);
if (ret)
- pr_err("%s: Locking boot partition ro until next power on
failed: %d\n", md->disk->disk_name, ret);
+ pr_err("%s: Locking boot partition ro until next power on
failed: %d\n",
+ md->disk->disk_name, ret);
else
card->ext_csd.boot_ro_lock |= EXT_CSD_BOOT_WP_B_PWR_WP_EN;
@@ -253,7 +258,8 @@ static ssize_t power_ro_lock_store(struct device *dev,
list_for_each_entry(part_md, >part, part)
if (part_md->area_type == MMC_BLK_DATA_AREA_BOOT) {
- pr_info("%s: Locking boot partition ro until
next power on\n", part_md->disk->disk_name);
+ pr_info("%s: Locking boot partition ro until
next power on\n",
+ part_md->disk->disk_name);
set_disk_ro(part_md->disk, 1);
}
}
@@ -279,10 +285,12 @@ static ssize_t force_ro_store(struct device *dev, struct
device_attribute *attr,
const char *buf, size_t count)
{
int ret;
- char *end;
+ int err;
struct mmc_blk_data *md = mmc_blk_get(dev_to_disk(dev));
- unsigned long set = simple_strtoul(buf, , 0);
- if (end == buf) {
+ unsigned long set;
+
+ err = kstrtoul(buf, 0, );
+ if (err) {
ret = -EINVAL;
goto out;
}
@@ -580,7 +588,8 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
* issuing the command.
*/
if (idata->ic.postsleep_min_us)
- usleep_range(idata->ic.postsleep_min_us,
idata->ic.postsleep_max_us);
+ usleep_range(idata->ic.postsleep_min_us,
+idata->ic.postsleep_max_us);
if (copy_to_user(&(ic_ptr->response), cmd.resp, sizeof(cmd.resp))) {
err = -EFAULT;
@@ -588,8 +597,9 @@ static int mmc_blk_ioctl_cmd(struct block_device *bdev,
}
if (!idata->ic.write_flag) {
- if (copy_to_user((void __user *)(unsigned long)
idata->ic.data_ptr,
- idata->buf, idata->buf_bytes)) {
+ if (copy_to_user((void __user *)(unsigned long)
+ idata->ic.data_ptr, idata->buf,
+ idata->buf_bytes)) {
err = -EFAULT;
goto cmd_rel_host;
}
@@ -622,6 +632,7 @@ static int mmc_blk_ioctl(struct block_device *bdev, fmode_t
mode,
unsigned int cmd, unsigned long arg)
{
int ret = -EINVAL;
+
if (cmd == MMC_IOC_CMD)
ret = mmc_blk_ioctl_cmd(bdev, (struct mmc_ioc_cmd __user *)arg);
return ret;
@@ -1227,7 +1238,8 @@ static int mmc_blk_err_check(struct mmc_card *card,
*/
if (brq->sbc.error || brq->cmd.error || brq->stop.error ||
brq->data.error) {
- switch
linux-next: manual merge of the xen-tip tree with the tip tree
Hi all,
Today's linux-next merge of the xen-tip tree got a conflict in:
arch/x86/xen/enlighten.c
between commit:
9261e050b686 ("x86/asm/tsc, x86/paravirt: Remove read_tsc() and read_tscp()
paravirt hooks")
from the tip tree and commit:
cd6f350a5460 ("xen/PMU: Initialization code for Xen PMU")
from the xen-tip tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/xen/enlighten.c
index d9cfa452da9d,a1c2e46206a9..
--- a/arch/x86/xen/enlighten.c
+++ b/arch/x86/xen/enlighten.c
@@@ -1215,8 -1179,11 +1219,8 @@@ static const struct pv_cpu_ops xen_cpu_
.read_msr = xen_read_msr_safe,
.write_msr = xen_write_msr_safe,
- .read_pmc = native_read_pmc,
- .read_tsc = native_read_tsc,
+ .read_pmc = xen_read_pmc,
- .read_tscp = native_read_tscp,
-
.iret = xen_iret,
#ifdef CONFIG_X86_64
.usergs_sysret32 = xen_sysret32,
--
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 v2] f2fs: skip checkpoint if there is no dirty segments
Change log from v1:
- fix skipping gc incorrectly
>From 06f90d3757a6b7ff524cc112168488f31bbf830f Mon Sep 17 00:00:00 2001
From: Jaegeuk Kim
Date: Tue, 11 Aug 2015 21:59:49 -0700
Subject: [PATCH] f2fs: skip checkpoint if there is no dirty and prefree
segments
We should avoid needless checkpoints when there is no dirty and prefree segment.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/gc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/f2fs/gc.c b/fs/f2fs/gc.c
index fcb263a..98bf538 100644
--- a/fs/f2fs/gc.c
+++ b/fs/f2fs/gc.c
@@ -811,7 +811,8 @@ gc_more:
if (gc_type == BG_GC && has_not_enough_free_secs(sbi, nfree)) {
gc_type = FG_GC;
- write_checkpoint(sbi, );
+ if (dirty_segments(sbi) || prefree_segments(sbi))
+ write_checkpoint(sbi, );
}
if (!__get_victim(sbi, , gc_type))
--
2.1.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: [RFC PATCH v1] mmc: sdhci-of-arasan: Add the support for sdhci-5.1
+linux-mmc
On 08/11/2015 04:53 PM, Michal Simek wrote:
> On 08/11/2015 09:46 AM, Shawn Lin wrote:
>> This patch adds the compatible string in sdhci-of-arasan.c to
>> support sdhci-arasan5.1 version of controller. No documented
>> controller IP version is found in the TRM, so we use ths version
>> of command queueing engine integrated into this controller by arasan
>> to specify our controller.
>>
>> Signed-off-by: Shawn Lin
>>
>> ---
>>
>> Changes in v1:
>> - Remove redundant SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN for "arasan, sdhci-5.1"
>> since
>> SDHCI will check "host->max_clk == 0" and let driver get it from
>> host->ops->get_max_clock.
>>
>> Documentation/devicetree/bindings/mmc/arasan,sdhci.txt | 2 +-
>> drivers/mmc/host/sdhci-of-arasan.c | 1 +
>> 2 files changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> index 7e94903..da541c3 100644
>> --- a/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> +++ b/Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
>> @@ -9,7 +9,7 @@ Device Tree Bindings for the Arasan SDHCI Controller
>>
>> Required Properties:
>>- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
>> -'arasan,sdhci-4.9a'
>> +'arasan,sdhci-4.9a' or 'arasan,sdhci-5.1'
>>- reg: From mmc bindings: Register location and length.
>>- clocks: From clock bindings: Handles to clock inputs.
>>- clock-names: From clock bindings: Tuple including "clk_xin" and
>> "clk_ahb"
>> diff --git a/drivers/mmc/host/sdhci-of-arasan.c
>> b/drivers/mmc/host/sdhci-of-arasan.c
>> index ef5a7d2..75379cb 100644
>> --- a/drivers/mmc/host/sdhci-of-arasan.c
>> +++ b/drivers/mmc/host/sdhci-of-arasan.c
>> @@ -217,6 +217,7 @@ static int sdhci_arasan_remove(struct platform_device
>> *pdev)
>>
>> static const struct of_device_id sdhci_arasan_of_match[] = {
>> { .compatible = "arasan,sdhci-8.9a" },
>> +{ .compatible = "arasan,sdhci-5.1" },
>> { .compatible = "arasan,sdhci-4.9a" },
>> { }
>> };
>>
>
> Acked-by: Michal Simek
>
> Thanks,
> Michal
>
>
--
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] staging: lustre: Add blank line after variable declaration
On Tue, Aug 11, 2015 at 09:32:30PM +0800, Swee Hua Law wrote:
> Add blank line after variable declaration
>
> Signed-off-by: Swee Hua Law
> ---
> drivers/staging/lustre/lustre/llite/lloop.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/staging/lustre/lustre/llite/lloop.c
> b/drivers/staging/lustre/lustre/llite/lloop.c
> index b643f11..de5eaa0 100644
> --- a/drivers/staging/lustre/lustre/llite/lloop.c
> +++ b/drivers/staging/lustre/lustre/llite/lloop.c
> @@ -372,9 +372,11 @@ err:
> static inline void loop_handle_bio(struct lloop_device *lo, struct bio *bio)
> {
> int ret;
> +
> ret = do_bio_lustrebacked(lo, bio);
> while (bio) {
> struct bio *tmp = bio->bi_next;
> +
> bio->bi_next = NULL;
> bio_endio(bio);
This patch will not apply. I am not sure how your tree got
bio_endio(bio) but in the staging tree this line is bio_endio(bio, ret);
regards
sudip
--
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] power: align wakeup_sources format
On Wed, Aug 12, 2015 at 12:31:14PM +0800, check.ker...@gmail.com wrote: > From: yangdongdong Use the same name here as you used for the signed-off-by: line please. Please fix and resend. thanks, greg k-h -- 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 v16 2/4] ARM: power-domain: rockchip: add all the domain type on RK3288 SoCs
According to a description from TRM, the following table lists all the power domains. - |VD_CORE | |VD_LOGIC| PD_VIO | | | |---| | | | | | | | | | | |- ---| | | |PD_PERI | | PD_VIDEO | | | |- ---| | | |- ---| | | |PD_ALIVE | | PD_HEVC | |-- -- | |- ---| ||PD_A17_1| |PD_A17_2| | - |-- -- | |VD_GPU |PD_GPU| |-- -- | - ||PD_A17_3| |PD_DEBUG| | - |-- -- | |VD_PMU |PD_PMU| - VD_* : voltage domain PD_* : power domain At the moment, we can support some power-domain type on RK3288. We can add more types on RK3288 in the future, that's need to do. Signed-off-by: Caesar Wang --- Changes in v16: - Add more domain decription. Series-changes: 15 - change the comment. include/dt-bindings/power-domain/rk3288.h | 31 +++ 1 file changed, 31 insertions(+) create mode 100644 include/dt-bindings/power-domain/rk3288.h diff --git a/include/dt-bindings/power-domain/rk3288.h b/include/dt-bindings/power-domain/rk3288.h new file mode 100644 index 000..db5e810 --- /dev/null +++ b/include/dt-bindings/power-domain/rk3288.h @@ -0,0 +1,31 @@ +#ifndef __DT_BINDINGS_POWER_DOMAIN_RK3288_H__ +#define __DT_BINDINGS_POWER_DOMAIN_RK3288_H__ + +/** + * RK3288 Power Domain and Voltage Domain Summary. + */ + +/* VD_CORE */ +#define RK3288_PD_A17_00 +#define RK3288_PD_A17_11 +#define RK3288_PD_A17_22 +#define RK3288_PD_A17_33 +#define RK3288_PD_SCU 4 +#define RK3288_PD_DEBUG5 +#define RK3288_PD_MEM 6 + +/* VD_LOGIC */ +#define RK3288_PD_BUS 7 +#define RK3288_PD_PERI 8 +#define RK3288_PD_VIO 9 +#define RK3288_PD_ALIVE10 +#define RK3288_PD_HEVC 11 +#define RK3288_PD_VIDEO12 + +/* VD_GPU */ +#define RK3288_PD_GPU 13 + +/* VD_PMU */ +#define RK3288_PD_PMU 14 + +#endif -- 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: [llvm-dev] llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On Wed, Aug 12, 2015 at 10:34:43AM +0800, Wangnan (F) via llvm-dev wrote:
>
> Think about a program like this:
>
> struct strA { int a; }
> struct strB { int b; }
> int func() {
> struct strA a;
> struct strB b;
>
> a.a = 1;
> b.b = 2;
> bpf_output(gettype(a), );
> bpf_output(gettype(b), );
> return 0;
> }
>
> BPF backend can't (and needn't) tell the difference between local
> variables a and b in theory. In LLVM implementation, it filters type
> information out using ComputeValueVTs(). Please have a look at
> SelectionDAGBuilder::visitIntrinsicCall in
> lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp and
> SelectionDAGBuilder::visitTargetIntrinsic in the same file. in
> visitTargetIntrinsic, ComputeValueVTs acts as a barrier which strips
> type information out from CallInst ("I"), and leave SDValue and SDVTList
> ("Ops" and "VTs") to target code. SDValue and SDVTList are wrappers of
> EVT and MVT, all information we concern won't be passed here.
>
> I think now we have 2 choices:
>
> 1. Hacking into clang, implement target specific builtin function. Now I
>have worked out a ugly but workable patch which setup a builtin function:
>__builtin_bpf_typeid(), which accepts local or global variable then
>returns different constant for different types.
>
> 2. Implementing an LLVM intrinsic call (llvm.typeid), make it be processed
> in
>visitIntrinsicCall(). I think we can get something useful if it is
> processed
>with that function.
Yeah. You're right about pure target intrinsics.
I think llvm.typeid might work. imo it's cleaner than
doing it at clang level.
> The next thing should be generating debug information to map type and
> constants which issued by __builtin_bpf_typeid() or llvm.typeid. Now we
> have a crazy idea that, if we limit the name of the structure to 8 bytes,
> we can insert the name into a u64, then there would be no need to consider
> type information in DWARF. For example, in the above sample code, gettype(a)
> will issue 0x41727473 because its type is "strA". What do you think?
that's way too hacky.
I was thinking when compiling we can keep llvm ir along with .o
instead of dwarf and extract type info from there.
dwarf has names and other things that we don't need. We only
care about actual field layout of the structs.
But it probably won't be easy to parse llvm ir on perf side
instead of dwarf.
btw, if you haven't looked at iovisor/bcc, there we're solving
similar problem differently. There we use clang rewriter, so all
structs fields are visible at this level, then we use bpf backend
in JIT mode and push bpf instructions into the kernel on the fly
completely skipping ELF and .o
For example in:
https://github.com/iovisor/bcc/blob/master/examples/distributed_bridge/tunnel.c
when you see
struct ethernet_t {
unsigned long long dst:48;
unsigned long long src:48;
unsigned inttype:16;
} BPF_PACKET_HEADER;
struct ethernet_t *ethernet = cursor_advance(cursor, sizeof(*ethernet));
... ethernet->src ...
is recognized by clang rewriter and ->src is converted to a different
C code that is sent again into clang.
So there is no need to use dwarf or patch clang/llvm. clang rewriter
has all the info.
I'm not sure you can live with clang/llvm on the host where you
want to run the tracing bits, but if you can that's an easier option.
--
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] net: Use SK_MEM_QUANTUM as minimum for tcp/udp rmem/wmem
Commit 8133534c760d4083 ("net: limit tcp/udp rmem/wmem to
SOCK_{RCV,SND}BUF_MIN") modified four sysctls to enforce that the values
written to them are not less than SOCK_MIN_{RCV,SND}BUF.
That change causes 4096 (or SK_MEM_QUANTUM) to no longer be accepted as
a valid value for 'min' in tcp_wmem and udp_wmem_min. 4096 has been the
default for both of those sysctls for a long time, and unfortunately
seems to be an extremely popular setting. This change breaks a large
number of sysctl configurations at FB.
That commit referred to b1cb59cf2efe7971 ("net: sysctl_net_core: check
SNDBUF and RCVBUF for min length"), which choose to use the SOCK_MIN
constants as the lower limits to avoid nasty bugs. But AFAICS, a limit
of SOCK_MIN_SNDBUF isn't necessary to do that: the BUG_ON cited in the
commit message seems to have happened because unix_stream_sendmsg()
expects a minimum of a full page (ie SK_MEM_QUANTUM) and the math broke,
not because it had less than SOCK_MIN_SNDBUF allocated.
Nothing seems to assume that it has at least SOCK_MIN_SNDBUF to play
with, so I think enforcing a minimum of SK_MEM_QUANTUM avoids the sort
of bugs 8133534c was trying to avoid, and it does so without breaking
anybody's sysctl configurations.
Fixes: 8133534c760d4083 ("net: limit tcp/udp rmem/wmem to SOCK_MIN...")
Signed-off-by: Calvin Owens
---
net/ipv4/sysctl_net_ipv4.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/net/ipv4/sysctl_net_ipv4.c b/net/ipv4/sysctl_net_ipv4.c
index 433231c..a214b6a 100644
--- a/net/ipv4/sysctl_net_ipv4.c
+++ b/net/ipv4/sysctl_net_ipv4.c
@@ -41,8 +41,7 @@ static int tcp_syn_retries_min = 1;
static int tcp_syn_retries_max = MAX_TCP_SYNCNT;
static int ip_ping_group_range_min[] = { 0, 0 };
static int ip_ping_group_range_max[] = { GID_T_MAX, GID_T_MAX };
-static int min_sndbuf = SOCK_MIN_SNDBUF;
-static int min_rcvbuf = SOCK_MIN_RCVBUF;
+static int min_buf = SK_MEM_QUANTUM;
/* Update system visible IP port range */
static void set_local_port_range(struct net *net, int range[2])
@@ -530,7 +529,7 @@ static struct ctl_table ipv4_table[] = {
.maxlen = sizeof(sysctl_tcp_wmem),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
- .extra1 = _sndbuf,
+ .extra1 = _buf,
},
{
.procname = "tcp_notsent_lowat",
@@ -545,7 +544,7 @@ static struct ctl_table ipv4_table[] = {
.maxlen = sizeof(sysctl_tcp_rmem),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
- .extra1 = _rcvbuf,
+ .extra1 = _buf,
},
{
.procname = "tcp_app_win",
@@ -758,7 +757,7 @@ static struct ctl_table ipv4_table[] = {
.maxlen = sizeof(sysctl_udp_rmem_min),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
- .extra1 = _rcvbuf,
+ .extra1 = _buf,
},
{
.procname = "udp_wmem_min",
@@ -766,7 +765,7 @@ static struct ctl_table ipv4_table[] = {
.maxlen = sizeof(sysctl_udp_wmem_min),
.mode = 0644,
.proc_handler = proc_dointvec_minmax,
- .extra1 = _sndbuf,
+ .extra1 = _buf,
},
{ }
};
--
1.8.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/
[PATCH] crypto: fix simple_return.cocci warnings
drivers/crypto/qat/qat_common/adf_sriov.c:258:1-4: WARNING: end returns can be simpified and declaration on line 212 can be dropped Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci CC: Tadeusz Struk Signed-off-by: Fengguang Wu --- adf_sriov.c |8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) --- a/drivers/crypto/qat/qat_common/adf_sriov.c +++ b/drivers/crypto/qat/qat_common/adf_sriov.c @@ -209,7 +209,7 @@ static int adf_enable_sriov(struct adf_a _BARS(accel_dev)[hw_data->get_misc_bar_id(hw_data)]; void __iomem *pmisc_addr = pmisc->virt_addr; struct adf_accel_vf_info *vf_info; - int i, ret; + int i; u32 reg; /* Workqueue for PF2VF responses */ @@ -255,11 +255,7 @@ static int adf_enable_sriov(struct adf_a * order for all the hardware resources (i.e. bundles) to be usable. * When SR-IOV is enabled, each of the VFs will own one bundle. */ - ret = pci_enable_sriov(pdev, totalvfs); - if (ret) - return ret; - - return 0; + return pci_enable_sriov(pdev, totalvfs); } /** -- 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 v16 4/4] ARM: dts: add the support power-domain node on RK3288 SoCs
We can add more domains node in the future.
This patch add the needed clocks into power-controller.
As the discuess about all the device clocks being listed in
the power-domains itself.
There are several reasons as follows:
Firstly, the clocks need be turned off to save power when
the system enter the suspend state. So we need to enumerate
the clocks in the dts. In order to power domain can turn on and off.
Secondly, the reset-circuit should reset be synchronous on RK3288,
then sync revoked. So we need to enable clocks of all devices.
In other words, we have to enable the clocks before you operate them
if all the device clocks are included in someone domians.
Someone wish was to get the clocks by reading the clocks from the
device nodes, We can do that but we can solve the above issues.
Anyway, the best ideas we can fix it in the future SoCs.
Signed-off-by: jinkun.hong
Signed-off-by: Caesar Wang
---
Changes in v16:
- Manually copy the problem in patch v15.
- rebase the description.
Series-changes: 15
- As Tomasz remarked previously the dts should represent the hardware
and the power-domains are part of the pmu.
Series-changes: 12
- Remove essential clocks from rk3288 PD_VIO domain, Some clocks are
essential for the system health and should not be turned down.
However there is no owner for them so if they listed as belonging to power
domain we'll try toggling them up and down during power domain transition.
As a result we either fail to suspend or resume the system.
Series-changes: 10
- fix missing the #include .
- remove the notes.
Series-changes: 9
- add decription for power-doamin node.
Series-changes: 8
- DTS go back to v2.
Series-changes: 3
- Decomposition power-controller, changed to multiple controller
(gpu-power-controller, hevc-power-controller).
Series-changes: 2
- make pd_vio clocks all one entry per line and alphabetize.
- power: power-controller move back to pinctrl: pinctrl.
arch/arm/boot/dts/rk3288.dtsi | 60 ++-
1 file changed, 59 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 22316d0..161931d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -44,6 +44,7 @@
#include
#include
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -590,8 +591,65 @@
};
pmu: power-management@ff73 {
- compatible = "rockchip,rk3288-pmu", "syscon";
+ compatible = "rockchip,rk3288-pmu", "syscon", "simple-mfd";
reg = <0xff73 0x100>;
+
+ power: power-controller {
+ compatible = "rockchip,rk3288-power-controller";
+ #power-domain-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pd_gpu {
+ reg = ;
+ clocks = < ACLK_GPU>;
+ };
+
+ pd_hevc {
+ reg = ;
+ clocks = < ACLK_HEVC>,
+< SCLK_HEVC_CABAC>,
+< SCLK_HEVC_CORE>,
+< HCLK_HEVC>;
+ };
+
+ pd_vio {
+ reg = ;
+ clocks = < ACLK_IEP>,
+< ACLK_ISP>,
+< ACLK_RGA>,
+< ACLK_VIP>,
+< ACLK_VOP0>,
+< ACLK_VOP1>,
+< DCLK_VOP0>,
+< DCLK_VOP1>,
+< HCLK_IEP>,
+< HCLK_ISP>,
+< HCLK_RGA>,
+< HCLK_VIP>,
+< HCLK_VOP0>,
+< HCLK_VOP1>,
+< PCLK_EDP_CTRL>,
+< PCLK_HDMI_CTRL>,
+< PCLK_LVDS_PHY>,
+< PCLK_MIPI_CSI>,
+< PCLK_MIPI_DSI0>,
+< PCLK_MIPI_DSI1>,
+< SCLK_EDP_24M>,
+< SCLK_EDP>,
+< SCLK_HDMI_CEC>,
+< SCLK_HDMI_HDCP>,
+< SCLK_ISP_JPE>,
+< SCLK_ISP>,
+< SCLK_RGA>;
+ };
+
+
[PATCH v16 3/4] soc: rockchip: power-domain: Add power domain driver
This driver is found on RK3288 SoCs. In order to meet high performance and low power requirements, a power management unit is designed or saving power when RK3288 in low power mode. The RK3288 PMU is dedicated for managing the power of the whole chip. PMU can work in the Low Power Mode by setting bit[0] of PMU_PWRMODE_CON register. After setting the register, PMU would enter the Low Power mode. In the low power mode, pmu will auto power on/off the specified power domain, send idle req to specified power domain, shut down/up pll and so on. All of above are configurable by setting corresponding registers. Signed-off-by: jinkun.hong Signed-off-by: Caesar Wang --- Changes in v16: - the driver type from tristate to bool. - Letter misspelled. - As Ulf suggestion, remove #include , use "%pC" as the formatting string for the dev_dbg(). - As the Ulf suggestion, set the genpd->flags to assign the ->stop|start() callbacks. Series-changes: 15 - As the kevin suggestion, put the power-domain driver into driver/soc/vendor. - As Heiko suggestion, Patch 1: binding doc, 2: binding-header, 3: driver, 4: dts-changes. - return -ENXIO --> return -ENODEV. Series-changes: 14 - does not need to set an owner,remove the "THIS_MODULE". Series-changes: 13 - Remove essential clocks from rk3288 PD_VIO domain Some clocks are essential for the system health and should not be turned down. However there is no owner for them so if they listed as belonging to power domain we'll try toggling them up and down during power domain. - Device drivers expect their devices to be powered on before their probing code is invoked. To achieve that we should start with power domains powered on (we may turn them off later once all devices enable runtime powermanagment and go idle). - This change switches Rockchip power domain driver to use updated device_attach and device_detach API. - set the gpu/core power domain power delay time. - fix enumerating PM clocks for devices. - fix use after free We can't use clk after we did clk_put(clk). Series-changes: 12 - fix the title doamin->domain. - updated device_attach and device_detach API,otherwise it will compile fail on next kernel. Series-changes: 11 - fix pm_genpd_init(>genpd, NULL, false). Series-changes: 10 - this switches over domain infos to use masks instead of recomputing them each time and also gets rid of custom domain translator and uses standard onecell on. Series-changes: 9 - fix v8 changes as follows: - This reconciles the v2 and v7 code so that we power domain have lists of clocks they trigger on and off during power transitions and independently from power domains clocks. We attach clocks to devices comprising power domain and prepare them so they are turn on and off by runtime PM. - add rockchip_pm_add_one_domain() to control domains. - add pd_start/pd_stop interface to control clocks. Series-changes: 8 - This reconciles the v2 and v7 code so that we power domain have lists of clocks they toggle on and off during power transitions and independently from power domains clocks we attach clocks to devices comprising power domain and prepare them so they are turn on and off by runtime PM. Series-changes: 7 - Delete unused variables Series-changes: 6 - delete pmu_lock. - modify dev_lock using mutex. - pm_clk_resume(pd->dev) change to pm_clk_resume(ed->dev). - pm_clk_suspend(pd->dev) change to pm_clk_suspend(ed->dev). - add devm_kfree(pd->dev, de) in rockchip_pm_domain_detach_dev. Series-changes: 5 - delete idle_lock. - add timeout in rockchip_pmu_set_idle_request(). Series-changes: 4 - use list storage dev. Series-changes: 3 - change use pm_clk_resume() and pm_clk_suspend(). Series-changes: 2 - remove the "pd->pd.of_node = np". drivers/soc/Kconfig | 1 + drivers/soc/Makefile | 1 + drivers/soc/rockchip/Kconfig | 13 + drivers/soc/rockchip/Makefile | 4 + drivers/soc/rockchip/pm_domains.c | 485 ++ 5 files changed, 504 insertions(+) create mode 100644 drivers/soc/rockchip/Kconfig create mode 100644 drivers/soc/rockchip/Makefile create mode 100644 drivers/soc/rockchip/pm_domains.c diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig index 96ddecb..ecb1a6c 100644 --- a/drivers/soc/Kconfig +++ b/drivers/soc/Kconfig @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers" source "drivers/soc/mediatek/Kconfig" source "drivers/soc/qcom/Kconfig" +source "drivers/soc/rockchip/Kconfig" source "drivers/soc/sunxi/Kconfig" source "drivers/soc/ti/Kconfig" source "drivers/soc/versatile/Kconfig" diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile index 7dc7c0d..ff8bbfb 100644 --- a/drivers/soc/Makefile +++ b/drivers/soc/Makefile @@ -4,6 +4,7 @@ obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/ obj-$(CONFIG_ARCH_QCOM)+= qcom/ +obj-$(CONFIG_ARCH_ROCKCHIP)+= rockchip/ obj-$(CONFIG_ARCH_SUNXI) += sunxi/ obj-$(CONFIG_ARCH_TEGRA)
[PATCH v16 1/4] dt-bindings: add document of Rockchip power domain
This add the necessary binding documentation for the power domain
found on Rockchip Socs.
Signed-off-by: jinkun.hong
Signed-off-by: Caesar Wang
---
Changes in v16:
- remove the pmu node.
Series-changes:9
- add document decription.
Series-changes: 8
- document go back to v2.
Series-changes: 3
- DT structure has changed.
Series-changes: 2
- move clocks to "optional".
.../bindings/soc/rockchip/power_domain.txt | 46 ++
1 file changed, 46 insertions(+)
create mode 100644
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
diff --git a/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
new file mode 100644
index 000..138754d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
@@ -0,0 +1,46 @@
+* Rockchip Power Domains
+
+Rockchip processors include support for multiple power domains which can be
+powered up/down by software based on different application scenes to save
power.
+
+Required properties for power domain controller:
+- compatible: Should be one of the following.
+ "rockchip,rk3288-power-controller" - for RK3288 SoCs.
+- #power-domain-cells: Number of cells in a power-domain specifier.
+ Should be 1 for multiple PM domains.
+- #address-cells: Should be 1.
+- #size-cells: Should be 0.
+
+Required properties for power domain sub nodes:
+- reg: index of the power domain, should use macros in:
+ "include/dt-bindings/power-domain/rk3288.h" - for rk3288 type power
domain.
+- clocks (optional): phandles to clocks which need to be enabled while power
domain
+ switches state.
+
+Example:
+
+ power: power-controller {
+ compatible = "rockchip,rk3288-power-controller";
+ #power-domain-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ pd_gpu {
+ reg = ;
+ clocks = < ACLK_GPU>;
+ };
+ };
+
+Node of a device using power domains must have a power-domains property,
+containing a phandle to the power device node and an index specifying which
+power domain to use.
+The index should use macros in:
+ "include/dt-bindings/power-domain/rk3288.h" - for rk3288 type power
domain.
+
+Example of the node using power domain:
+
+ node {
+ /* ... */
+ power-domains = < RK3288_PD_GPU>;
+ /* ... */
+ };
--
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/
[PATCH v16 0/4] ARM: rk3288: Add PM Domain support
Add power domain drivers based on generic power domain for
Rockchip platform, and support RK3288 SoCs.
Verified on url =
https://chromium.googlesource.com/chromiumos/third_party/kernel/+/v3.14
localhost / # cat /sys/kernel/debug/pm_genpd/pm_genpd_summary
domain status slaves
/device runtimestatus
--
pd_videooff
/devices/ff9a0800.iommu suspended
/devices/ff9a.video-codec suspended
pd_vio on
/devices/ff930300.iommu suspended
/devices/ff940300.iommu suspended
/devices/ff93.vop suspended
/devices/ff94.vop suspended
/devices/ff98.hdmi unsupported
/devices/rockchip-edp unsupported
pd_hevc off
pd_gpu off
/devices/ffa3.gpu suspended
The following is the easy example.
vopb: vop@ff93 {
compatible = "rockchip,rk3288-vop";
...
iommus = <_mmu>;
power-domains = < RK3288_PD_VIO>;
status = "disabled";
...
};
vopb_mmu: iommu@ff930300 {
compatible = "rockchip,iommu";
...
interrupt-names = "vopb_mmu";
power-domains = < RK3288_PD_VIO>;
#iommu-cells = <0>;
status = "disabled";
...
};
vopl: vop@ff94 {
compatible = "rockchip,rk3288-vop";
reg = <0xff94 0x19c>;
...
iommus = <_mmu>;
power-domains = < RK3288_PD_VIO>;
status = "disabled";
...
};
vopl_mmu: iommu@ff940300 {
compatible = "rockchip,iommu";
...
interrupt-names = "vopl_mmu";
power-domains = < RK3288_PD_VIO>;
#iommu-cells = <0>;
status = "disabled";
};
Others, we can verify this driver for the EDP.
We can apply the following these patchs.
6967631 New [v2,1/8] drm: exynos/dp: fix code style
6967741 New [v2,2/8] drm: exynos/dp: convert to drm bridge mode
6967801 New [v2,3/8] drm: bridge: analogix_dp: split exynos dp driver
to bridge dir
6967791 New [v2,4/8] drm: rockchip/dp: add rockchip platform dp driver
6968031 New [v2,5/8] drm: bridge/analogix_dp: add platform device type
support
6968141 New [v2,6/8] drm: bridge: analogix_dp: add some rk3288 special
registers setting
6967941 New [v2,7/8] drm: bridge: analogix_dp: try force hpd after
plug in lookup failed
6967971 New [v2,8/8] drm: bridge/analogix_dp: expand the delay time
for hpd detect
There is a recent addition from Linus Walleij,
called simple-mfd [a] that is supposed to get added real early for kernel 4.2
[a]:
https://git.kernel.org/cgit/linux/kernel/git/linusw/linux-integrator.git/commit/?h=simple-mfd=fcf294c020ff7ee4e3b1e96159e4dc7a17ad59d1
Here is my branch, Tested by chromeos-3.14 and next-kernel.
2b82899 ARM: dts: add RK3288 power-domain node
69d0b5b soc: rockchip: power-domain: support power domain driver for
RK3288 SoCs
66f8758 ARM: power-domain: rockchip: add all the domain type on RK3288
SoCs
c5f12a3 dt-bindings: add document of Rockchip power domain
7a834ba Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
0be0171 HID: wacom: Report correct device resolution when using the
wireless adapater
2b9bea0 Merge tag 'mfd-fixes-4.2' of
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd
016a9f5 Merge tag 'ntb-4.2-rc7' of git://github.com/jonmason/ntb
a3ca013 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
..
Caesar Wang (4):
dt-bindings: add document of Rockchip power domain
ARM: power-domain: rockchip: add all the domain type on RK3288 SoCs
soc: rockchip: power-domain: Add power domain driver
ARM: dts: add the support power-domain node on RK3288 SoCs
.../bindings/soc/rockchip/power_domain.txt | 46 ++
arch/arm/boot/dts/rk3288.dtsi | 60 ++-
drivers/soc/Kconfig| 1 +
drivers/soc/Makefile | 1 +
drivers/soc/rockchip/Kconfig | 13 +
drivers/soc/rockchip/Makefile | 4 +
drivers/soc/rockchip/pm_domains.c | 485 +
include/dt-bindings/power-domain/rk3288.h | 31 ++
8 files changed, 640 insertions(+), 1 deletion(-)
create mode 100644
Documentation/devicetree/bindings/soc/rockchip/power_domain.txt
create mode 100644 drivers/soc/rockchip/Kconfig
create mode 100644 drivers/soc/rockchip/Makefile
create mode 100644 drivers/soc/rockchip/pm_domains.c
create mode 100644 include/dt-bindings/power-domain/rk3288.h
--
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
Re: [PATCH v8 00/21] Compile-time stack validation
On Tue, Aug 11, 2015 at 04:31:07PM -0500, Chris J Arges wrote: > Josh, > > I've applied and tried to build your patchset against the latest > mainline kernel with the following config: > http://paste.ubuntu.com/12058017/ > > I can build if I disable CONFIG_STACK_VALIDATION, then re-enable it > after all objects are already built, so this seems like it should be > resolvable in Makefiles. Any suggestions for debugging this? > > Building from clean I get the following: > ~/linux$ make > HOSTCC scripts/basic/fixdep > HOSTCC scripts/basic/bin2c > GEN arch/x86/lib/inat-tables.c > HOSTCC arch/x86/tools/relocs_32.o > HOSTCC arch/x86/tools/relocs_64.o > HOSTCC arch/x86/tools/relocs_common.o > HOSTLD arch/x86/tools/relocs > CHK include/config/kernel.release > CHK include/generated/uapi/linux/version.h > CHK include/generated/utsrelease.h > CC arch/x86/purgatory/purgatory.o > AS arch/x86/purgatory/stack.o > AS arch/x86/purgatory/setup-x86_64.o > CC arch/x86/purgatory/sha256.o > AS arch/x86/purgatory/entry64.o > CC arch/x86/purgatory/string.o > LD arch/x86/purgatory/purgatory.ro > BIN2C arch/x86/purgatory/kexec-purgatory.c > CC kernel/bounds.s > CHK include/generated/bounds.h > CHK include/generated/timeconst.h > CC arch/x86/kernel/asm-offsets.s > CHK include/generated/asm-offsets.h > CALLscripts/checksyscalls.sh > HOSTCC scripts/genksyms/genksyms.o > HOSTCC scripts/genksyms/parse.tab.o > HOSTCC scripts/genksyms/lex.lex.o > HOSTLD scripts/genksyms/genksyms > CC scripts/mod/empty.o > scripts/mod/empty.o > open: No such file or directory > error reading elf file scripts/mod/empty.o > scripts/Makefile.build:284: recipe for target 'scripts/mod/empty.o' failed > make[2]: *** [scripts/mod/empty.o] Error 1 > scripts/Makefile.build:429: recipe for target 'scripts/mod' failed > make[1]: *** [scripts/mod] Error 2 > Makefile:545: recipe for target 'scripts' failed > make: *** [scripts] Error 2 Thanks for trying it out. I couldn't figure out how to recreate this exact error, but I played around with "make mrproper" and saw some probably related errors. Does this fix it? ---8<--- Subject: [PATCH] stackvalidate: fix circular build dependencies After "make mrproper" with CONFIG_STACK_VALIDATION enabled, I get the following errors: make[2]: *** No rule to make target 'arch/x86/purgatory/purgatory.o', needed by 'arch/x86/purgatory/purgatory.ro'. Stop. make[3]: *** No rule to make target 'scripts/mod/empty.o', needed by 'scripts/mod/elfconfig.h'. Stop. These are caused by circular dependencies. The %.o pattern rules in scripts/Makefile.build have the stackvalidate binary listed as a dependency. But stackvalidate gets built *after* archprepare and scripts/mod, both of which build objects using the %.o pattern rules. The STACKVALIDATE and STACKVALIDATE_foo.o variables are already used to determine whether to validate a given object. Also use them to determine whether to create the pattern rule dependency. Signed-off-by: Josh Poimboeuf --- scripts/Makefile.build | 7 +-- scripts/mod/Makefile | 2 ++ 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index a1270d3..ec96c51 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -243,7 +243,7 @@ endif ifdef CONFIG_STACK_VALIDATION -stackvalidate = $(objtree)/scripts/stackvalidate/stackvalidate +__stackvalidate = $(objtree)/scripts/stackvalidate/stackvalidate ifndef CONFIG_FRAME_POINTER nofp = --no-frame-pointer @@ -251,9 +251,12 @@ endif # Set STACKVALIDATE_foo.o=n to skip stack validation for a file. # Set STACKVALIDATE=n to skip stack validation for a directory. +stackvalidate = $(if $(patsubst n%,, \ + $(STACKVALIDATE_$(basetarget).o)$(STACKVALIDATE)y), \ + $(__stackvalidate)) cmd_stackvalidate = $(if $(patsubst n%,, \ $(STACKVALIDATE_$(basetarget).o)$(STACKVALIDATE)y), \ - $(stackvalidate) $(nofp) "$(@)";) + $(__stackvalidate) $(nofp) "$(@)";) endif # CONFIG_STACK_VALIDATION diff --git a/scripts/mod/Makefile b/scripts/mod/Makefile index c11212f..374c413 100644 --- a/scripts/mod/Makefile +++ b/scripts/mod/Makefile @@ -1,3 +1,5 @@ +STACKVALIDATE := n + hostprogs-y:= modpost mk_elfconfig always := $(hostprogs-y) empty.o -- 2.4.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 v5 01/11] block: make generic_make_request handle arbitrarily sized bios
On Tue, 2015-08-11 at 20:24 -0400, Martin K. Petersen wrote: > > "Ming" == Ming Lin writes: > > Ming> Do you still agree we cap discard to 2G as an interim solution? > > I can live with the 2G cap for 4.3 but would like to see it fixed > properly in 4.4. Sure. I'd like to work on the fix. -- 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 v3 2/2] ARM: dts: ls1021a: add wakeup device ftm0 node for ls1021a
From: Wang Dongsheng
Add ftm0 node, cause of ftm0 can be set as a alarm before system going
to deep sleep.
Signed-off-by: Wang Dongsheng
Signed-off-by: Alison Wang
---
*V3*
- No changes.
*V2*
- Add my SoB.
- Use "ARM:" as subject prefix.
diff --git a/arch/arm/boot/dts/ls1021a-qds.dts
b/arch/arm/boot/dts/ls1021a-qds.dts
index 9c5e16b..f14731b 100644
--- a/arch/arm/boot/dts/ls1021a-qds.dts
+++ b/arch/arm/boot/dts/ls1021a-qds.dts
@@ -75,6 +75,10 @@
};
};
+ {
+ status = "okay";
+};
+
{
status = "okay";
diff --git a/arch/arm/boot/dts/ls1021a.dtsi b/arch/arm/boot/dts/ls1021a.dtsi
index c70bb27..7e9e122 100644
--- a/arch/arm/boot/dts/ls1021a.dtsi
+++ b/arch/arm/boot/dts/ls1021a.dtsi
@@ -332,6 +332,14 @@
status = "disabled";
};
+ ftm0: ftm0@29d {
+ compatible = "fsl,ftm-alarm";
+ reg = <0x0 0x29d 0x0 0x1>;
+ interrupts = ;
+ big-endian;
+ status = "disabled";
+ };
+
wdog0: watchdog@2ad {
compatible = "fsl,imx21-wdt";
reg = <0x0 0x2ad 0x0 0x1>;
--
2.1.0.27.g96db324
--
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] usb: core: hub: Removed some warnings generated by checkpatch.pl
Removed some checkpatch.pl warnings saying there was an unwanted space between
function names and their arguments.
Signed-off-by: Chase Metzger
---
drivers/usb/core/hub.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 9387cc20..38cb6d3 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -1442,8 +1442,8 @@ static int hub_configure(struct usb_hub *hub,
break;
}
- spin_lock_init (>tt.lock);
- INIT_LIST_HEAD (>tt.clear_list);
+ spin_lock_init(>tt.lock);
+ INIT_LIST_HEAD(>tt.clear_list);
INIT_WORK(>tt.clear_work, hub_tt_work);
switch (hdev->descriptor.bDeviceProtocol) {
case USB_HUB_PR_FS:
@@ -1632,7 +1632,7 @@ static int hub_configure(struct usb_hub *hub,
return 0;
fail:
- dev_err (hub_dev, "config failed, %s (err %d)\n",
+ dev_err(hub_dev, "config failed, %s (err %d)\n",
message, ret);
/* hub_disconnect() frees urb and descriptor */
return ret;
@@ -1775,7 +1775,7 @@ static int hub_probe(struct usb_interface *intf, const
struct usb_device_id *id)
if ((desc->desc.bInterfaceSubClass != 0) &&
(desc->desc.bInterfaceSubClass != 1)) {
descriptor_error:
- dev_err (>dev, "bad descriptor, ignoring hub\n");
+ dev_err(>dev, "bad descriptor, ignoring hub\n");
return -EIO;
}
@@ -1790,11 +1790,11 @@ descriptor_error:
goto descriptor_error;
/* We found a hub */
- dev_info (>dev, "USB hub found\n");
+ dev_info(>dev, "USB hub found\n");
hub = kzalloc(sizeof(*hub), GFP_KERNEL);
if (!hub) {
- dev_dbg (>dev, "couldn't kmalloc hub struct\n");
+ dev_dbg(>dev, "couldn't kmalloc hub struct\n");
return -ENOMEM;
}
@@ -1807,7 +1807,7 @@ descriptor_error:
usb_get_intf(intf);
usb_get_dev(hdev);
- usb_set_intfdata (intf, hub);
+ usb_set_intfdata(intf, hub);
intf->needs_remote_wakeup = 1;
pm_suspend_ignore_children(>dev, true);
@@ -1820,14 +1820,14 @@ descriptor_error:
if (hub_configure(hub, endpoint) >= 0)
return 0;
- hub_disconnect (intf);
+ hub_disconnect(intf);
return -ENODEV;
}
static int
hub_ioctl(struct usb_interface *intf, unsigned int code, void *user_data)
{
- struct usb_device *hdev = interface_to_usbdev (intf);
+ struct usb_device *hdev = interface_to_usbdev(intf);
struct usb_hub *hub = usb_hub_to_struct_hub(hdev);
/* assert ifno == 0 (part of hub spec) */
@@ -2143,7 +2143,7 @@ void usb_disconnect(struct usb_device **pdev)
* cleaning up all state associated with the current configuration
* so that the hardware is now fully quiesced.
*/
- dev_dbg (>dev, "unregistering device\n");
+ dev_dbg(>dev, "unregistering device\n");
usb_disable_device(udev, 0);
usb_hcd_synchronize_unlinks(udev);
@@ -2242,7 +2242,7 @@ static int usb_enumerate_device_otg(struct usb_device
*udev)
struct usb_bus *bus = udev->bus;
/* descriptor may appear anywhere in config */
- if (__usb_get_extra_descriptor (udev->rawdescriptors[0],
+ if (__usb_get_extra_descriptor(udev->rawdescriptors[0],
le16_to_cpu(udev->config[0].desc.wTotalLength),
USB_DT_OTG, (void **) ) == 0) {
if (desc->bmAttributes & USB_OTG_HNP) {
@@ -3526,7 +3526,7 @@ static int check_ports_changed(struct usb_hub *hub)
static int hub_suspend(struct usb_interface *intf, pm_message_t msg)
{
- struct usb_hub *hub = usb_get_intfdata (intf);
+ struct usb_hub *hub = usb_get_intfdata(intf);
struct usb_device *hdev = hub->hdev;
unsignedport1;
int status;
--
2.1.4
--
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] power: align wakeup_sources format
From: yangdongdong
This aligns every column of elements in wakeup_sources to
conveniently check any specific column for suspicious power
consumption wakeup source or for other easily readable purpose.
Signed-off-by: Andy Yang
Signed-off-by: Linghua Gu
---
drivers/base/power/wakeup.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c
index 51f15bc..b6fe9e6 100644
--- a/drivers/base/power/wakeup.c
+++ b/drivers/base/power/wakeup.c
@@ -998,7 +998,7 @@ static int print_wakeup_source_stats(struct seq_file *m,
active_time = ktime_set(0, 0);
}
- seq_printf(m,
"%-12s\t%lu\t\t%lu\t\t%lu\t\t%lu\t\t%lld\t\t%lld\t\t%lld\t\t%lld\t\t%lld\n",
+ seq_printf(m,
"%-32s\t%lu\t\t%lu\t\t%lu\t\t%lu\t\t%lld\t\t%lld\t\t%lld\t\t%lld\t\t%lld\n",
ws->name, active_count, ws->event_count,
ws->wakeup_count, ws->expire_count,
ktime_to_ms(active_time), ktime_to_ms(total_time),
@@ -1018,7 +1018,7 @@ static int wakeup_sources_stats_show(struct seq_file *m,
void *unused)
{
struct wakeup_source *ws;
- seq_puts(m, "name\t\tactive_count\tevent_count\twakeup_count\t"
+ seq_puts(m, "name\t\t\t\t\tactive_count\tevent_count\twakeup_count\t"
"expire_count\tactive_since\ttotal_time\tmax_time\t"
"last_change\tprevent_suspend_time\n");
--
2.5.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/
Re: [PATCH] MAINTAINERS: The keyrings mailing list has moved
On Tue, 11 Aug 2015, David Howells wrote: > The keyrings mailing list has moved to keyri...@vger.kernel.org > > Signed-off-by: David Howells Applied. -- James Morris -- 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 v3 1/2] Documentation: DT: FTM: add FTM0 be used as alarm timer
From: Wang Dongsheng
In freescale layerscape platform there is only FTM0 can be used as
alarm timer to wake up system. So add FTM0 description for devicetree
document.
Signed-off-by: Wang Dongsheng
---
V3:
Include this patch in V3.
diff --git a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
index aa8c402..380a0b3d 100644
--- a/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
+++ b/Documentation/devicetree/bindings/timer/fsl,ftm-timer.txt
@@ -1,5 +1,7 @@
Freescale FlexTimer Module (FTM) Timer
+* Default FTM Timer
+
Required properties:
- compatible : should be "fsl,ftm-timer"
@@ -29,3 +31,26 @@ ftm: ftm@400b8000 {
< VF610_CLK_FTM3_EXT_FIX_EN>;
big-endian;
};
+
+* FTM Alarm Timer
+ The default FTM device contains eight FlexTimer modules. FlexTimer1 is in
+ on-domain(power is not switched off in deep sleep mode). Other seven
FlexTimer
+ modules(flextimer2/3/4/5/6/7/8) are in off-domain (power is switched off in
+ deep sleep mode).
+
+Required properties:
+
+- compatible : should be "fsl,ftm-alarm".
+- reg : should contain base address and length of FTM timer 0 register.
+- interrupts : Should contain FTM 0 interrupt.
+- big-endian: One boolean property, the big endian mode will be in use if it is
+ present, or the little endian mode will be in use for all the device
registers.
+
+Example:
+ftm0: ftm0@29d {
+ compatible = "fsl,ftm-alarm";
+ reg = <0x0 0x29d 0x0 0x1>;
+ interrupts = ;
+ big-endian;
+ status = "disabled";
+};
--
2.1.0.27.g96db324
--
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] MODSIGN: Use PKCS#7 for module signatures [ver #7a]
On Tue, 11 Aug 2015, David Howells wrote: > Hi James, > > Can you pull this into security/next please? Its aim is twofold: firstly, > make the module signatures of PKCS#7/CMS format rather than a home-brewed > format and secondly to pave the way for use of the signing code for > firmware signatures (to follow later). After installing the devel package, I now see these warnings and error: WARNING: modpost: missing MODULE_LICENSE() in crypto/asymmetric_keys/pkcs7_test_key.o scripts/sign-file.c: In function ‘main’: scripts/sign-file.c:188: warning: value computed is not used At main.c:146: - SSL error:02001002:system library:fopen:No such file or directory: bss_file.c:169 - SSL error:2006D080:BIO routines:BIO_new_file:no such file: bss_file.c:172 extract-cert: signing_key.pem: No such file or directory rm: cannot remove `signing_key.x509': No such file or directory -- James Morris
[PATCH] Revert "drm/nouveau/fifo/gk104: kick channels when deactivating them"
This reverts commit 1addc1264852
This commit seems to cause crashes in gk104_fifo_intr_runlist() by
returning 0xbad0da00 when register 0x2a00 is read. Since this commit was
intended for GM20B which is not completely supported yet, let's revert
it for the time being.
Reported-by: Eric Biggers
Signed-off-by: Alexandre Courbot
---
David, it would be great if this could be merged for 4.2 since lots of
users could potentially experience this issue. Thanks!
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 29 +++-
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index 52c22b026005..e10f9644140f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
@@ -166,30 +166,14 @@ gk104_fifo_context_attach(struct nvkm_object *parent,
}
static int
-gk104_fifo_chan_kick(struct gk104_fifo_chan *chan)
-{
- struct nvkm_object *obj = (void *)chan;
- struct gk104_fifo_priv *priv = (void *)obj->engine;
-
- nv_wr32(priv, 0x002634, chan->base.chid);
- if (!nv_wait(priv, 0x002634, 0x10, 0x00)) {
- nv_error(priv, "channel %d [%s] kick timeout\n",
-chan->base.chid, nvkm_client_name(chan));
- return -EBUSY;
- }
-
- return 0;
-}
-
-static int
gk104_fifo_context_detach(struct nvkm_object *parent, bool suspend,
struct nvkm_object *object)
{
struct nvkm_bar *bar = nvkm_bar(parent);
+ struct gk104_fifo_priv *priv = (void *)parent->engine;
struct gk104_fifo_base *base = (void *)parent->parent;
struct gk104_fifo_chan *chan = (void *)parent;
u32 addr;
- int ret;
switch (nv_engidx(object->engine)) {
case NVDEV_ENGINE_SW: return 0;
@@ -204,9 +188,13 @@ gk104_fifo_context_detach(struct nvkm_object *parent, bool
suspend,
return -EINVAL;
}
- ret = gk104_fifo_chan_kick(chan);
- if (ret && suspend)
- return ret;
+ nv_wr32(priv, 0x002634, chan->base.chid);
+ if (!nv_wait(priv, 0x002634, 0x, chan->base.chid)) {
+ nv_error(priv, "channel %d [%s] kick timeout\n",
+chan->base.chid, nvkm_client_name(chan));
+ if (suspend)
+ return -EBUSY;
+ }
if (addr) {
nv_wo32(base, addr + 0x00, 0x);
@@ -331,7 +319,6 @@ gk104_fifo_chan_fini(struct nvkm_object *object, bool
suspend)
gk104_fifo_runlist_update(priv, chan->engine);
}
- gk104_fifo_chan_kick(chan);
nv_wr32(priv, 0x80 + (chid * 8), 0x);
return nvkm_fifo_channel_fini(>base, suspend);
}
--
2.5.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/
[PATCH] kmod: correct documentation of return status of request_module
if request_module() successfully runs modprobe, but modprobe exits with a non-zero status, then the return value from request_module() will be that (positive) error status. So the return from request_module can be: negative errno zero for success positive exit code. Signed-off-by: NeilBrown Cc: Goldwyn Rodrigues diff --git a/kernel/kmod.c b/kernel/kmod.c index 2777f40a9c7b..1734ba61ff23 100644 --- a/kernel/kmod.c +++ b/kernel/kmod.c @@ -114,10 +114,11 @@ out: * @...: arguments as specified in the format string * * Load a module using the user mode module loader. The function returns - * zero on success or a negative errno code on failure. Note that a - * successful module load does not mean the module did not then unload - * and exit on an error of its own. Callers must check that the service - * they requested is now available not blindly invoke it. + * zero on success or a negative errno code or positive exit code from + * "modprobe" on failure. Note that a successful module load does not mean + * the module did not then unload and exit on an error of its own. Callers + * must check that the service they requested is now available not blindly + * invoke it. * * If module auto-loading support is disabled then this function * becomes a no-operation. -- 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 09/10] Define PERF_PMU_TXN_READ interface
Peter Zijlstra [pet...@infradead.org] wrote:
| On Sun, Jul 26, 2015 at 10:40:37PM -0700, Sukadev Bhattiprolu wrote:
| > @@ -3743,7 +3762,13 @@ static u64 perf_event_aggregate(struct perf_event
*event, u64 *enabled,
| > lockdep_assert_held(>child_mutex);
| >
| > list_for_each_entry(child, >child_list, child_list) {
| > +#if 0
| > + /*
| > +* TODO: Do we need this read() for group events on PMUs that
| > +* don't implement PERF_PMU_TXN_READ transactions?
| > +*/
| > (void)perf_event_read(child, false);
| > +#endif
| > total += perf_event_count(child);
| > *enabled += child->total_time_enabled;
| > *running += child->total_time_running;
|
| Aw gawd, I've been an idiot!!
|
| I just realized this is a _CHILD_ loop, not a _SIBLING_ loop !!
|
| We need to flip the loops in perf_read_group(), find attached two
| patches that go on top of 1,2,4.
|
| After this you can add the perf_event_read() return value (just fold
| patches 6,8) after which you can do patch 10 (which has a broken
| Subject fwiw).
Thanks for the patches. I am building and testing, but have a question
on the second patch below:
| Subject: perf: Invert perf_read_group() loops
| From: Peter Zijlstra
| Date: Thu Aug 6 13:41:13 CEST 2015
|
| In order to enable the use of perf_event_read(.group = true), we need
| to invert the sibling-child loop nesting of perf_read_group().
|
| Currently we iterate the child list for each sibling, this precludes
| using group reads. Flip things around so we iterate each group for
| each child.
|
| Signed-off-by: Peter Zijlstra (Intel)
| ---
| kernel/events/core.c | 84
---
| 1 file changed, 54 insertions(+), 30 deletions(-)
|
| --- a/kernel/events/core.c
| +++ b/kernel/events/core.c
| @@ -3809,50 +3809,74 @@ u64 perf_event_read_value(struct perf_ev
| }
| EXPORT_SYMBOL_GPL(perf_event_read_value);
|
| -static int perf_read_group(struct perf_event *event,
| -u64 read_format, char __user *buf)
| +static void __perf_read_group_add(struct perf_event *leader, u64
read_format, u64 *values)
| {
| - struct perf_event *leader = event->group_leader, *sub;
| - struct perf_event_context *ctx = leader->ctx;
| - int n = 0, size = 0, ret;
| - u64 count, enabled, running;
| - u64 values[5];
| + struct perf_event *sub;
| + int n = 1; /* skip @nr */
This n = 1 is to skip over the values[0] = 1 + nr_siblings in the
caller.
Anyway, in __perf_read_group_add() we always start with n = 1, however
...
|
| - lockdep_assert_held(>mutex);
| + perf_event_read(leader, true);
| +
| + /*
| + * Since we co-schedule groups, {enabled,running} times of siblings
| + * will be identical to those of the leader, so we only publish one
| + * set.
| + */
| + if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED) {
| + values[n++] += leader->total_time_enabled +
| + atomic64_read(leader->child_total_time_enabled);
| + }
|
| - count = perf_event_read_value(leader, , );
| + if (read_format & PERF_FORMAT_TOTAL_TIME_RUNNING) {
| + values[n++] += leader->total_time_running +
| + atomic64_read(leader->child_total_time_running);
| + }
|
| - values[n++] = 1 + leader->nr_siblings;
| - if (read_format & PERF_FORMAT_TOTAL_TIME_ENABLED)
| - values[n++] = enabled;
| - if (read_format & PERF_FORMAT_TOTAL_TIME_RUNNING)
| - values[n++] = running;
| - values[n++] = count;
| + /*
| + * Write {count,id} tuples for every sibling.
| + */
| + values[n++] += perf_event_count(leader);
| if (read_format & PERF_FORMAT_ID)
| values[n++] = primary_event_id(leader);
|
| - size = n * sizeof(u64);
| + list_for_each_entry(sub, >sibling_list, group_entry) {
| + values[n++] += perf_event_count(sub);
| + if (read_format & PERF_FORMAT_ID)
| + values[n++] = primary_event_id(sub);
| + }
| +}
|
| - if (copy_to_user(buf, values, size))
| - return -EFAULT;
| +static int perf_read_group(struct perf_event *event,
| +u64 read_format, char __user *buf)
| +{
| + struct perf_event *leader = event->group_leader, *child;
| + struct perf_event_context *ctx = leader->ctx;
| + int ret = leader->read_size;
| + u64 *values;
|
| - ret = size;
| + lockdep_assert_held(>mutex);
|
| - list_for_each_entry(sub, >sibling_list, group_entry) {
| - n = 0;
| + values = kzalloc(event->read_size);
| + if (!values)
| + return -ENOMEM;
|
| - values[n++] = perf_event_read_value(sub, , );
| - if (read_format & PERF_FORMAT_ID)
| - values[n++] = primary_event_id(sub);
| + values[0] = 1 +
Re: [ftrace] possible to implement user-space tracers?
Hi Kun, On 08/11/2015 08:42 PM, Kun Huang wrote: > Hi Scotty > > I have read your links. I found the read from 'trace' and the write to > 'trace_marker' are normal read which works like proc system. > > I have questions that what's more difference between ftrace and proc? > I just know I could read data as pipeline from ftrace. Well, in kernel land you can trace your functions, with very little over head. For example, in the binder driver (http://lxr.free-electrons.com/source/drivers/android/binder.c#L2423) there are trace events everywhere throughout the code. The thing is you need to build the traces into your code, if you're going to use it. When you're in userland one way to trace your application flow is by making a wrapper around the debugfs entry (like android does) and manually write()'ing the data into the kernel buffer -- This is what android does. Why ftrace is in debugfs and not procfs? I'm not sure you'll have to ask the original developers, I'm sure there is a good reason. Perhaps I didn't understand your use case. Did you want to see what was happening in kernel land while you were running your python project? Or do you want to be able to trace your python functions like the way ftrace can trace kernel functions during execution? > On Wed, Aug 12, 2015 at 10:25 AM, Kun Huang wrote: >> Thank you for your help Scotty :) I'm reading it. >> >> On Wed, Aug 12, 2015 at 2:34 AM, Scotty Bauer wrote: >>> It is possible to trace from userland, Android does it. >>> >>> Essentially you need to write your data into >>> /sys/kernel/debug/tracing/trace_marker >>> >>> then read it out of /sys/kernel/debug/tracing/trace >>> >>> >>> If you care how the implementation works you can read it in >>> /kernel/tracing/trace.c >>> (http://lxr.free-electrons.com/source/kernel/trace/trace.c) search for >>> tracing_mark_fops and tracing_fops. >>> >>> >>> In Android here are the relevant files you will need to see how it's used in >>> userland: >>> Atrace (for reading data out + setting things up): >>> https://android.googlesource.com/platform/frameworks/native/+/master/cmds/atrace/atrace.cpp >>> https://android.googlesource.com/platform/external/chromium-trace/+/master >>> (host side setup of the device) >>> >>> trace-dev (for writing data in): >>> https://android.googlesource.com/platform/system/core/+/master/libcutils/trace-dev.c >>> >>> Once we have all the data we usually run it through trace-viewer, >>> (https://github.com/catapult-project/catapult) >>> >>> Cheers. >>> >>> On 2015-08-11 06:53, Kun Huang wrote: > > Hi ftrace developers > > I'm developing a huge python based programs and facing performance > issue everyday. I like the ftrace system and hope there could be a > tracer to trace my python codes. Is it possible or is it worthy > > to do this? > > --- > > Kun > -- > 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 [6] > > Please read the FAQ at http://www.tux.org/lkml/ [7] Links: -- [1] http://lxr.free-electrons.com/source/kernel/trace/trace.c [2] https://android.googlesource.com/platform/frameworks/native/+/master/cmds/atrace/atrace.cpp [3] https://android.googlesource.com/platform/external/chromium-trace/+/master [4] https://android.googlesource.com/platform/system/core/+/master/libcutils/trace-dev.c [5] https://github.com/catapult-project/catapult [6] http://vger.kernel.org/majordomo-info.html [7] http://www.tux.org/lkml/ > -- > 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/ > -- 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: [Ksummit-discuss] [BELATED CORE TOPIC] context tracking / nohz / RCU state
On Wed, Aug 12, 2015 at 1:49 AM, Andy Lutomirski wrote: > This is a bit late, but here goes anyway. > > Having played with the x86 context tracking hooks for awhile, I think > it would be nice if core code that needs to be aware of CPU context > (kernel, user, idle, guest, etc) could come up with single, > comprehensible, easily validated set of hooks that arch code is > supposed to call. > > Currently we have: > > - RCU hooks, which come in a wide variety to notify about IRQs, NMIs, etc. > > - Context tracking hooks. Only used by some arches. Calling these > calls the RCU hooks for you in most cases. They have weird > interactions with interrupts and they're slow. > > - vtime. Beats the heck out of me. > > - Whatever deferred things Christoph keeps reminding us about. > > Honestly, I don't fully understand what all these hooks are supposed > to do, nor do I care all that much. From my perspective, the code > code should be able to do whatever it wants and rely on appropriate > notifications from arch code. It would be great if we could come up > with something straightforward that covers everything. For example: > > user_mode_to_kernel_mode() > kernel_mode_to_user_mode() > kernel_mode_to_guest_mode() > in_a_periodic_tick() > starting_nmi() > ending_nmi() > may_i_turn_off_ticks_right_now() > or, better yet: > i_am_turning_off_ticks_right_now_and_register_your_own_darned_hrtimer_if_thats_a_problem() > > Some arches may need: > > i_am_lame_and_forgot_my_previous_context() > > x86 will soon (4.3 or 4.4, depending on how my syscall cleanup goes) > no longer need that. > > Paul says that some arches need something that goes straight from IRQ > to user mode (?) -- sigh. > > etc. > > It might make sense to get enough people who understand what's going > on behind the scenes together to hash out the requirements. > I am also interested by the topic. I hope we can find out a common infrastructure to handle these callbacks. I am interested in optimizing/simplifying the these callbacks of RCU as well. Thanks, Lai > --Andy > ___ > Ksummit-discuss mailing list > ksummit-disc...@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss -- 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 v3] fs/pstore: provide panic data even in suspend
From: yangdongdong
If system restart after panic, this patch also enables
panic and oops messages which in suspend context to be
logged into ramoops console buffer where it can be read
back at some later point.
Signed-off-by: yangdongdong
Signed-off-by: gulinghua
Signed-off-by: duhui
---
fs/pstore/ram.c| 16
include/linux/pstore_ram.h | 1 +
kernel/printk/printk.c | 7 +++
3 files changed, 24 insertions(+)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 6c26c4d..3d981a1 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -642,8 +642,23 @@ static void ramoops_register_dummy(void)
}
}
+static int ramoops_console_notify(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ pr_emerg("ramoops unlock console ...\n");
+ emergency_unlock_console();
+
+ return 0;
+}
+
+static struct notifier_block ramoop_nb = {
+ .notifier_call = ramoops_console_notify,
+ .priority = INT_MAX,
+};
+
static int __init ramoops_init(void)
{
+ atomic_notifier_chain_register(_notifier_list, _nb);
ramoops_register_dummy();
return platform_driver_register(_driver);
}
@@ -654,6 +669,7 @@ static void __exit ramoops_exit(void)
platform_driver_unregister(_driver);
platform_device_unregister(dummy);
kfree(dummy_data);
+ atomic_notifier_chain_unregister(_notifier_list, _nb);
}
module_exit(ramoops_exit);
diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
index 9c9d6c1..826a35b 100644
--- a/include/linux/pstore_ram.h
+++ b/include/linux/pstore_ram.h
@@ -52,6 +52,7 @@ struct persistent_ram_zone {
size_t old_log_size;
};
+extern void emergency_unlock_console(void);
struct persistent_ram_zone *persistent_ram_new(phys_addr_t start, size_t size,
u32 sig, struct persistent_ram_ecc_info *ecc_info,
unsigned int memtype);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index cf8c242..ca02094 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2107,6 +2107,13 @@ void resume_console(void)
console_unlock();
}
+void emergency_unlock_console(void)
+{
+ if (panic_timeout != 0 && console_suspended)
+ resume_console();
+}
+EXPORT_SYMBOL(emergency_unlock_console);
+
/**
* console_cpu_notify - print deferred console messages after CPU hotplug
* @self: notifier struct
--
2.5.0
Following is the difference between v2 and v3:
void emergency_unlock_console(void)
{
- if (panic_timeout != 0)
+ if ((panic_timeout != 0) && console_suspended)
resume_console();
}
EXPORT_SYMBOL(emergency_unlock_console);
Once system kernel panic with nonzero panic_timeout value, we hope the debugging
information could be dumped and system could be recovered by reboot.
Since it is emergency case before system reboot, no whether it is triggered by
watchdog or emergency_restart, the debugging data is important for us to
be read back at some later point and system would have no possible enter
suspend and resume.
And usually dump panic data process would be hoped to handle in atomic process.
That is why no console_suspended check for emergency_unlock_console at the
PATCH-V2.
Here is updating it to [PATCH v3], also add console_suspended check for
emergency_unlock_console, which specific invoked conosole_suspended previously.
Due to no panic information, if we use current ram console approach once panic
occurs
on system enter suspend, we would not know who is the trouble maker. We have
such
experience at receiving big noise in MO call under system suspend. That is the
intention to add the patch.
Thanks,
Andy
--
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][rfc] intel_pstate: Fix user input of min/max to legal policy region
In current code, if system is using performance policy, user can modify the max_perf_pct to any values lower than 100: $ grep . /sys/devices/system/cpu/intel_pstate/m*_perf_pct /sys/devices/system/cpu/intel_pstate/max_perf_pct:100 /sys/devices/system/cpu/intel_pstate/min_perf_pct:100 $ echo 80 > /sys/devices/system/cpu/intel_pstate/max_perf_pct $ grep . /sys/devices/system/cpu/intel_pstate/m*_perf_pct /sys/devices/system/cpu/intel_pstate/max_perf_pct:80 /sys/devices/system/cpu/intel_pstate/min_perf_pct:100 the max_perf_pct above is lower than min_perf_pct, which is not reasonable. This patch solves this problem by clamping min_perf_pct and max_perf_pct to be strictly inside [min_policy_pct,max_policy_pct]. Signed-off-by: Chen Yu --- drivers/cpufreq/intel_pstate.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/drivers/cpufreq/intel_pstate.c b/drivers/cpufreq/intel_pstate.c index fcb929e..3702c5a 100644 --- a/drivers/cpufreq/intel_pstate.c +++ b/drivers/cpufreq/intel_pstate.c @@ -423,6 +423,7 @@ static ssize_t store_max_perf_pct(struct kobject *a, struct attribute *b, limits.max_sysfs_pct = clamp_t(int, input, 0 , 100); limits.max_perf_pct = min(limits.max_policy_pct, limits.max_sysfs_pct); + limits.max_perf_pct = max(limits.min_policy_pct, limits.max_perf_pct); limits.max_perf = div_fp(int_tofp(limits.max_perf_pct), int_tofp(100)); if (hwp_active) @@ -442,6 +443,7 @@ static ssize_t store_min_perf_pct(struct kobject *a, struct attribute *b, limits.min_sysfs_pct = clamp_t(int, input, 0 , 100); limits.min_perf_pct = max(limits.min_policy_pct, limits.min_sysfs_pct); + limits.min_perf_pct = min(limits.max_policy_pct, limits.min_perf_pct); limits.min_perf = div_fp(int_tofp(limits.min_perf_pct), int_tofp(100)); if (hwp_active) @@ -985,12 +987,14 @@ static int intel_pstate_set_policy(struct cpufreq_policy *policy) limits.min_policy_pct = (policy->min * 100) / policy->cpuinfo.max_freq; limits.min_policy_pct = clamp_t(int, limits.min_policy_pct, 0 , 100); - limits.min_perf_pct = max(limits.min_policy_pct, limits.min_sysfs_pct); - limits.min_perf = div_fp(int_tofp(limits.min_perf_pct), int_tofp(100)); - limits.max_policy_pct = (policy->max * 100) / policy->cpuinfo.max_freq; limits.max_policy_pct = clamp_t(int, limits.max_policy_pct, 0 , 100); + + limits.min_perf_pct = max(limits.min_policy_pct, limits.min_sysfs_pct); + limits.min_perf_pct = min(limits.max_policy_pct, limits.min_perf_pct); + limits.min_perf = div_fp(int_tofp(limits.min_perf_pct), int_tofp(100)); limits.max_perf_pct = min(limits.max_policy_pct, limits.max_sysfs_pct); + limits.max_perf_pct = max(limits.min_policy_pct, limits.max_perf_pct); limits.max_perf = div_fp(int_tofp(limits.max_perf_pct), int_tofp(100)); if (hwp_active) -- 1.8.3.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: [ftrace] possible to implement user-space tracers?
Hi Scotty I have read your links. I found the read from 'trace' and the write to 'trace_marker' are normal read which works like proc system. I have questions that what's more difference between ftrace and proc? I just know I could read data as pipeline from ftrace. On Wed, Aug 12, 2015 at 10:25 AM, Kun Huang wrote: > Thank you for your help Scotty :) I'm reading it. > > On Wed, Aug 12, 2015 at 2:34 AM, Scotty Bauer wrote: >> It is possible to trace from userland, Android does it. >> >> Essentially you need to write your data into >> /sys/kernel/debug/tracing/trace_marker >> >> then read it out of /sys/kernel/debug/tracing/trace >> >> >> If you care how the implementation works you can read it in >> /kernel/tracing/trace.c >> (http://lxr.free-electrons.com/source/kernel/trace/trace.c) search for >> tracing_mark_fops and tracing_fops. >> >> >> In Android here are the relevant files you will need to see how it's used in >> userland: >> Atrace (for reading data out + setting things up): >> https://android.googlesource.com/platform/frameworks/native/+/master/cmds/atrace/atrace.cpp >> https://android.googlesource.com/platform/external/chromium-trace/+/master >> (host side setup of the device) >> >> trace-dev (for writing data in): >> https://android.googlesource.com/platform/system/core/+/master/libcutils/trace-dev.c >> >> Once we have all the data we usually run it through trace-viewer, >> (https://github.com/catapult-project/catapult) >> >> Cheers. >> >> >>> On 2015-08-11 06:53, Kun Huang wrote: Hi ftrace developers I'm developing a huge python based programs and facing performance issue everyday. I like the ftrace system and hope there could be a tracer to trace my python codes. Is it possible or is it >>> >>> worthy to do this? --- Kun -- 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 >>> >>> [6] Please read the FAQ at http://www.tux.org/lkml/ [7] >>> >>> >>> Links: >>> -- >>> [1] http://lxr.free-electrons.com/source/kernel/trace/trace.c >>> [2] >>> >>> https://android.googlesource.com/platform/frameworks/native/+/master/cmds/atrace/atrace.cpp >>> [3] >>> https://android.googlesource.com/platform/external/chromium-trace/+/master >>> [4] >>> >>> https://android.googlesource.com/platform/system/core/+/master/libcutils/trace-dev.c >>> [5] https://github.com/catapult-project/catapult >>> [6] http://vger.kernel.org/majordomo-info.html >>> [7] http://www.tux.org/lkml/ -- 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/
linux-next: build failure after merge of the v4l-dvb tree
Hi Mauro,
After merging the v4l-dvb tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
ERROR (phandle_references): Reference to non-existent node or label "ssc2"
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target
'arch/arm/boot/dts/stih410-b2120.dtb' failed
ERROR (phandle_references): Reference to non-existent node or label "ssc2"
ERROR: Input tree has errors, aborting (use -f to force output)
scripts/Makefile.lib:293: recipe for target
'arch/arm/boot/dts/stih407-b2120.dtb' failed
Caused by commit
5d8877b6ae0d ("[media] ARM: DT: STi: STiH407: Add c8sectpfe LinuxDVB DT node")
I have used the v4l-dvb tree from next-20150810 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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/
linux-next: manual merge of the crypto tree with the imx-mxs tree
Hi Herbert,
Today's linux-next merge of the crypto tree got a conflict in:
arch/arm/configs/imx_v6_v7_defconfig
between commit:
351265f46291 ("ARM: imx_v6_v7_defconfig: build in audio driver")
from the imx-mxs tree and commit:
ab86ca0755ec ("ARM: imx_v6_v7_defconfig: Select CAAM")
from the crypto tree.
I fixed it up (they both removed the same line) and can carry the fix
as necessary (no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] ACPI / EC: Fix an issue caused by the serialized _Qxx evaluations.
It is proven that Windows evaluates _Qxx handlers in a parallel way. This
patch follows this fact, splits _Qxx evaluations from the NOTIFY queue to
form a separate queue, so that _Qxx evaluations can be queued up on
different CPUs rather than being queued up on a CPU0 bound queue.
Event handling related callbacks are also renamed and sorted in this patch.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Reported-and-tested-by: Gabriele Mazzotta
Signed-off-by: Lv Zheng
---
drivers/acpi/ec.c | 76 ++---
1 file changed, 55 insertions(+), 21 deletions(-)
Index: linux-acpica/drivers/acpi/ec.c
===
--- linux-acpica.orig/drivers/acpi/ec.c
+++ linux-acpica/drivers/acpi/ec.c
@@ -161,8 +161,16 @@ struct transaction {
u8 flags;
};
+struct acpi_ec_query {
+ struct transaction transaction;
+ struct work_struct work;
+ struct acpi_ec_query_handler *handler;
+};
+
static int acpi_ec_query(struct acpi_ec *ec, u8 *data);
static void advance_transaction(struct acpi_ec *ec);
+static void acpi_ec_event_handler(struct work_struct *work);
+static void acpi_ec_event_processor(struct work_struct *work);
struct acpi_ec *boot_ec, *first_ec;
EXPORT_SYMBOL(first_ec);
@@ -974,60 +982,90 @@ void acpi_ec_remove_query_handler(struct
}
EXPORT_SYMBOL_GPL(acpi_ec_remove_query_handler);
-static void acpi_ec_run(void *cxt)
+static struct acpi_ec_query *acpi_ec_create_query(u8 *pval)
{
- struct acpi_ec_query_handler *handler = cxt;
+ struct acpi_ec_query *q;
+ struct transaction *t;
+
+ q = kzalloc(sizeof (struct acpi_ec_query), GFP_KERNEL);
+ if (!q)
+ return NULL;
+ INIT_WORK(>work, acpi_ec_event_processor);
+ t = >transaction;
+ t->command = ACPI_EC_COMMAND_QUERY;
+ t->rdata = pval;
+ t->rlen = 1;
+ return q;
+}
+
+static void acpi_ec_delete_query(struct acpi_ec_query *q)
+{
+ if (q) {
+ if (q->handler)
+ acpi_ec_put_query_handler(q->handler);
+ kfree(q);
+ }
+}
+
+static void acpi_ec_event_processor(struct work_struct *work)
+{
+ struct acpi_ec_query *q = container_of(work, struct acpi_ec_query,
work);
+ struct acpi_ec_query_handler *handler = q->handler;
- if (!handler)
- return;
ec_dbg_evt("Query(0x%02x) started", handler->query_bit);
if (handler->func)
handler->func(handler->data);
else if (handler->handle)
acpi_evaluate_object(handler->handle, NULL, NULL, NULL);
ec_dbg_evt("Query(0x%02x) stopped", handler->query_bit);
- acpi_ec_put_query_handler(handler);
+ acpi_ec_delete_query(q);
}
static int acpi_ec_query(struct acpi_ec *ec, u8 *data)
{
u8 value = 0;
int result;
- acpi_status status;
struct acpi_ec_query_handler *handler;
- struct transaction t = {.command = ACPI_EC_COMMAND_QUERY,
- .wdata = NULL, .rdata = ,
- .wlen = 0, .rlen = 1};
+ struct acpi_ec_query *q;
+
+ q = acpi_ec_create_query();
+ if (!q)
+ return -ENOMEM;
/*
* Query the EC to find out which _Qxx method we need to evaluate.
* Note that successful completion of the query causes the ACPI_EC_SCI
* bit to be cleared (and thus clearing the interrupt source).
*/
- result = acpi_ec_transaction(ec, );
- if (result)
- return result;
- if (data)
- *data = value;
+ result = acpi_ec_transaction(ec, >transaction);
if (!value)
- return -ENODATA;
+ result = -ENODATA;
+ if (result)
+ goto err_exit;
mutex_lock(>mutex);
list_for_each_entry(handler, >list, node) {
if (value == handler->query_bit) {
- /* have custom handler for this bit */
- handler = acpi_ec_get_query_handler(handler);
+ q->handler = acpi_ec_get_query_handler(handler);
ec_dbg_evt("Query(0x%02x) scheduled",
- handler->query_bit);
- status = acpi_os_execute((handler->func) ?
- OSL_NOTIFY_HANDLER : OSL_GPE_HANDLER,
- acpi_ec_run, handler);
- if (ACPI_FAILURE(status))
+ q->handler->query_bit);
+ /*
+* It is reported that _Qxx are evaluated in a
+* parallel way on Windows:
+* https://bugzilla.kernel.org/show_bug.cgi?id=94411
+*/
+ if (!schedule_work(>work))
result = -EBUSY;
Re: [PATCH net] netconsole: Check for carrier before calling netpoll_send_udp()
> I personally think that drivers need to synchronize such things > internally. They are the only entity which knows when it's "OK" > to do whatever the netpoll method does, and they are also the only > entity which can properly synchronize such checks. Thanks agreed. I am testing the following ixgbe patch on my reproducer that checks for resetting/removing/down state flags in ixgbe_poll() and bails if true. It does that check in other ixgbe routines as well. It's working fine so far. We will need to do something similar for vmxnet3 as well and possibly other drivers. --- a/drivers/net/ixgbe/ixgbe_main.c 2015-08-10 17:13:02.899400508 +1000 +++ b/drivers/net/ixgbe/ixgbe_main.c.patch 2015-08-12 11:34:49.951053887 +1000 @@ -2672,6 +2672,11 @@ int per_ring_budget; bool clean_complete = true; + if (test_bit(__IXGBE_DOWN, >state) || +test_bit(__IXGBE_REMOVING, >state) || +test_bit(__IXGBE_RESETTING, >state)) + return budget; + #ifdef CONFIG_IXGBE_DCA if (adapter->flags & IXGBE_FLAG_DCA_ENABLED) ixgbe_update_dca(q_vector); -- 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] x86/mce: fix failed to reenable cmci when swiching to interrupt mode
Zhang Liguang report a bug as bellow:
1) system detected cmci storm on current cpu
2) disable cmci interrupt on banks ownd by current cpu, then swiching to poll
mode
3) a few minites later, system swiching to interrupt mode on current cpu
4) we expect system to reenable cmci interrupt on banks ownd by current cpu
mce_intel_adjust_timer
|-> cmci_reenable
|-> cmci_discover # but, ownd banks is ignore here
> static void cmci_discover(int banks)
> ...
> for (i = 0; i < banks; i++) {
> ...
> if (test_bit(i, owned)) # ownd banks is ignore here
> continue;
In this patch, we add a func cmci_storm_set_cmci(), just to enable or
disable banks which ownd by current cpu without clean the ownd flags.
Reported-by: Zhang Liguang
Cc: sta...@vger.kernel.org # v3.15+
Signed-off-by: Xie XiuQi
---
arch/x86/kernel/cpu/mcheck/mce_intel.c | 41 +++---
1 file changed, 23 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce_intel.c
b/arch/x86/kernel/cpu/mcheck/mce_intel.c
index 844f56c..a20e18b 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_intel.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_intel.c
@@ -146,6 +146,27 @@ void mce_intel_hcpu_update(unsigned long cpu)
per_cpu(cmci_storm_state, cpu) = CMCI_STORM_NONE;
}
+static void cmci_storm_set_cmci(bool on)
+{
+ unsigned long flags, *owned;
+ int bank;
+ u64 val;
+
+ raw_spin_lock_irqsave(_discover_lock, flags);
+ owned = this_cpu_ptr(mce_banks_owned);
+ for_each_set_bit(bank, owned, MAX_NR_BANKS) {
+ rdmsrl(MSR_IA32_MCx_CTL2(bank), val);
+
+ if (on)
+ val |= MCI_CTL2_CMCI_EN;
+ else
+ val &= ~MCI_CTL2_CMCI_EN;
+
+ wrmsrl(MSR_IA32_MCx_CTL2(bank), val);
+ }
+ raw_spin_unlock_irqrestore(_discover_lock, flags);
+}
+
unsigned long cmci_intel_adjust_timer(unsigned long interval)
{
if ((this_cpu_read(cmci_backoff_cnt) > 0) &&
@@ -175,7 +196,7 @@ unsigned long cmci_intel_adjust_timer(unsigned long
interval)
*/
if (!atomic_read(_storm_on_cpus)) {
__this_cpu_write(cmci_storm_state, CMCI_STORM_NONE);
- cmci_reenable();
+ cmci_storm_set_cmci(true);
cmci_recheck();
}
return CMCI_POLL_INTERVAL;
@@ -186,22 +207,6 @@ unsigned long cmci_intel_adjust_timer(unsigned long
interval)
}
}
-static void cmci_storm_disable_banks(void)
-{
- unsigned long flags, *owned;
- int bank;
- u64 val;
-
- raw_spin_lock_irqsave(_discover_lock, flags);
- owned = this_cpu_ptr(mce_banks_owned);
- for_each_set_bit(bank, owned, MAX_NR_BANKS) {
- rdmsrl(MSR_IA32_MCx_CTL2(bank), val);
- val &= ~MCI_CTL2_CMCI_EN;
- wrmsrl(MSR_IA32_MCx_CTL2(bank), val);
- }
- raw_spin_unlock_irqrestore(_discover_lock, flags);
-}
-
static bool cmci_storm_detect(void)
{
unsigned int cnt = __this_cpu_read(cmci_storm_cnt);
@@ -223,7 +228,7 @@ static bool cmci_storm_detect(void)
if (cnt <= CMCI_STORM_THRESHOLD)
return false;
- cmci_storm_disable_banks();
+ cmci_storm_set_cmci(false);
__this_cpu_write(cmci_storm_state, CMCI_STORM_ACTIVE);
r = atomic_add_return(1, _storm_on_cpus);
mce_timer_kick(CMCI_STORM_INTERVAL);
--
2.0.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/
Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On 2015/8/4 3:44, Alexei Starovoitov wrote:
[SNIP]
I'll post 2 LLVM patches by replying this mail. Please have a look and
help me
send them to LLVM if you think my code is correct.
[SNIP]
patch 2:
do we really need to hack clang?
Can you just define a function that aliases to intrinsic,
like we do for ld_abs/ld_ind ?
void bpf_store_half(void *skb, u64 off, u64 val)
asm("llvm.bpf.store.half");
then no extra patches necessary.
Hi Alexei,
By two weeks researching, I have to give you a sad answer that:
target specific intrinsic is not work.
I tried target specific intrinsic. However, LLVM isolates backend and
frontend, and there's no way to pass language level type information
to backend code.
Think about a program like this:
struct strA { int a; }
struct strB { int b; }
int func() {
struct strA a;
struct strB b;
a.a = 1;
b.b = 2;
bpf_output(gettype(a), );
bpf_output(gettype(b), );
return 0;
}
BPF backend can't (and needn't) tell the difference between local
variables a and b in theory. In LLVM implementation, it filters type
information out using ComputeValueVTs(). Please have a look at
SelectionDAGBuilder::visitIntrinsicCall in
lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp and
SelectionDAGBuilder::visitTargetIntrinsic in the same file. in
visitTargetIntrinsic, ComputeValueVTs acts as a barrier which strips
type information out from CallInst ("I"), and leave SDValue and SDVTList
("Ops" and "VTs") to target code. SDValue and SDVTList are wrappers of
EVT and MVT, all information we concern won't be passed here.
I think now we have 2 choices:
1. Hacking into clang, implement target specific builtin function. Now I
have worked out a ugly but workable patch which setup a builtin
function:
__builtin_bpf_typeid(), which accepts local or global variable then
returns different constant for different types.
2. Implementing an LLVM intrinsic call (llvm.typeid), make it be
processed in
visitIntrinsicCall(). I think we can get something useful if it is
processed
with that function.
The next thing should be generating debug information to map type and
constants which issued by __builtin_bpf_typeid() or llvm.typeid. Now we
have a crazy idea that, if we limit the name of the structure to 8 bytes,
we can insert the name into a u64, then there would be no need to consider
type information in DWARF. For example, in the above sample code, gettype(a)
will issue 0x41727473 because its type is "strA". What do you think?
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: [PATCH v2 3/5] mm/hwpoison: introduce put_hwpoison_page to put refcount for memory error handling
On 8/12/15 7:24 AM, Andrew Morton wrote:
On Mon, 10 Aug 2015 19:28:21 +0800 Wanpeng Li wrote:
Introduce put_hwpoison_page to put refcount for memory
error handling.
...
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -922,6 +922,27 @@ int get_hwpoison_page(struct page *page)
}
EXPORT_SYMBOL_GPL(get_hwpoison_page);
+/**
+ * put_hwpoison_page() - Put refcount for memory error handling:
+ * @page: raw error page (hit by memory error)
+ */
+void put_hwpoison_page(struct page *page)
+{
+ struct page *head = compound_head(page);
+
+ if (PageHuge(head)) {
+ put_page(head);
+ return;
+ }
+
+ if (PageTransHuge(head))
+ if (page != head)
+ put_page(head);
+
+ put_page(page);
+}
+EXPORT_SYMBOL_GPL(put_hwpoison_page);
I don't believe the export is needed?
ERROR: "put_hwpoison_page" [mm/hwpoison-inject.ko] undefined!
So I'm afraid it should be needed.
Regards,
Wanpeng Li
--
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: [ftrace] possible to implement user-space tracers?
Thank you for your help Scotty :) I'm reading it. On Wed, Aug 12, 2015 at 2:34 AM, Scotty Bauer wrote: > It is possible to trace from userland, Android does it. > > Essentially you need to write your data into > /sys/kernel/debug/tracing/trace_marker > > then read it out of /sys/kernel/debug/tracing/trace > > > If you care how the implementation works you can read it in > /kernel/tracing/trace.c > (http://lxr.free-electrons.com/source/kernel/trace/trace.c) search for > tracing_mark_fops and tracing_fops. > > > In Android here are the relevant files you will need to see how it's used in > userland: > Atrace (for reading data out + setting things up): > https://android.googlesource.com/platform/frameworks/native/+/master/cmds/atrace/atrace.cpp > https://android.googlesource.com/platform/external/chromium-trace/+/master > (host side setup of the device) > > trace-dev (for writing data in): > https://android.googlesource.com/platform/system/core/+/master/libcutils/trace-dev.c > > Once we have all the data we usually run it through trace-viewer, > (https://github.com/catapult-project/catapult) > > Cheers. > > >> On 2015-08-11 06:53, Kun Huang wrote: >>> >>> Hi ftrace developers >>> >>> I'm developing a huge python based programs and facing performance >>> issue everyday. I like the ftrace system and hope there could be a >>> tracer to trace my python codes. Is it possible or is it >> >> worthy >>> >>> to do this? >>> >>> --- >>> >>> Kun >>> -- >>> 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 >> >> [6] >>> >>> Please read the FAQ at http://www.tux.org/lkml/ [7] >> >> >> Links: >> -- >> [1] http://lxr.free-electrons.com/source/kernel/trace/trace.c >> [2] >> >> https://android.googlesource.com/platform/frameworks/native/+/master/cmds/atrace/atrace.cpp >> [3] >> https://android.googlesource.com/platform/external/chromium-trace/+/master >> [4] >> >> https://android.googlesource.com/platform/system/core/+/master/libcutils/trace-dev.c >> [5] https://github.com/catapult-project/catapult >> [6] http://vger.kernel.org/majordomo-info.html >> [7] http://www.tux.org/lkml/ -- 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: rebalance printk
On 2015年08月12日 10:04, Greg Kroah-Hartman wrote:
> On Wed, Aug 12, 2015 at 09:53:58AM +0800, Pan Xinhui wrote:
>> Hi, Greg
>> thanks for your reply!
>> On 2015年08月12日 02:16, Greg Kroah-Hartman wrote:
>>> On Tue, Aug 11, 2015 at 07:23:01PM +0800, Pan Xinhui wrote:
From: Pan Xinhui
printk can be called in any context, It's very useful to output debug
info.
But it might cause very bad issues on some special cases. For example,
some driver hit errors, and it dumps many messages like reg values, etc.
Sometimes, printk is called when irqs disabled. This is OKay if there is
a few messages. But What would happen if many messages outputted by other
drivers at same time.
Here is the scenario.
CPUA CPUB
local_irq_save(flags);
printk()
while(..) {--> console_unlock
printk(...);
//hundreds or thousands loops
} //all messages flushed out to consoles
local_irq_restore(flags);
>>>
>>> Where are you seeing this type of scenario "in the wild"? Or is this
>>> just a "debug/bringup hardware" issue? We shouldn't be ever stuck in a
>>> printk that prints hundreds or thousands of loops, if so, we need to fix
>>> the kernel code that does that, as we do have control over this.
>>>
>>
>> Sorry for misleading. these loops are just an example. In real world,
>> there are many pr_info/pr_err when some drivers hit device errors to
>> dump debug information.
>
> That's not good, they should use dev_dbg() for that instead.
>
Agree, We changed some codes to use dev_dbg(). But some errors still need be
outputted immediately.
But when we enabled dynamic debug. there is not much difference... printk issue
still hit.
>> There is camera and sound test(multimedia test) in our side, we enable
>> dynamic_debug to collect logs to fix some weird issues. sound driver
>> will dump many reg/memory values, and camera will output a few logs
>> with irqs disabled. So we hit this printk issues very frequently, and
>> it blocks our tests indeed.
>
> Maybe those memory value dumps should be done through debugfs instead of
> printk?
>
These reg/memory runtime values must be outputted in time, they have changed at
any time..
>> As printk is announced that it could be used in most context, So I
>> prefer to enhance the stability of printk to handle such case.
>
> Stability is nice, but using printk for things it was never ment to be
> used for, isn't good. Especially if you are forced to add additional
> complexity to the printk logic just for these corner cases that no one
> uses :)
>
printk is very good, it does work in very complex context, including in
interrupt, etc.
However if we could make it better, then why not :)
My patch is a little complex. Sorry for that.
I would try to work out V2.
thanks
xinhui
> thanks,
>
> greg k-h
>
--
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 v3] align crash_notes allocation to make it be inside one physical page
People reported that crash_notes in /proc/vmcore were corrupted and
this cause crash kdump failure. With code debugging and log we got
the root cause. This is because percpu variable crash_notes are
allocated in 2 vmalloc pages. Currently percpu is based on vmalloc
by default. Vmalloc can't guarantee 2 continuous vmalloc pages
are also on 2 continuous physical pages. So when 1st kernel exports
the starting address and size of crash_notes through sysfs like below:
/sys/devices/system/cpu/cpux/crash_notes
/sys/devices/system/cpu/cpux/crash_notes_size
kdump kernel use them to get the content of crash_notes. However the
2nd part may not be in the next neighbouring physical page as we
expected if crash_notes are allocated accross 2 vmalloc pages. That's
why nhdr_ptr->n_namesz or nhdr_ptr->n_descsz could be very huge in
update_note_header_size_elf64() and cause note header merging failure
or some warnings.
In this patch change to call __alloc_percpu() to passed in the align
value by rounding crash_notes_size up to the nearest power of two.
This makes sure the crash_notes is allocated inside one physical page
since sizeof(note_buf_t) in all ARCHS is smaller than PAGE_SIZE.
Meanwhile add a BUILD_BUG_ON to break compile if size is bigger than
PAGE_SIZE since crash_notes definitely will be in 2 pages. That need
be avoided, and need be reported if it's unavoidable.
v1->v2:
Minfei mentioned percpu can't take align value bigger then PAGE_SIZE.
So limit align to be PAGE_SIZE at most.
v2->v3:
Change code and add code comments as Andrew suggested.
Signed-off-by: Baoquan He
---
kernel/kexec.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index 35d9e0a..293fe64 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1620,7 +1620,24 @@ void crash_save_cpu(struct pt_regs *regs, int cpu)
static int __init crash_notes_memory_init(void)
{
/* Allocate memory for saving cpu registers. */
- crash_notes = alloc_percpu(note_buf_t);
+ size_t size, align;
+
+ /* crash_notes could be allocated across 2 vmalloc pages when percpu
+* is vmalloc based . vmalloc doesn't guarantee 2 continuous vmalloc
+* pages are also on 2 continuous physical pages. In this case the
+* 2nd part of crash_notes in 2nd page could be lost since only the
+* starting address and size of crash_notes are exported through sysfs.
+* Here round up the size of crash_notes to the nearest power of two
+* and pass it to __alloc_percpu as align value. This can make sure
+* crash_notes is allocated inside one physical page. */
+ size = sizeof(note_buf_t);
+ align = min(roundup_pow_of_two(sizeof(note_buf_t)), PAGE_SIZE);
+
+ /* Break compile if size is bigger than PAGE_SIZE since crash_notes
+* definitely will be in 2 pages with that. */
+ BUILD_BUG_ON(size > PAGE_SIZE);
+
+ crash_notes = __alloc_percpu(size, align);
if (!crash_notes) {
pr_warn("Kexec: Memory allocation for saving cpu register
states failed\n");
return -ENOMEM;
--
1.9.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] x86/mce: fix failed to reenable cmci when swiching to interrupt mode
On 2015/8/12 2:52, Luck, Tony wrote: Well, ok, but do it differently, please: rename cmci_storm_disable_banks() to cmci_storm_switch_banks(bool on) which turns them on and off. Unless Tony has a better suggestion... I like the boolean argument ... but not the "switch_banks" name. It sounds more like we are juggling between banks, rather than setting a switch/flag in a bank. How does "cmci_storm_set_cmci(bool on)" sound? Too many "cmci" in one name? Thanks, I'll use this name. -- Xie XiuQi -Tony -- 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] x86/mce: fix failed to reenable cmci when swiching to interrupt mode
On 2015/8/11 22:46, Borislav Petkov wrote:
On Tue, Aug 11, 2015 at 06:09:37PM +0800, Xie XiuQi wrote:
Zhang Liguang report a bug as bellow:
1) system detected cmci storm on current cpu
2) disable cmci interrupt on banks ownd by current cpu, then swiching to poll
mode
3) a few minites later, system swiching to interrupt mode on current cpu
4) we expect system to reenable cmci interrupt on banks ownd by current cpu
mce_intel_adjust_timer
|-> cmci_reenable
|-> cmci_discover # but, ownd banks is ignore here
static void cmci_discover(int banks)
...
for (i = 0; i < banks; i++) {
...
if (test_bit(i, owned)) # ownd banks is ignore here
continue;
In this patch, we add a func cmci_storm_enable_banks(), just to enable banks
which ownd by current cpu without clean the ownd flags. We call this func
instead of cmci_reenble() when swiching to interrupt mode.
Hmm, and we cannot clear the owned bit because those banks won't be
polled otherwise, see:
27f6c573e0f7 ("x86, CMCI: Add proper detection of end of CMCI storms")
OK, thanks.
Yuck.
Well, ok, but do it differently, please: rename
cmci_storm_disable_banks() to cmci_storm_switch_banks(bool on) which
turns them on and off. Unless Tony has a better suggestion...
Reported-by: Zhang Liguang
Cc: sta...@vger.kernel.org # v4.1+
Why 4.1 only?
My fault, it's v3.15+.
Thanks,
Xie XiuQi
--
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: rebalance printk
On Wed, Aug 12, 2015 at 09:53:58AM +0800, Pan Xinhui wrote:
> Hi, Greg
> thanks for your reply!
> On 2015年08月12日 02:16, Greg Kroah-Hartman wrote:
> > On Tue, Aug 11, 2015 at 07:23:01PM +0800, Pan Xinhui wrote:
> >> From: Pan Xinhui
> >>
> >> printk can be called in any context, It's very useful to output debug
> >> info.
> >>
> >> But it might cause very bad issues on some special cases. For example,
> >> some driver hit errors, and it dumps many messages like reg values, etc.
> >>
> >> Sometimes, printk is called when irqs disabled. This is OKay if there is
> >> a few messages. But What would happen if many messages outputted by other
> >> drivers at same time.
> >>
> >> Here is the scenario.
> >> CPUA CPUB
> >>local_irq_save(flags);
> >>printk()
> >> while(..) {--> console_unlock
> >>printk(...);
> >>//hundreds or thousands loops
> >> } //all messages flushed out to consoles
> >>local_irq_restore(flags);
> >>
> >
> > Where are you seeing this type of scenario "in the wild"? Or is this
> > just a "debug/bringup hardware" issue? We shouldn't be ever stuck in a
> > printk that prints hundreds or thousands of loops, if so, we need to fix
> > the kernel code that does that, as we do have control over this.
> >
>
> Sorry for misleading. these loops are just an example. In real world,
> there are many pr_info/pr_err when some drivers hit device errors to
> dump debug information.
That's not good, they should use dev_dbg() for that instead.
> There is camera and sound test(multimedia test) in our side, we enable
> dynamic_debug to collect logs to fix some weird issues. sound driver
> will dump many reg/memory values, and camera will output a few logs
> with irqs disabled. So we hit this printk issues very frequently, and
> it blocks our tests indeed.
Maybe those memory value dumps should be done through debugfs instead of
printk?
> As printk is announced that it could be used in most context, So I
> prefer to enhance the stability of printk to handle such case.
Stability is nice, but using printk for things it was never ment to be
used for, isn't good. Especially if you are forced to add additional
complexity to the printk logic just for these corner cases that no one
uses :)
thanks,
greg k-h
--
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 5/5] samples/bpf: example of get selected PMU counter value
On 8/6/15 12:02 AM, Kaixu Xia wrote: This is a simple example and shows how to use the new ability to get the selected Hardware PMU counter value. Signed-off-by: Kaixu Xia --- samples/bpf/Makefile | 4 +++ samples/bpf/bpf_helpers.h | 2 ++ samples/bpf/tracex6_kern.c | 26 ++ samples/bpf/tracex6_user.c | 68 ++ 1. I see a bunch of warnings building it: HOSTCC samples/bpf/tracex6_user.o ../samples/bpf/tracex6_user.c: In function ‘test_bpf_perf_event’: ../samples/bpf/tracex6_user.c:49:2: warning: passing argument 1 of ‘close’ makes integer from pointer without a cast [enabled by default] In file included from ../samples/bpf/tracex6_user.c:2:0: /usr/include/unistd.h:354:12: note: expected ‘int’ but argument is of type ‘int *’ ../samples/bpf/tracex6_user.c:20:16: warning: unused variable ‘value’ [-Wunused-variable] ../samples/bpf/tracex6_user.c:42:8: warning: ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result] ../samples/bpf/tracex6_user.c:43:8: warning: ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result] ../samples/bpf/tracex6_user.c:44:8: warning: ignoring return value of ‘system’, declared with attribute warn_unused_result [-Wunused-result] HOSTLD samples/bpf/tracex6 HOSTCC samples/bpf/lathist_user.o HOSTLD samples/bpf/lathist clang -nostdinc -isystem /usr/lib/gcc/x86_64-linux-gnu/4.7/include -I../arch/x86/include -Iarch/x86/include/generated/uapi -Iarch/x86/include/generated -I../include -Iinclude -I../arch/x86/include/uapi -Iarch/x86/include/generated/uapi -I../include/uapi -Iinclude/generated/uapi -include ../include/linux/kconfig.h \ -D__KERNEL__ -Wno-unused-value -Wno-pointer-sign \ -O2 -emit-llvm -c ../samples/bpf/tracex6_kern.c -o -| ../tools/bpf/llvm/bld/Debug+Asserts/bin/llc -march=bpf -filetype=obj -o samples/bpf/tracex6_kern.o ../samples/bpf/tracex6_kern.c:13:22: warning: declaration of 'struct pt_regs' will not be visible outside of this function [-Wvisibility] int bpf_prog1(struct pt_regs *ctx) Please fix. 2. the example is incomplete. Please add read_trace_pipe() otherwise it exits without printing anything useful. 3. please replace ls and pwd with ls > /dev/null the spam on the screen is unnecessary. -- 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: rebalance printk
Hi, Greg
thanks for your reply!
On 2015年08月12日 02:16, Greg Kroah-Hartman wrote:
> On Tue, Aug 11, 2015 at 07:23:01PM +0800, Pan Xinhui wrote:
>> From: Pan Xinhui
>>
>> printk can be called in any context, It's very useful to output debug
>> info.
>>
>> But it might cause very bad issues on some special cases. For example,
>> some driver hit errors, and it dumps many messages like reg values, etc.
>>
>> Sometimes, printk is called when irqs disabled. This is OKay if there is
>> a few messages. But What would happen if many messages outputted by other
>> drivers at same time.
>>
>> Here is the scenario.
>> CPUA CPUB
>> local_irq_save(flags);
>> printk()
>> while(..) { --> console_unlock
>> printk(...);
>> //hundreds or thousands loops
>> }//all messages flushed out to consoles
>> local_irq_restore(flags);
>>
>
> Where are you seeing this type of scenario "in the wild"? Or is this
> just a "debug/bringup hardware" issue? We shouldn't be ever stuck in a
> printk that prints hundreds or thousands of loops, if so, we need to fix
> the kernel code that does that, as we do have control over this.
>
Sorry for misleading. these loops are just an example. In real world, there are
many pr_info/pr_err when some drivers
hit device errors to dump debug information.
There is camera and sound test(multimedia test) in our side, we enable
dynamic_debug to collect logs to fix some weird issues.
sound driver will dump many reg/memory values, and camera will output a few
logs with irqs disabled. So we hit this printk issues
very frequently, and it blocks our tests indeed.
Although we have other log-store methods, for example, pstore. But some boards
are from customers, thanks to the security, every time
boards powered up, memory are erased
As printk is announced that it could be used in most context, So I prefer to
enhance the stability of printk to handle such case.
thanks
xinhui
> thanks,
>
> greg k-h
>
--
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/5] x86, gfp: Cache best near node for memory allocation.
On 2015/8/9 14:15, Tang Chen wrote: > Hi Liu, > > Have you posted your new patches ? > (I mean memory-less node support patches.) Hi Chen, I have rebased my patches to v4.2-rc4, but unfortunately it breaks. Seems there are some changes in x86 NUMA support since 3.17. I need some time to figure it out. > > If you are going to post them, please cc me. Sure. > > And BTW, how did you reproduce the memory-less node problem ? > Do you have a real memory-less node on your machine ? Yes, we have a system with memoryless nodes. Thanks! Gerry -- 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 0/4] clk: hisilicon: support stub clock
Hi Stephen, On Tue, Aug 11, 2015 at 05:38:17PM -0700, Stephen Boyd wrote: > On 08/04, Leo Yan wrote: > > This series adds support for hisilicon stub clock driver. On hi6220, > > the bootloader needs load the firmware image and set info for OPPs; > > after run into kernel, the stub clock driver is used to communicate > > w/t firmware for cpu dynamic frequency scaling. > > > > In patch series v1/v2, the stub clock driver simply writes request in > > sram and send ipc to firmware; For patch series v3, the firmware has > > been upgraded to use mailbox, so stub clock driver will call standard > > mailbox APIs to request mailbox channel and send message to firmware. > > > > Patch 4 adds stub clock node into dts and it references mailbox with > > phandle, so patch 4 will depend on mailbox driver's patch series [1]. > > These patches have been tested on 96board hikey and is used by cpufreq > > driver. > > The To: list is everyone, so I'm not sure who is supposed to > apply these patches. I'd like to take patches 1, 2, and 3 through > the clk tree though. Thanks, you could take first three patches. For patch 4, i will re-send it after mailbox driver's patches have been merged. Wei Xu, is this okay for you? Thanks, Leo Yan -- 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 2/2] i2c: mediatek: Fixup i2c ack error interrupt handling
> Or, did I not wait long enough? This. signature.asc Description: Digital signature
Re: [PATCH] printk: rebalance printk
hi, Peter
thanks for your reply!
On 2015年08月11日 20:00, Peter Hurley wrote:
> On 08/11/2015 07:23 AM, Pan Xinhui wrote:
>> From: Pan Xinhui
>>
>> printk can be called in any context, It's very useful to output debug
>> info.
>>
>> But it might cause very bad issues on some special cases. For example,
>> some driver hit errors, and it dumps many messages like reg values, etc.
>>
>> Sometimes, printk is called when irqs disabled. This is OKay if there is
>> a few messages. But What would happen if many messages outputted by other
>> drivers at same time.
>>
>> Here is the scenario.
>> CPUA CPUB
>> local_irq_save(flags);
>> printk()
>> while(..) { --> console_unlock
>> printk(...);
>> //hundreds or thousands loops
>> }//all messages flushed out to consoles
>> local_irq_restore(flags);
>>
>> printk runs on CPUA just store the messages in the buf and return.
>> printk runs on CPUB(who owns the console_sem lock) would take the duty
>> to flush all messages to consoles. It would take a long time to flush
>> messages out, IOW, irq would be disabled for a long time. Such case is
>> too bad. We hit many interrupt related panics, for example, cpu did not
>> respond to IPI.
>>
>> Here is the solution, if we detect such case above, try to rebalance it.
>> Let CPUA take the duty to flush messages to consoles.
>>
>> The idea is simple, but the implementation is a little difficult.
>> Introduce many help functions to fix it.
>
> Please describe the rebalance state machine/message passing in detail.
>
> Regards,
> Peter Hurley
>
yes, I should describe it more detailedly. Sorry for that.
I will send out V2.
thanks
xinhui
--
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/2] ARM64: dts: vexpress: Use assigned-clock-parents for sp810
The sp810 clk driver is calling the clk consumer APIs from
clk_prepare ops to change the parent to a 1 MHz fixed rate clock
for each of the clocks that the driver provides. Use
assigned-clock-parents for this instead of doing it in the driver
to avoid using the consumer API in provider code. This also
allows us to remove the usage of clk provider APIs that take a
struct clk as an argument from the sp810 driver.
Cc: Pawel Moll
Cc: Linus Walleij
Tested-by: Sudeep Holla
Signed-off-by: Stephen Boyd
---
This came out of a larger series to change this binding[1]. This
patch can go through arm-soc independently though, so please apply.
[1]
http://lkml.kernel.org/r/1438386285-5070-1-git-send-email-sb...@codeaurora.org
arch/arm64/boot/dts/arm/juno-motherboard.dtsi| 2 ++
arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi | 2 ++
2 files changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
index 021e0f40f419..637e046f0e36 100644
--- a/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-motherboard.dtsi
@@ -136,6 +136,8 @@
clock-names = "refclk", "timclk",
"apb_pclk";
#clock-cells = <1>;
clock-output-names = "timerclken0",
"timerclken1", "timerclken2", "timerclken3";
+ assigned-clocks = <_sysctl 0>,
<_sysctl 1>, <_sysctl 3>, <_sysctl 3>;
+ assigned-clock-parents =
<_refclk1mhz>, <_refclk1mhz>, <_refclk1mhz>, <_refclk1mhz>;
};
apbregs@01 {
diff --git a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
index c46cbb29f3c6..88a7583ed7a7 100644
--- a/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
+++ b/arch/arm64/boot/dts/arm/rtsm_ve-motherboard.dtsi
@@ -74,6 +74,8 @@
clock-names = "refclk", "timclk", "apb_pclk";
#clock-cells = <1>;
clock-output-names = "timerclken0",
"timerclken1", "timerclken2", "timerclken3";
+ assigned-clocks = <_sysctl 0>, <_sysctl
1>, <_sysctl 3>, <_sysctl 3>;
+ assigned-clock-parents = <_refclk1mhz>,
<_refclk1mhz>, <_refclk1mhz>, <_refclk1mhz>;
};
aaci@04 {
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 1/2] ARM: dts: vexpress: Use assigned-clock-parents for sp810
The sp810 clk driver is calling the clk consumer APIs from clk_prepare ops to change the parent to a 1 MHz fixed rate clock for each of the clocks that the driver provides. Use assigned-clock-parents for this instead of doing it in the driver to avoid using the consumer API in provider code. This also allows us to remove the usage of clk provider APIs that take a struct clk as an argument from the sp810 driver. Cc: Pawel Moll Cc: Linus Walleij Tested-by: Sudeep Holla Signed-off-by: Stephen Boyd --- This came out of a larger series to change this binding[1]. This patch can go through arm-soc independently though, so please apply. [1] http://lkml.kernel.org/r/1438386285-5070-1-git-send-email-sb...@codeaurora.org arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 2 ++ arch/arm/boot/dts/vexpress-v2m.dtsi | 2 ++ 2 files changed, 4 insertions(+) diff --git a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi index 2efb2058ba49..21b02874bea3 100644 --- a/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi +++ b/arch/arm/boot/dts/vexpress-v2m-rs1.dtsi @@ -101,6 +101,8 @@ clock-names = "refclk", "timclk", "apb_pclk"; #clock-cells = <1>; clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3"; + assigned-clocks = <_sysctl 0>, <_sysctl 1>, <_sysctl 3>, <_sysctl 3>; + assigned-clock-parents = <_refclk1mhz>, <_refclk1mhz>, <_refclk1mhz>, <_refclk1mhz>; }; /* PCI-E I2C bus */ diff --git a/arch/arm/boot/dts/vexpress-v2m.dtsi b/arch/arm/boot/dts/vexpress-v2m.dtsi index cb3090f919a7..e712c0af149b 100644 --- a/arch/arm/boot/dts/vexpress-v2m.dtsi +++ b/arch/arm/boot/dts/vexpress-v2m.dtsi @@ -100,6 +100,8 @@ clock-names = "refclk", "timclk", "apb_pclk"; #clock-cells = <1>; clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3"; + assigned-clocks = <_sysctl 0>, <_sysctl 1>, <_sysctl 3>, <_sysctl 3>; + assigned-clock-parents = <_refclk1mhz>, <_refclk1mhz>, <_refclk1mhz>, <_refclk1mhz>; }; /* PCI-E I2C bus */ -- The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- 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] driver/i2c/mux: Add register-based mux i2c-mux-reg
> Do I have to add myself to MAINTAINER file for this driver? Do you want to maintain this driver? signature.asc Description: Digital signature
Re: [PATCH v2 2/2] i2c: mediatek: Fixup i2c ack error interrupt handling
Hi Wolfram, On Tue, Aug 11, 2015 at 10:55 PM, Wolfram Sang wrote: > On Thu, Aug 06, 2015 at 03:22:11PM +0800, Eddie Huang wrote: >> When occur i2c ack error, i2c controller generate two interrupts, >> first is the ack error interrupt, then the complete interrupt. >> i2c interrupt handler should keep the two interrupt value, and only >> call complete() for the complete interrupt. >> >> Signed-off-by: Liguo Zhang >> Signed-off-by: Eddie Huang > > Applied to for-next, thanks! I don't see them in [0]. [0] https://git.kernel.org/cgit/linux/kernel/git/wsa/linux.git/log/?h=i2c/for-next Am I not looking in the right place? Or, did I not wait long enough? Thanks! -Dan -- 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] HID: gembird: add new driver to fix Gembird JPD-DualForce 2
This gamepad advertises 5 absolute axis while 4 are actually used.
The first Z axis shows some garbage, so it has to be ignored by HID.
The second Z axis and the Rz one are actually Rx and Ry. Remap them.
We could also just remap and ignore the axis in .input_mapping(). I
went ahead with .report_fixup() first, so here it is.
Reported-by: Orivej Desh
Tested-by: Orivej Desh
---
* Benjamin Tissoires
> so here are the fixes I mentioned yesterday. If you could give a quick shot
> and a "tested-by" that would be even better.
I tested your patch and it works as advertised, thank you! But your
comment about the implementation («re-assigning X to the original Z
axis») did not match the implementation, so I simplified the
implementation according to the comment, and tested it too. Since the
patch has changed, I think you need to sign it off again.
> Jiri, I am not sure if the .input_mapping() alternative would not be better.
> Both solutions are valid, so if you do not like my memcpys, I can re-write the
> patch the other way.
drivers/hid/Kconfig | 6
drivers/hid/Makefile | 1 +
drivers/hid/hid-core.c| 1 +
drivers/hid/hid-gembird.c | 77 +++
drivers/hid/hid-ids.h | 3 ++
5 files changed, 88 insertions(+)
create mode 100644 drivers/hid/hid-gembird.c
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 57c94d7..6ab51ae 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -251,6 +251,12 @@ config HID_EZKEY
---help---
Support for Ezkey BTC 8193 keyboard.
+config HID_GEMBIRD
+ tristate "Gembird Joypad"
+ depends on HID
+ ---help---
+ Support for Gembird JPD-DualForce 2.
+
config HID_HOLTEK
tristate "Holtek HID devices"
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index 2f8a41d..e6441bc 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_HID_EMS_FF) += hid-emsff.o
obj-$(CONFIG_HID_ELECOM) += hid-elecom.o
obj-$(CONFIG_HID_ELO) += hid-elo.o
obj-$(CONFIG_HID_EZKEY)+= hid-ezkey.o
+obj-$(CONFIG_HID_GEMBIRD) += hid-gembird.o
obj-$(CONFIG_HID_GT683R) += hid-gt683r.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_HOLTEK) += hid-holtek-kbd.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index e982e70..22afab9 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1844,6 +1844,7 @@ static const struct hid_device_id
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_EZKEY, USB_DEVICE_ID_BTC_8193) },
{ HID_USB_DEVICE(USB_VENDOR_ID_GAMERON,
USB_DEVICE_ID_GAMERON_DUAL_PSX_ADAPTOR) },
{ HID_USB_DEVICE(USB_VENDOR_ID_GAMERON,
USB_DEVICE_ID_GAMERON_DUAL_PCS_ADAPTOR) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_GEMBIRD,
USB_DEVICE_ID_GEMBIRD_JPD_DUALFORCE2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, 0x0003) },
{ HID_USB_DEVICE(USB_VENDOR_ID_GREENASIA, 0x0012) },
{ HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE)
},
diff --git a/drivers/hid/hid-gembird.c b/drivers/hid/hid-gembird.c
new file mode 100644
index 000..cefc394
--- /dev/null
+++ b/drivers/hid/hid-gembird.c
@@ -0,0 +1,77 @@
+/*
+ * HID driver for Gembird Joypad, "PC Game Controller"
+ *
+ * Copyright (c) 2015 Red Hat, Inc
+ * Copyright (c) 2015 Benjamin Tissoires
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)
+ * any later version.
+ */
+
+#include
+#include
+#include
+
+#include "hid-ids.h"
+
+#define GEMBIRD_START_FAULTY_RDESC 22
+
+/*
+ * This gamepad advertises 5 absolute axis while 4 are actually used.
+ * The first Z axis shows some garbage, so it has to be ignored by HID.
+ * The second Z axis and the Rz one are actually Rx and Ry. Remap them.
+ */
+
+static const __u8 gembird_jpd_faulty_rdesc[] = {
+ 0x09, 0x30, /* Usage (X) */
+ 0x09, 0x31, /* Usage (Y) */
+ 0x09, 0x32, /* Usage (Z) */
+ 0x09, 0x32, /* Usage (Z) */
+ 0x09, 0x35, /* Usage (Rz) */
+};
+static const __u8 gembird_jpd_fixed_rdesc[] = {
+ 0x09, 0x30, /* Usage (X) */
+ 0x09, 0x31, /* Usage (Y) */
+ 0x09, 0x30, /* Usage (X) (ignored)*/
+ 0x09, 0x33, /* Usage (Rx) */
+ 0x09, 0x34, /* Usage (Ry) */
+};
+
+static __u8 *gembird_report_fixup(struct hid_device *hdev,
[PATCH 2/2] userns,pidns: Force thread group sharing, not signal handler sharing
The code that places signals in signal queues computes the uids, gids,
and pids at the time the signals are enqueued. Which means that tasks
that share signal queues must be in the same pid and user namespaces.
Sharing signal handlers is fine, but bizarre.
So make the code in fork and userns_install clearer by only testing
for what is functionally necessary.
Also update the comment in unshare about unsharing a user namespace to
be a little more explicit and make a little more sense.
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 8
kernel/user_namespace.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 0edc437d5bb0..c9a4373a4d96 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1273,10 +1273,9 @@ static struct task_struct *copy_process(unsigned long
clone_flags,
/*
* If the new process will be in a different pid or user namespace
-* do not allow it to share a thread group or signal handlers or
-* parent with the forking task.
+* do not allow it to share a thread group with the forking task.
*/
- if (clone_flags & CLONE_SIGHAND) {
+ if (clone_flags & CLONE_THREAD) {
if ((clone_flags & (CLONE_NEWUSER | CLONE_NEWPID)) ||
(task_active_pid_ns(current) !=
current->nsproxy->pid_ns_for_children))
@@ -1940,7 +1939,8 @@ SYSCALL_DEFINE1(unshare, unsigned long, unshare_flags)
int err;
/*
-* If unsharing a user namespace must also unshare the thread.
+* If unsharing a user namespace must also unshare the thread group
+* and unshare the filesystem root and working directories.
*/
if (unshare_flags & CLONE_NEWUSER)
unshare_flags |= CLONE_THREAD | CLONE_FS;
diff --git a/kernel/user_namespace.c b/kernel/user_namespace.c
index 4109f8320684..f65a0a06a8c0 100644
--- a/kernel/user_namespace.c
+++ b/kernel/user_namespace.c
@@ -976,8 +976,8 @@ static int userns_install(struct nsproxy *nsproxy, struct
ns_common *ns)
if (user_ns == current_user_ns())
return -EINVAL;
- /* Threaded processes may not enter a different user namespace */
- if (atomic_read(>mm->mm_users) > 1)
+ /* Tasks that share a thread group must share a user namespace */
+ if (!thread_group_empty(current))
return -EINVAL;
if (current->fs->users != 1)
--
2.2.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 v2 1/5] clk: rockchip: rk3288: Add the clock id of eFuse
On 08/11, Shunqian Zheng wrote: > From: ZhengShunQian > > The clock id is necessary item, changing it from 0 > then can be referred in driver and device tree. > > Signed-off-by: ZhengShunQian > Reviewed-by: Heiko Stuebner > --- Acked-by: Stephen Boyd -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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 1/2] unshare: Unsharing a thread does not require unsharing a vm
In the logic in the initial commit of unshare made creating a new
thread group for a process, contingent upon creating a new memory
address space for that process. That is wrong. Two separate
processes in different thread groups can share a memory address space
and clone allows creation of such proceses.
This is significant because it was observed that mm_users > 1 does not
mean that a process is multi-threaded, as reading /proc/PID/maps
temporarily increments mm_users, which allows other processes to
(accidentally) interfere with unshare() calls.
Correct the check in check_unshare_flags() to test for
!thread_group_empty() for CLONE_THREAD, CLONE_SIGHAND, and CLONE_VM
and also for CLONE_VM check for !current_is_single_threaded instead
of mm_users > 1.
By using the correct checks in unshare this removes the possibility of
an accidental denial of service attack.
Additionally using the correct checks in unshare ensures that only an
explicit unshare(CLONE_VM) can possibly trigger the slow path of
current_is_single_threaded(). As an explict unshare(CLONE_VM) is
pointless it is not expected there are many applications that make
that call.
Cc: sta...@vger.kernel.org
Fixes: b2e0d98705e60e45bbb3c0032c48824ad7ae0704 userns: Implement unshare of
the user namespace
Reported-by: Ricky Zhou
Reported-by: Kees Cook
Signed-off-by: "Eric W. Biederman"
---
kernel/fork.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/kernel/fork.c b/kernel/fork.c
index 1bfefc6f96a4..0edc437d5bb0 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1866,13 +1866,17 @@ static int check_unshare_flags(unsigned long
unshare_flags)
CLONE_NEWUSER|CLONE_NEWPID))
return -EINVAL;
/*
-* Not implemented, but pretend it works if there is nothing to
-* unshare. Note that unsharing CLONE_THREAD or CLONE_SIGHAND
-* needs to unshare vm.
+* Not implemented, but pretend it works if there is nothing
+* to unshare. Note that unsharing the address space or the
+* signal handlers also need to unshare the signal queues (aka
+* CLONE_THREAD).
*/
if (unshare_flags & (CLONE_THREAD | CLONE_SIGHAND | CLONE_VM)) {
- /* FIXME: get_task_mm() increments ->mm_users */
- if (atomic_read(>mm->mm_users) > 1)
+ if (!thread_group_empty(current))
+ return -EINVAL;
+ }
+ if (unshare_flags & CLONE_VM) {
+ if (!current_is_single_threaded())
return -EINVAL;
}
@@ -1941,16 +1945,16 @@ SYSCALL_DEFINE1(unshare, unsigned long, unshare_flags)
if (unshare_flags & CLONE_NEWUSER)
unshare_flags |= CLONE_THREAD | CLONE_FS;
/*
-* If unsharing a thread from a thread group, must also unshare vm.
-*/
- if (unshare_flags & CLONE_THREAD)
- unshare_flags |= CLONE_VM;
- /*
* If unsharing vm, must also unshare signal handlers.
*/
if (unshare_flags & CLONE_VM)
unshare_flags |= CLONE_SIGHAND;
/*
+* If unsharing a signal handlers, must also unshare the signal queues.
+*/
+ if (unshare_flags & CLONE_SIGHAND)
+ unshare_flags |= CLONE_THREAD;
+ /*
* If unsharing namespace, must also unshare filesystem information.
*/
if (unshare_flags & CLONE_NEWNS)
--
2.2.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/
[PATCH 0/2] userns: Creation logic fixes
So I have take a good hard stare at the problem, as well as sitting down and writing some test code to verify the code works the way I think it does. The following two patches are how I think this bit of chaos needs to be solved. If folks could take a once over these patches and possibly test them to confirm they fix your issues I would appreciate it. Eric W. Biederman (2): unshare: Unsharing a thread does not require unsharing a vm userns,pidns: Force thread group sharing, not signal handler sharing. kernel/fork.c | 32 ++-- kernel/user_namespace.c | 4 ++-- 2 files changed, 20 insertions(+), 16 deletions(-) Eric -- 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/
[BUGFIX PATCH perf/core ] perf-probe: Fix to show lines of sys_ functions correctly
"perf probe --lines sys_poll" shows only the first line of
sys_poll, because the SYSCALL_DEFINE macro
SYSCALL_DEFINE*(foo,...)
{
body;
}
is expanded as below (on debuginfo)
static inline int SYSC_foo(...)
{
body;
}
int SyS_foo(...) <- is an alias of sys_foo.
{
return SYSC_foo(...);
}
So, "perf probe --lines sys_foo" decodes SyS_foo function and
it also skips inlined functions(SYSC_foo) inside the target
function because those functions are usually defined somewhere
else.
To fix this issue, this fix checks whether the inlined function
is defined at the same point of the target function, and if so,
it doesn't skip the inline function.
Reported-by: Arnaldo Carvalho de Melo
Signed-off-by: Masami Hiramatsu
---
tools/perf/util/dwarf-aux.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/tools/perf/util/dwarf-aux.c b/tools/perf/util/dwarf-aux.c
index 57f3ef4..445f455 100644
--- a/tools/perf/util/dwarf-aux.c
+++ b/tools/perf/util/dwarf-aux.c
@@ -734,15 +734,18 @@ int die_walk_lines(Dwarf_Die *rt_die,
line_walk_callback_t callback, void *data)
Dwarf_Lines *lines;
Dwarf_Line *line;
Dwarf_Addr addr;
- const char *fname;
+ const char *fname, *decf = NULL;
int lineno, ret = 0;
+ int decl = 0, inl;
Dwarf_Die die_mem, *cu_die;
size_t nlines, i;
/* Get the CU die */
- if (dwarf_tag(rt_die) != DW_TAG_compile_unit)
+ if (dwarf_tag(rt_die) != DW_TAG_compile_unit) {
cu_die = dwarf_diecu(rt_die, _mem, NULL, NULL);
- else
+ dwarf_decl_line(rt_die, );
+ decf = dwarf_decl_file(rt_die);
+ } else
cu_die = rt_die;
if (!cu_die) {
pr_debug2("Failed to get CU from given DIE.\n");
@@ -773,9 +776,14 @@ int die_walk_lines(Dwarf_Die *rt_die, line_walk_callback_t
callback, void *data)
* The line is included in given function, and
* no inline block includes it.
*/
- if (!dwarf_haspc(rt_die, addr) ||
- die_find_inlinefunc(rt_die, addr, _mem))
+ if (!dwarf_haspc(rt_die, addr))
continue;
+ if (die_find_inlinefunc(rt_die, addr, _mem)) {
+ dwarf_decl_line(_mem, );
+ if (inl != decl ||
+ decf != dwarf_decl_file(_mem))
+ continue;
+ }
/* Get source line */
fname = dwarf_linesrc(line, NULL, NULL);
--
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] user_ns: use correct check for single-threadedness
Oleg Nesterov writes: > On 08/06, Oleg Nesterov wrote: >> >> On 08/05, Eric W. Biederman wrote: >> > >> > So I have to ask. >> >> I hope you are asking someone else, not me ;) I never understood what >> exactly we try to restrict and why. >> >> > Is it possible to rework these checks such that we >> > look at the sighand struct and signal sharing handling sharing instead >> > of the count on the mm_struct? >> >> Then why we can't simply check thread_group_empty() == T ? Why should we >> worry about CLONE_SIGHAND at all? > > The same for clone() actually... I forgot why we decided to check > CLONE_SIGHAND, iirc I suggested CLONE_THREAD initially then we switched > to CLONE_SIGHAND "just in case", to make it as strict as possible. I do agree that making the test be for CLONE_THREAD is safe, makes sense, and is less confusing than what we have now.x > How about the patch below? > > (note that the "or parent" part of the comment is wrong in any case). It was correct. You failed to removed it when you removed CLONE_PARENT from that test. Eric -- 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: [BELATED CORE TOPIC] context tracking / nohz / RCU state
On Tue, Aug 11, 2015 at 5:51 PM, Paul E. McKenney wrote: > On Tue, Aug 11, 2015 at 02:52:59PM -0700, Andy Lutomirski wrote: >> On Tue, Aug 11, 2015 at 2:47 PM, Paul E. McKenney >> wrote: >> > On Tue, Aug 11, 2015 at 12:07:54PM -0700, Andy Lutomirski wrote: >> >> On Tue, Aug 11, 2015 at 11:33 AM, Paul E. McKenney >> >> wrote: >> >> > On Tue, Aug 11, 2015 at 10:49:36AM -0700, Andy Lutomirski wrote: >> >> >> This is a bit late, but here goes anyway. >> >> >> >> >> >> Having played with the x86 context tracking hooks for awhile, I think >> >> >> it would be nice if core code that needs to be aware of CPU context >> >> >> (kernel, user, idle, guest, etc) could come up with single, >> >> >> comprehensible, easily validated set of hooks that arch code is >> >> >> supposed to call. >> >> >> >> >> >> Currently we have: >> >> >> >> >> >> - RCU hooks, which come in a wide variety to notify about IRQs, NMIs, >> >> >> etc. >> >> > >> >> > Something about people yelling at me for waking up idle CPUs, thus >> >> > degrading their battery lifetimes. ;-) >> >> > >> >> >> - Context tracking hooks. Only used by some arches. Calling these >> >> >> calls the RCU hooks for you in most cases. They have weird >> >> >> interactions with interrupts and they're slow. >> >> > >> >> > Combining these would be good, but there are subtleties. For example, >> >> > some arches don't have context tracking, but RCU still needs to >> >> > correctly >> >> > identify idle CPUs without in any way interrupting or awakening that >> >> > CPU. >> >> > It would be good to make this faster, but it does have to work. >> >> >> >> Could we maybe have one set of old RCU-only (no context tracking) >> >> callbacks and a completely separate set of callbacks for arches that >> >> support full context tracking? The implementation of the latter would >> >> presumably call into RCU. >> > >> > It should be possible for RCU to use context tracking if it is available >> > and to have RCU maintain its own state otherwise, if that is what you >> > are getting at. Assuming that the decision is global and made at either >> > build or boot time, anyway. Having some CPUs tracking context and others >> > not sounds like an invitation for subtle bugs. >> >> I think that, if this happens, the decision should be made at build >> time, per arch, and not be configurable. If x86_64 uses context >> tracking, then I think x86_64 shouldn't need additional RCU callbacks, >> assuming that context tracking is comprehensive enough for RCU's >> purposes. > > If by "shouldn't need additional RCU callbacks" you mean that x86_64 > shouldn't need to call the existing rcu_user_enter() and rcu_user_exit() > functions, I agree. Ditto for rcu_irq_enter(), rcu_irq_exit(), > rcu_nmi_enter(), rcu_nmi_exit(), I would guess. But would be necessary > to invoke rcu_idle_enter() and rcu_idle_exit(), especially for > CONFIG_NO_HZ_FULL_SYSIDLE=y kernels. Except that something wants vtime for idle, too, so maybe just kernel_to_idle(). On the other hand, the idle loop is already fully stocked with vtime stuff. --Andy -- 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 4/4] rtc: s3c: enable/disable clocks for alarm
On 08/12/2015 09:28 AM, Krzysztof Kozlowski wrote:
> On 11.08.2015 20:28, Joonyoung Shim wrote:
>> The clock enable/disable codes for alarm have removed from
>
> What do you mean in this paragraph? The clock code was removing something?
>
>> 'commit 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock
>
> Remove the 'apostrophe.
>
>> control")' and the clocks keep disabling even if alarm is set, so alarm
>> interrupt can't happen.
> ...and the clocks are disabled even...
>
>
>>
>> The s3c_rtc_setaie function can be called several times with that
>> enabled argument has same value,
> ...several times with 'enabled' argument having same value
>
>> so it needs to check whether clocks is
>> enabled or not.
> s/is/are/
>
>>
>> Signed-off-by: Joonyoung Shim
>
> Please add Cc-stable and fixes tag. To backport the patch probably
> you'll have to remove the dependency on previous patches.
Thanks for the point, i didn't think it.
--
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] mtd: spi-nor: Add driver for Cadence Quad SPI Flash Controller.
Hi Marek,
> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Wednesday, August 05, 2015 4:15 PM
> To: Vikas MANOCHA
> Cc: Graham Moore; linux-...@lists.infradead.org; David Woodhouse; Brian
> Norris; linux-kernel@vger.kernel.org; Alan Tull; Dinh Nguyen; Yves
> Vandervennet
> Subject: Re: [PATCH V6 2/2] mtd: spi-nor: Add driver for Cadence Quad SPI
> Flash Controller.
>
> On Wednesday, August 05, 2015 at 08:29:11 PM, vikasm wrote:
> > Hi Graham,
>
> Hi vikasm,
>
> > On 07/28/2015 10:38 AM, Graham Moore wrote:
> > > Signed-off-by: Graham Moore
> > > ---
> > > V2: use NULL instead of modalias in spi_nor_scan call
> > > V3: Use existing property is-decoded-cs instead of creating duplicate.
> > > V4: Support Micron quad mode by snooping command stream for EVCR
> > > command and subsequently configuring Cadence controller for quad
> mode.
> > > V5: Clean up sparse and smatch complaints. Remove snooping of
> > > Micron quad mode. Add comment on XIP mode bit and dummy clock
> > > cycles. Set up SRAM partition at 1:1 during init.
> > > V6: Remove dts patch that was included by mistake. Incorporate
> > > Vikas's comments regarding fifo width, SRAM partition setting, and
> > > trigger address. Trigger address was added as an unsigned int, as
> > > it is not an IO resource per se, and does not need to be mapped.
> > > Also add Marek Vasut's workaround for picking up OF properties on
> subnodes.
> >
> > I am still not able to apply this patch to master. It seems to be
> > rebased on master for ..spi-nor/Kconfig & spi-nor/makefile.
>
> I'm able to apply this on next/master just fine.
I think my thunderbird client is messing up with the patch, I am trying to fix
it.
>
> > Also I still see spaces are still not replaced by tabs in this version.
>
> Which exact spots are you talking about ? I don't see that many indent flubs
> in this patch to be honest. Sometimes, it is better to indent the last piece
> with spaces (mandated by kernel coding style btw) to increase the
> readability.
>
> This is in particular the case with stuff like this:
>
> pr_err("formating string that is almost 80 chars long %i!\n",
>parameter_that_is_indented_with_7_spaces);
>
> The sole purpose is to align stuff right under the opening parenthesis.
>
> > > ---
>
> btw. would you please learn to use [...] and keep only the part you're
> commenting on with a bit of context in your reply? It is really hard to locate
> your comment if it's inbetween 500 lines of nothing.
>
> [...]
Thanks Marek, I am not sure how to use it. I would appreciate any help.
>
> > > +static int cqspi_indirect_read_setup(struct spi_nor *nor,
> > > +unsigned int from_addr) {
> > > + unsigned int reg;
> > > + unsigned int dummy_clk = 0;
> > > + struct cqspi_st *cqspi = nor->priv;
> > > + void __iomem *reg_base = cqspi->iobase;
> > > +
> > > + writel(cqspi->trigger_address,
> > > + reg_base + CQSPI_REG_INDIRECTTRIGGER);
> >
> > move indirect trigger configuration in init, no need to do it for
> > every read & write.
>
> Fixed.
>
> > > + writel(from_addr, reg_base + CQSPI_REG_INDIRECTRDSTARTADDR);
> > > +
> > > + reg = nor->read_opcode << CQSPI_REG_RD_INSTR_OPCODE_LSB;
> > > + reg |= cqspi_calc_rdreg(nor, nor->read_opcode);
> > > +
> > > + /* Setup dummy clock cycles */ #define
> > > +CQSPI_SUPPORT_XIP_CHIPS #ifdef CQSPI_SUPPORT_XIP_CHIPS
> > > + /*
> > > +* Set mode bits high to ensure chip doesn't enter XIP.
> > > +* This results in an extra 8 dummy clocks so
> > > +* we must account for them.
> > > +*/
> > > + writel(0xFF, reg_base + CQSPI_REG_MODE_BIT);
> > > + reg |= (1 << CQSPI_REG_RD_INSTR_MODE_EN_LSB);
> > > + if (nor->read_dummy >= 8)
> > > + dummy_clk = nor->read_dummy - 8;
> > > + else
> > > + dummy_clk = 0;
> > > +#else
> > > + dummy_clk = nor->read_dummy; #endif
> > > + reg |= (dummy_clk & CQSPI_REG_RD_INSTR_DUMMY_MASK)
> > > + << CQSPI_REG_RD_INSTR_DUMMY_LSB;
> > > +
> > > + writel(reg, reg_base + CQSPI_REG_RD_INSTR);
> > > +
> > > + /* Set address width */
> > > + reg = readl(reg_base + CQSPI_REG_SIZE);
> > > + reg &= ~CQSPI_REG_SIZE_ADDRESS_MASK;
> > > + reg |= (nor->addr_width - 1);
> > > + writel(reg, reg_base + CQSPI_REG_SIZE);
> > > + return 0;
> > > +}
> > > +
> > > +static int cqspi_indirect_read_execute(struct spi_nor *nor,
> > > + u8 *rxbuf, unsigned n_rx) {
> > > + int ret = 0;
> > > + unsigned int reg = 0;
> > > + unsigned int bytes_to_read = 0;
> > > + unsigned int timeout;
> > > + unsigned int watermark;
> > > + struct cqspi_st *cqspi = nor->priv;
> > > + void __iomem *reg_base = cqspi->iobase;
> > > + void __iomem *ahb_base = cqspi->ahb_base;
> > > +
RE: [PATCH v2] staging: fsl-mc: add DPAA2 overview readme
> -Original Message- > From: Tillmann Heidsieck [mailto:theidsi...@leenox.de] > Sent: Tuesday, August 11, 2015 6:01 AM > To: Yoder Stuart-B08248; gre...@linuxfoundation.org; Rivera Jose-B46482; katz > Itai-RM05202 > Cc: de...@driverdev.osuosl.org; linux-kernel@vger.kernel.org; ag...@suse.de; > a...@arndb.de > Subject: Re: [PATCH v2] staging: fsl-mc: add DPAA2 overview readme > > Hi Stuart, > > I am by no means a native speaker, but I have proof-read my fair share of > articles and theses, so here are a > bunch of suggestions which might or might not help improve you document. > > On 07.08.2015 03:09, Stuart Yoder wrote: > > add README file providing an overview of the DPAA2 architecture > > and how it is integrated in Linux > > > > Signed-off-by: Stuart Yoder > > --- > > -v2: added changelog text > > > > drivers/staging/fsl-mc/README.txt | 364 > > ++ > > drivers/staging/fsl-mc/TODO | 4 - > > 2 files changed, 364 insertions(+), 4 deletions(-) > > create mode 100644 drivers/staging/fsl-mc/README.txt > > > > diff --git a/drivers/staging/fsl-mc/README.txt > > b/drivers/staging/fsl-mc/README.txt > > new file mode 100644 > > index 000..8214102 > > --- /dev/null > > +++ b/drivers/staging/fsl-mc/README.txt > > @@ -0,0 +1,364 @@ > > +Copyright (C) 2015 Freescale Semiconductor Inc. > > + > > +DPAA2 (Data Path Acceleration Architecture Gen2) > > + > > + > > +This document provides an overview of the Freescale DPAA2 architecture > > +and how it is integrated into the Linux kernel. > > + > > +Contents summary > > + -DPAA2 overview > > + -Overview of DPAA2 objects > > + -DPAA2 Linux driver architecture overview > > +-bus driver > > +-dprc driver > > - DPRC driver > > > +-allocator > > +-dpio driver > > - DPIO driver > > > +-Ethernet > > +-mac > mac -> MAC > > + > > +DPAA2 Overview > > +-- > > + > > +DPAA2 is a hardware architecture designed for high-speeed network > > +packet processing. DPAA2 consists of sophisticated mechanisms for > > +processing Ethernet packets, queue management, buffer management, > > +autonomous L2 switching, virtual Ethernet bridging, and accelerator > > +(e.g. crypto) sharing. > > + > > +A DPAA2 hardware component called the Management Complex (or MC) manages > > the > > +DPAA2 hardware resources. The MC provides an object-based abstraction for > > +software drivers to use the DPAA2 hardware. > > + > > +The MC uses DPAA2 hardware resources such as queues, buffer pools, and > > +network ports to create functional objects/devices such as network > > +interfaces, an L2 switch, or accelerator instances. > > + > > +The MC provides memory-mapped I/O command interfaces (MC portals) > > +which DPAA2 software drivers use to operate on DPAA2 objects: > > + > > + +--+ > > + | OS | > > + |DPAA2 drivers | > > + | || > > + +-|+ > > + | > > + | (create,discover,connect > > + | config,use,destroy) > > + | > > + DPAA2 | > > + +| mc portal |-+ > > + | || > > + | +- - - - - - - - - - - - -V- - -+ | > > + | | | | > > + | | Management Complex (MC) | | > > + | | | | > > + | +- - - - - - - - - - - - - - - -+ | > > + | | > > + | Hardware Hardware | > > + | Resources Objects| > > + | - ---| > > + | -queues -DPRC | > > + | -buffer pools -DPMCP | > > + | -Eth MACs/ports -DPIO | > > + | -network interface-DPNI | > > + | profiles -DPMAC | > > + | -queue portals-DPBP | > > + | -MC portals... | > > + | ... | > > + | | > > + +--+ > > + > > +The MC mediates operations such as create, discover, > > +connect, configuration, and destroy. Fast-path operations > > +on data, such as packet transmit/receive, are not mediated by > > +the MC and are done directly using memory mapped regions in > > +DPIO objects. > > + > > +Overview of DPAA2 Objects > > +- > > +The section provides a brief overview of
Re: [tip:x86/asm] x86/asm/entry/64: Migrate error and IRQ exit work to C and remove old assembly code
On Tue, Aug 11, 2015 at 03:59:37PM -0700, Andy Lutomirski wrote: > On Tue, Aug 11, 2015 at 3:49 PM, Frederic Weisbecker > wrote: > > On Tue, Aug 11, 2015 at 03:25:04PM -0700, Andy Lutomirski wrote: > >> Can you explain to me what context tracking does that rcu_irq_enter > >> and vtime_account_irq_enter don't do that's expensive? Frankly, I'd > >> rather drop everything except the context tracking callback. > > > > Irqs have their own hooks in the generic code. irq_enter() and irq_exit(). > > And those take care of RCU and time accounting already. So arch code really > > doesn't need to care about that. > > I'd love to have irq_enter_from_user and irq_enter_from_kernel instead. RCU would need to know about irq_enter_from_user(), but could blithely ignore irq_enter_from_kernel(). Unless irq_enter_from_kernel() is called from the idle loop, in which case RCU would need to know. All that aside, the overhead of rcu_irq_enter() when called from non-idle kernel mode should be relatively small. So just telling RCU about all the interrupts is actually not a bad strategy. > > context tracking exists for the sole purpose of tracking states that don't > > have generic hooks. Those are syscalls and exceptions. > > > > Besides, rcu_user_exit() is more costly than rcu_irq_enter() which have been > > designed for the very purpose of providing a fast RCU tracking for non > > sleepable > > code (which needs rcu_user_exit()). > > So rcu_user_exit is slower because it's okay to sleep after calling it? > > Would it be possible to defer the overhead until we actually try to > sleep rather than doing it on entry? (I have no idea what's going on > under the hood.) Nor do I, at least not until someone tells me what .config they are using. NO_HZ_FULL, NO_HZ_FULL_SYSIDLE, and RCU_FAST_NO_HZ make a difference in this case. > Anyway, irq_enter_from_user would solve this problem completely. > > > > > I've been thinking about pushing down syscalls and exceptions to generic > > handlers. It might work for syscalls btw. But many exceptions have only > > arch handlers, or significant amount of work is done on the arch level > > which might make use of RCU (eg: breakpoint handlers on x86). > > I'm trying to port the meat of the x86 syscall code to C. Maybe the > result will generalize. The exit code is already in C (in -tip). That does sound like a good thing! Thanx, Paul -- 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/6] sd: implement the persisten reservation API
> "Christoph" == Christoph Hellwig writes: Slightly more verbose patch description would be nice. Code looks OK. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering -- 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: [BELATED CORE TOPIC] context tracking / nohz / RCU state
On Tue, Aug 11, 2015 at 02:52:59PM -0700, Andy Lutomirski wrote: > On Tue, Aug 11, 2015 at 2:47 PM, Paul E. McKenney > wrote: > > On Tue, Aug 11, 2015 at 12:07:54PM -0700, Andy Lutomirski wrote: > >> On Tue, Aug 11, 2015 at 11:33 AM, Paul E. McKenney > >> wrote: > >> > On Tue, Aug 11, 2015 at 10:49:36AM -0700, Andy Lutomirski wrote: > >> >> This is a bit late, but here goes anyway. > >> >> > >> >> Having played with the x86 context tracking hooks for awhile, I think > >> >> it would be nice if core code that needs to be aware of CPU context > >> >> (kernel, user, idle, guest, etc) could come up with single, > >> >> comprehensible, easily validated set of hooks that arch code is > >> >> supposed to call. > >> >> > >> >> Currently we have: > >> >> > >> >> - RCU hooks, which come in a wide variety to notify about IRQs, NMIs, > >> >> etc. > >> > > >> > Something about people yelling at me for waking up idle CPUs, thus > >> > degrading their battery lifetimes. ;-) > >> > > >> >> - Context tracking hooks. Only used by some arches. Calling these > >> >> calls the RCU hooks for you in most cases. They have weird > >> >> interactions with interrupts and they're slow. > >> > > >> > Combining these would be good, but there are subtleties. For example, > >> > some arches don't have context tracking, but RCU still needs to correctly > >> > identify idle CPUs without in any way interrupting or awakening that CPU. > >> > It would be good to make this faster, but it does have to work. > >> > >> Could we maybe have one set of old RCU-only (no context tracking) > >> callbacks and a completely separate set of callbacks for arches that > >> support full context tracking? The implementation of the latter would > >> presumably call into RCU. > > > > It should be possible for RCU to use context tracking if it is available > > and to have RCU maintain its own state otherwise, if that is what you > > are getting at. Assuming that the decision is global and made at either > > build or boot time, anyway. Having some CPUs tracking context and others > > not sounds like an invitation for subtle bugs. > > I think that, if this happens, the decision should be made at build > time, per arch, and not be configurable. If x86_64 uses context > tracking, then I think x86_64 shouldn't need additional RCU callbacks, > assuming that context tracking is comprehensive enough for RCU's > purposes. If by "shouldn't need additional RCU callbacks" you mean that x86_64 shouldn't need to call the existing rcu_user_enter() and rcu_user_exit() functions, I agree. Ditto for rcu_irq_enter(), rcu_irq_exit(), rcu_nmi_enter(), rcu_nmi_exit(), I would guess. But would be necessary to invoke rcu_idle_enter() and rcu_idle_exit(), especially for CONFIG_NO_HZ_FULL_SYSIDLE=y kernels. Thanx, Paul -- 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: perf probe -L sys_select or sys_poll
> From: Arnaldo Carvalho de Melo [mailto:a...@kernel.org]
>
> Hi Masami,
>
> Have you noticed that sys_select or sys_poll stops after the
> first few lines? Please let me know if you need more info than is below.
>
> [root@zoo ~]# perf probe -L sys_select
>
> 0 SYSCALL_DEFINE5(select, int, n, fd_set __user *, inp, fd_set __user
> *, outp,
> fd_set __user *, exp, struct timeval __user *, tvp)
> {
> struct timespec end_time, *to = NULL;
>
> [root@zoo ~]# perf probe -L sys_poll
>
> 0 SYSCALL_DEFINE3(poll, struct pollfd __user *, ufds, unsigned int,
> nfds,
> int, timeout_msecs)
> {
> struct timespec end_time, *to = NULL;
>
> [root@zoo ~]#
>
> I haven't investigated it too much, if there is some trouble that makes
> 'perf probe -L' to stop like that maybe we should warn the user somehow?
>
> Using -v didn't helped that much:
>
> [root@zoo ~]# perf probe -v -L sys_poll
> Using /root/.debug/.build-id/a8/26726b5ddacfab1f0bade868f1a7924f6b20c4 for
> symbols
> Open Debuginfo file:
> /root/.debug/.build-id/a8/26726b5ddacfab1f0bade868f1a7924f6b20c4
> path: (null)
> Symbol sys_poll address found : 812297e0
> fname: /home/git/linux/fs/select.c, lineno:957
> New line range: 957 to 2147483647
> path: /home/git/linux/fs/select.c
>
> 0 SYSCALL_DEFINE3(poll, struct pollfd __user *, ufds, unsigned int,
> nfds,
> int, timeout_msecs)
> {
> struct timespec end_time, *to = NULL;
>
> [root@zoo ~]#
OK, I got what was wrong.
I've ingestigated and found that SYSCALL_DEFINE macro is doing
SYSCALL_DEFINE*(foo,...)
{
body;
}
is expanded as below (on debuginfo)
static inline int SYSC_foo(...)
{
body;
}
int SyS_foo(...) <- is an alias of sys_foo.
{
return SYSC_foo(...);
}
"perf probe -L sys_foo" decodes SyS_foo function and it also
skips inlined functions inside the target function because
those functions are usually defined somewhere else.
Thus, it shows only the first line of sys_foo.
BTW, since SYSC_foo doesn't have no instance, "perf probe -L SYSC_foo"
doesn't show anything.
I think we can avoid this problem by checking whether the inlined function
is defined at the same point of the target function definition.
Thank you,
--
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu...@hitachi.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 2/6] block: add a API for persistent reservations
> "Christoph" == Christoph Hellwig writes: Happy to see a generic interface for this. I wish PR semantics were simpler but the code looks good to me. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering -- 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: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
On Tue, Aug 11, 2015 at 5:17 PM, Stas Sergeev wrote: > Hi guys, I wonder how easily the include/uapi/* is being > changed these days. > The patch: > http://lkml.kernel.org/r/405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.l...@kernel.org > breaks dosemu (and perhaps everyone else who used > to restore the segregs by hands). And the fix involves > both autoconf magic and run-time magic, so it is not even > trivial. > I realize this patch may be good to have in general, but > breaking userspace without a single warning is a bit > discouraging. Seems like the old "we don't break userspace" > rule have gone. I didn't anticipate any breakage. I could have been wrong. Do you know what the actual breakage is? I'm curious how this ever worked for DOSEMU, given that, before this patch, it appeared to be impossible to return to any nonstandard SS from a 64-bit signal handler. FWIW, DOSEMU seems to work for me on recent kernels. We might still be able to require a new sigcontext flag to be set and to forcibly return to __USER_DS if the flag is set regardless of the ss value in sigcontext when sigreturn is called, if that is indeed the problem with DOSEMU. But I'm not actually sure that that's the problem. In fact, DOSEMU contains this: /* set up a frame to get back to DPMI via iret. The kernel does not save %ss, and the SYSCALL instruction in sigreturn() destroys it. IRET pops off everything in 64-bit mode even if the privilege does not change which is nice, but clobbers the high 48 bits of rsp if the DPMI client uses a 16-bit stack which is not so nice (see EMUfailure.txt). Setting %rsp to 0x1 so that bits 16-31 are zero works around this problem, as DPMI code can't see bits 32-63 anyway. */ So, if DOSEMU were to realize that both sigreturnissues it's complaining about are fixed in recent kernels, it could sigreturn directly back to any state. (It can't *directly* IRET back to a 16-bit state with properly controlled RSP, but it can do it via sigreturn.) I don't actually see any code in DOSEMU that generates a sigcontext from scratch (as opposed to copying one and modifying it), so I'm not entirely sure what the problem is. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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 0/4] clk: hisilicon: support stub clock
On 08/04, Leo Yan wrote: > This series adds support for hisilicon stub clock driver. On hi6220, > the bootloader needs load the firmware image and set info for OPPs; > after run into kernel, the stub clock driver is used to communicate > w/t firmware for cpu dynamic frequency scaling. > > In patch series v1/v2, the stub clock driver simply writes request in > sram and send ipc to firmware; For patch series v3, the firmware has > been upgraded to use mailbox, so stub clock driver will call standard > mailbox APIs to request mailbox channel and send message to firmware. > > Patch 4 adds stub clock node into dts and it references mailbox with > phandle, so patch 4 will depend on mailbox driver's patch series [1]. > These patches have been tested on 96board hikey and is used by cpufreq > driver. The To: list is everyone, so I'm not sure who is supposed to apply these patches. I'd like to take patches 1, 2, and 3 through the clk tree though. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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/6] block: cleanup blkdev_ioctl
> "Christoph" == Christoph Hellwig writes: Christoph> Split out helpers for all non-trivial ioctls to make this Christoph> function simpler, and also start passing around a pointer Christoph> version of the argument, as that's what most ioctl handlers Christoph> actually need. Looks good. Reviewed-by: Martin K. Petersen -- Martin K. Petersen Oracle Linux Engineering -- 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 4.1 099/267] phy: twl4030-usb: remove incorrect pm_runtime_get_sync() in probe function.
Hi, On Wed, Aug 12, 2015 at 08:09:27AM +1000, NeilBrown wrote: > On Tue, 11 Aug 2015 23:34:17 +0200 Alexander Holler > wrote: > > > Am 11.08.2015 um 10:29 schrieb NeilBrown: > > > > > With the current mainline code (plus my twl4030 charger enhancements, > > > which are not deeply relevant), the refcount does go to zero when > > > nothing is plugged in, and goes to 2 when a regular USB cable is > > > plugged in. > > > > Also I think it's just a little miswording (or extended typo), I'm not > > using a regular USB cable, but an OTG cable when using the host mode of > > the musb on the Beagleboard. Just to avoid confusion. Or do you talk > > about the client mode when it goes to 2? > > With an OTG cable, the usage_count would probably got to '1' because > the charger wouldn't be interested. > > However the important point is that the usage_count goes to zero when > no cable is plugged in. > > > > > Besides that, I'm sorry to not be of further help. My deeper knowledge > > about the musb sources in the kernel and u-boot (and the HW in > > question), has gone lost and I've currently no real reason to refresh > > that. ;) > > Just reporting the problem is sometimes 90% for the bug fixed. > I'm confident I know what is happening. What isn't clear is how best > to fix it without breaking something else... I suspect Felipe can help > with that. It'll take me a while to be able to look at this. I don't have any platform with TWL4030 (IIRC, AM335x uses tps65218 instead). Besides, I have a slightly bigger problem to look at (MUSB + some hubs + CP2108 fails sometimes). If I get some time, I'll try to have a look, but it might take a few weeks. cheers -- balbi signature.asc Description: Digital signature
Re: [PATCH 4/4] rtc: s3c: enable/disable clocks for alarm
On 11.08.2015 20:28, Joonyoung Shim wrote:
> The clock enable/disable codes for alarm have removed from
What do you mean in this paragraph? The clock code was removing something?
> 'commit 24e1455493da ("drivers/rtc/rtc-s3c.c: delete duplicate clock
Remove the 'apostrophe.
> control")' and the clocks keep disabling even if alarm is set, so alarm
> interrupt can't happen.
...and the clocks are disabled even...
>
> The s3c_rtc_setaie function can be called several times with that
> enabled argument has same value,
...several times with 'enabled' argument having same value
> so it needs to check whether clocks is
> enabled or not.
s/is/are/
>
> Signed-off-by: Joonyoung Shim
Please add Cc-stable and fixes tag. To backport the patch probably
you'll have to remove the dependency on previous patches.
> ---
> drivers/rtc/rtc-s3c.c | 24 ++--
> 1 file changed, 18 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index abe2a6d..fce078c 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -39,6 +39,7 @@ struct s3c_rtc {
> void __iomem *base;
> struct clk *rtc_clk;
> struct clk *rtc_src_clk;
> + bool clk_enabled;
>
> struct s3c_rtc_data *data;
>
> @@ -71,9 +72,12 @@ static void s3c_rtc_enable_clk(struct s3c_rtc *info)
> unsigned long irq_flags;
>
> spin_lock_irqsave(>alarm_clk_lock, irq_flags);
> - clk_enable(info->rtc_clk);
> - if (info->data->needs_src_clk)
> - clk_enable(info->rtc_src_clk);
> + if (!info->clk_enabled) {
> + clk_enable(info->rtc_clk);
> + if (info->data->needs_src_clk)
> + clk_enable(info->rtc_src_clk);
> + info->clk_enabled = true;
> + }
> spin_unlock_irqrestore(>alarm_clk_lock, irq_flags);
> }
>
> @@ -82,9 +86,12 @@ static void s3c_rtc_disable_clk(struct s3c_rtc *info)
> unsigned long irq_flags;
>
> spin_lock_irqsave(>alarm_clk_lock, irq_flags);
> - if (info->data->needs_src_clk)
> - clk_disable(info->rtc_src_clk);
> - clk_disable(info->rtc_clk);
> + if (info->clk_enabled) {
> + if (info->data->needs_src_clk)
> + clk_disable(info->rtc_src_clk);
> + clk_disable(info->rtc_clk);
> + info->clk_enabled = false;
> + }
> spin_unlock_irqrestore(>alarm_clk_lock, irq_flags);
> }
>
> @@ -128,6 +135,11 @@ static int s3c_rtc_setaie(struct device *dev, unsigned
> int enabled)
>
> s3c_rtc_disable_clk(info);
>
> + if (enabled)
> + s3c_rtc_enable_clk(info);
> + else
> + s3c_rtc_disable_clk(info);
> +
> return 0;
> }
During probe the clk_enabled is false, so the clock won't be disabled at
the end of probe with s3c_rtc_disable_clk(). Maybe previous patch
interferes here so it would work after applying all 4 patches but not
when backporting. The patch in current form looks non-backportable.
Best regards,
KRzysztof
--
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 v5 01/11] block: make generic_make_request handle arbitrarily sized bios
> "Ming" == Ming Lin writes: Ming> Do you still agree we cap discard to 2G as an interim solution? I can live with the 2G cap for 4.3 but would like to see it fixed properly in 4.4. -- Martin K. Petersen Oracle Linux Engineering -- 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/
[regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
Hi guys, I wonder how easily the include/uapi/* is being changed these days. The patch: http://lkml.kernel.org/r/405594361340a2ec32f8e2b115c142df0e180d8e.1426193719.git.l...@kernel.org breaks dosemu (and perhaps everyone else who used to restore the segregs by hands). And the fix involves both autoconf magic and run-time magic, so it is not even trivial. I realize this patch may be good to have in general, but breaking userspace without a single warning is a bit discouraging. Seems like the old "we don't break userspace" rule have gone. -- 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 net-next 2/2] hv_netvsc: Implement set_channels ethtool op
This enables the use of ethtool --set-channels devname combined N to
change the number of vRSS queues. Separate rx, tx, and other parameters
are not supported. The maximum is rsscap.num_recv_que. It passes the
given value to rndis_filter_device_add through the device_info->num_chn
field.
If the procedure fails, it attempts to recover to the prior state. If
the recovery fails, it logs an error and aborts.
Current num_chn is saved and restored when changing the MTU.
Signed-off-by: Andrew Schwartzmeyer
---
drivers/net/hyperv/netvsc_drv.c | 97 +
1 file changed, 97 insertions(+)
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 21845202a52d..f3b9d3eb753b 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -770,6 +770,101 @@ static void netvsc_get_channels(struct net_device *net,
}
}
+static int netvsc_set_channels(struct net_device *net,
+ struct ethtool_channels *channels)
+{
+ struct net_device_context *net_device_ctx = netdev_priv(net);
+ struct hv_device *dev = net_device_ctx->device_ctx;
+ struct netvsc_device *nvdev = hv_get_drvdata(dev);
+ struct netvsc_device_info device_info;
+ const u32 num_chn = nvdev->num_chn;
+ const u32 max_chn = min_t(u32, nvdev->max_chn, num_online_cpus());
+ int ret = 0;
+ bool recovering = false;
+
+ if (!nvdev || nvdev->destroy)
+ return -ENODEV;
+
+ if (nvdev->nvsp_version < NVSP_PROTOCOL_VERSION_5) {
+ pr_info("vRSS unsupported before NVSP Version 5\n");
+ return -EINVAL;
+ }
+
+ /* We do not support rx, tx, or other */
+ if (!channels ||
+ channels->rx_count ||
+ channels->tx_count ||
+ channels->other_count ||
+ (channels->combined_count < 1))
+ return -EINVAL;
+
+ if (channels->combined_count > max_chn) {
+ pr_info("combined channels too high, using %d\n", max_chn);
+ channels->combined_count = max_chn;
+ }
+
+ ret = netvsc_close(net);
+ if (ret)
+ goto out;
+
+ do_set:
+ nvdev->start_remove = true;
+ rndis_filter_device_remove(dev);
+
+ nvdev->num_chn = channels->combined_count;
+
+ net_device_ctx->device_ctx = dev;
+ hv_set_drvdata(dev, net);
+
+ memset(_info, 0, sizeof(device_info));
+ device_info.num_chn = nvdev->num_chn; /* passed to RNDIS */
+ device_info.ring_size = ring_size;
+ device_info.max_num_vrss_chns = max_num_vrss_chns;
+
+ ret = rndis_filter_device_add(dev, _info);
+ if (ret) {
+ if (recovering) {
+ netdev_err(net, "unable to add netvsc device (ret
%d)\n", ret);
+ return ret;
+ }
+ goto recover;
+ }
+
+ nvdev = hv_get_drvdata(dev);
+
+ ret = netif_set_real_num_tx_queues(net, nvdev->num_chn);
+ if (ret) {
+ if (recovering) {
+ netdev_err(net, "could not set tx queue count (ret
%d)\n", ret);
+ return ret;
+ }
+ goto recover;
+ }
+
+ ret = netif_set_real_num_rx_queues(net, nvdev->num_chn);
+ if (ret) {
+ if (recovering) {
+ netdev_err(net, "could not set rx queue count (ret
%d)\n", ret);
+ return ret;
+ }
+ goto recover;
+ }
+
+ out:
+ netvsc_open(net);
+
+ return ret;
+
+ recover:
+ /* If the above failed, we attempt to recover through the same
+* process but with the original number of channels.
+*/
+ netdev_err(net, "could not set channels, recovering\n");
+ recovering = true;
+ channels->combined_count = num_chn;
+ goto do_set;
+}
+
static int netvsc_change_mtu(struct net_device *ndev, int mtu)
{
struct net_device_context *ndevctx = netdev_priv(ndev);
@@ -802,6 +897,7 @@ static int netvsc_change_mtu(struct net_device *ndev, int
mtu)
memset(_info, 0, sizeof(device_info));
device_info.ring_size = ring_size;
+ device_info.num_chn = nvdev->num_chn;
device_info.max_num_vrss_chns = max_num_vrss_chns;
rndis_filter_device_add(hdev, _info);
@@ -891,6 +987,7 @@ static const struct ethtool_ops ethtool_ops = {
.get_drvinfo= netvsc_get_drvinfo,
.get_link = ethtool_op_get_link,
.get_channels = netvsc_get_channels,
+ .set_channels = netvsc_set_channels,
};
static const struct net_device_ops device_ops = {
--
2.4.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
[PATCH net-next 1/2] hv_netvsc: Set vRSS with num_chn in RNDIS filter
Uses device_info->num_chn to pass user provided number of vRSS
queues (from ethtool --set-channels) to rndis_filter_device_add. If
nonzero and less than the maximum, set net_device->num_chn to the given
value; else default to prior algorithm.
Always initialize struct device_info to 0, otherwise not all its fields
are guaranteed to be 0, which is necessary when checking if num_chn has
been purposefully set.
Signed-off-by: Andrew Schwartzmeyer
---
drivers/net/hyperv/hyperv_net.h | 1 +
drivers/net/hyperv/netvsc_drv.c | 3 +++
drivers/net/hyperv/rndis_filter.c | 7 ++-
3 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 5ce7020ca530..5fa98f599b3d 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -162,6 +162,7 @@ struct netvsc_device_info {
bool link_state;/* 0 - link up, 1 - link down */
int ring_size;
u32 max_num_vrss_chns;
+ u32 num_chn;
};
enum rndis_device_state {
diff --git a/drivers/net/hyperv/netvsc_drv.c b/drivers/net/hyperv/netvsc_drv.c
index 7b36d5fecc1f..21845202a52d 100644
--- a/drivers/net/hyperv/netvsc_drv.c
+++ b/drivers/net/hyperv/netvsc_drv.c
@@ -799,6 +799,8 @@ static int netvsc_change_mtu(struct net_device *ndev, int
mtu)
ndevctx->device_ctx = hdev;
hv_set_drvdata(hdev, ndev);
+
+ memset(_info, 0, sizeof(device_info));
device_info.ring_size = ring_size;
device_info.max_num_vrss_chns = max_num_vrss_chns;
rndis_filter_device_add(hdev, _info);
@@ -1022,6 +1024,7 @@ static int netvsc_probe(struct hv_device *dev,
net->needed_headroom = max_needed_headroom;
/* Notify the netvsc driver of the new device */
+ memset(_info, 0, sizeof(device_info));
device_info.ring_size = ring_size;
device_info.max_num_vrss_chns = max_num_vrss_chns;
ret = rndis_filter_device_add(dev, _info);
diff --git a/drivers/net/hyperv/rndis_filter.c
b/drivers/net/hyperv/rndis_filter.c
index 9b8263db49cc..5931a799aa17 100644
--- a/drivers/net/hyperv/rndis_filter.c
+++ b/drivers/net/hyperv/rndis_filter.c
@@ -1125,7 +1125,12 @@ int rndis_filter_device_add(struct hv_device *dev,
*/
node_cpu_mask = cpumask_of_node(cpu_to_node(dev->channel->target_cpu));
num_possible_rss_qs = cpumask_weight(node_cpu_mask);
- net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
+
+ /* We will use the given number of channels if available. */
+ if (device_info->num_chn && device_info->num_chn < net_device->max_chn)
+ net_device->num_chn = device_info->num_chn;
+ else
+ net_device->num_chn = min(num_possible_rss_qs, num_rss_qs);
num_rss_qs = net_device->num_chn - 1;
net_device->num_sc_offered = num_rss_qs;
--
2.4.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/
Re: [PATCH 3/4] rtc: s3c: use unified functions for enable/disable of clk
On 11.08.2015 20:28, Joonyoung Shim wrote:
> The driver uses clk_prepare_enable()/clk_disable_unprepare() only in
> probe only, elsewhere, use the unified functions for enable/disable of
> clk, e.g. s3c_rtc_enable_clk() / s3c_rtc_disable_clk(), so it's better
> to use them for consistency of code.
>
> Signed-off-by: Joonyoung Shim
> ---
> drivers/rtc/rtc-s3c.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
First of all - the code is larger (9 insertions, 5 deletion) so I have
doubts if this is better.
Second - this is not equivalent change. The s3c_rtc_enable_clk/disable
calls grab spin lock which is not necessary in probe.
Best regards,
Krzysztof
>
> diff --git a/drivers/rtc/rtc-s3c.c b/drivers/rtc/rtc-s3c.c
> index 44b2921..abe2a6d 100644
> --- a/drivers/rtc/rtc-s3c.c
> +++ b/drivers/rtc/rtc-s3c.c
> @@ -476,19 +476,21 @@ static int s3c_rtc_probe(struct platform_device *pdev)
> dev_err(>dev, "failed to find rtc clock\n");
> return PTR_ERR(info->rtc_clk);
> }
> - clk_prepare_enable(info->rtc_clk);
> + clk_prepare(info->rtc_clk);
>
> if (info->data->needs_src_clk) {
> info->rtc_src_clk = devm_clk_get(>dev, "rtc_src");
> if (IS_ERR(info->rtc_src_clk)) {
> dev_err(>dev,
> "failed to find rtc source clock\n");
> - clk_disable_unprepare(info->rtc_clk);
> + clk_unprepare(info->rtc_clk);
> return PTR_ERR(info->rtc_src_clk);
> }
> - clk_prepare_enable(info->rtc_src_clk);
> + clk_prepare(info->rtc_src_clk);
> }
>
> + s3c_rtc_enable_clk(info);
> +
> /* check to see if everything is setup correctly */
> if (info->data->enable)
> info->data->enable(info);
> @@ -548,9 +550,11 @@ static int s3c_rtc_probe(struct platform_device *pdev)
> if (info->data->disable)
> info->data->disable(info);
>
> + s3c_rtc_disable_clk(info);
> +
> if (info->data->needs_src_clk)
> - clk_disable_unprepare(info->rtc_src_clk);
> - clk_disable_unprepare(info->rtc_clk);
> + clk_unprepare(info->rtc_src_clk);
> + clk_unprepare(info->rtc_clk);
>
> 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 1/4] rtc: s3c: add missing clk control
On 11.08.2015 20:28, Joonyoung Shim wrote: > It's missed to call clk_unprepare() about info->rtc_src_clk in > s3c_rtc_remove and to call clk_disable_unprepare about info->rtc_clk in > error routine of s3c_rtc_probe. > > Signed-off-by: Joonyoung Shim > --- > drivers/rtc/rtc-s3c.c | 3 +++ > 1 file changed, 3 insertions(+) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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/4] rtc: s3c: remove unnecessary NULL assignment
On 11.08.2015 20:28, Joonyoung Shim wrote: > It's unnecessary the code that assigns info->rtc_clk to NULL in > s3c_rtc_remove. > > Signed-off-by: Joonyoung Shim > --- > drivers/rtc/rtc-s3c.c | 1 - > 1 file changed, 1 deletion(-) Reviewed-by: Krzysztof Kozlowski Best regards, Krzysztof -- 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 3/3] Documentation/filesystems/proc.txt: document hugetlb RSS
On Mon, Aug 10, 2015 at 05:44:54PM -0700, David Rientjes wrote:
> On Mon, 10 Aug 2015, Naoya Horiguchi wrote:
>
> > diff --git v4.2-rc4.orig/Documentation/filesystems/proc.txt
> > v4.2-rc4/Documentation/filesystems/proc.txt
> > index 6f7fafde0884..cb8565e150ed 100644
> > --- v4.2-rc4.orig/Documentation/filesystems/proc.txt
> > +++ v4.2-rc4/Documentation/filesystems/proc.txt
> > @@ -168,6 +168,7 @@ For example, to get the status information of a
> > process, all you have to do is
> >VmLck: 0 kB
> >VmHWM: 476 kB
> >VmRSS: 476 kB
> > + VmHugetlbRSS: 0 kB
> >VmData: 156 kB
> >VmStk:88 kB
> >VmExe:68 kB
> > @@ -230,6 +231,7 @@ Table 1-2: Contents of the status files (as of 4.1)
> > VmLck locked memory size
> > VmHWM peak resident set size ("high water mark")
> > VmRSS size of memory portions
> > + VmHugetlbRSSsize of hugetlb memory portions
> > VmData size of data, stack, and text segments
> > VmStk size of data, stack, and text segments
> > VmExe size of text segment
> > @@ -440,8 +442,12 @@ indicates the amount of memory currently marked as
> > referenced or accessed.
> > "Anonymous" shows the amount of memory that does not belong to any file.
> > Even
> > a mapping associated with a file may contain anonymous pages: when
> > MAP_PRIVATE
> > and a page is modified, the file page is replaced by a private anonymous
> > copy.
> > -"Swap" shows how much would-be-anonymous memory is also used, but out on
> > -swap.
> > +"Swap" shows how much would-be-anonymous memory is also used, but out on
> > swap.
> > +Since 4.3, "RSS" contains the amount of mappings for hugetlb pages.
> > Although
> > +RSS of hugetlb mappings is maintained separately from normal mappings
> > +(displayed in "VmHugetlbRSS" field of /proc/PID/status,) /proc/PID/smaps
> > shows
> > +both mappings in "RSS" field. Userspace applications clearly distinguish
> > the
> > +type of mapping with 'ht' flag in "VmFlags" field.
> >
> > "VmFlags" field deserves a separate description. This member represents
> > the kernel
> > flags associated with the particular virtual memory area in two letter
> > encoded
>
> My objection to adding hugetlb memory to the RSS field of /proc/pid/smaps
> still stands and can be addressed in the thread of the first patch. Since
> this includes wording that describes that change, then the objection would
> also cover that.
OK, I'll update this in accordance with the change on the first patch.
> With regard to adding VmHugetlbRSS, I think the change is fine, and I
> appreciate that you call it VmHugetlbRSS and not VmHugeRSS since that
> would be confused with thp.
I plan to rename the field, then the new name will/should be unconfusing
between thp and hugetlb.
> My only concern regarding VmHugetlbRSS would be extendability and whether
> we will eventually, or even today, want to differentiate between various
> hugetlb page sizes. For example, if 1GB hugetlb pages on x86 are a
> precious resource, then how do I determine which process has mapped it
> rather than 512 2MB hugetlb pages?
"KernelPageSize" field in /proc/PID/smaps is aware of hugetlb page sizes,
so I expected userspace to detect the size itself. But /proc/PID/status shows
only proccess-wide info, so userspace applications must read both of these
files to know the usage per hugepage size, which might be inconvenient.
One idea is to show the new field like "VmHugetlbRSS: 2x512kB 1x1GB" for
both of /proc/PID/{status,smaps}, which passes the full hugetlb info in a
single line so easier to parse and process. Or some other fields shows in
"kB", so "VmHugetlbRSS: 1052672 kB (2x512kB 1x1GB)" is possible for human
readability.
Thank you very much for the feedback, I'll repost soon, but any additional
comment is appreciated.
Naoya
Re: [PATCHv2] clk: socfpga: Add a second parent option for the dbg_base_clk
On 07/24, dingu...@opensource.altera.com wrote: > From: Dinh Nguyen > > The debug base clock can be bypassed from the main PLL to the OSC1 clock. > The bypass register is the staysoc1(0x10) register that is in the clock > manager. > > This patch adds the option to get the correct parent for the debug base > clock. > > Signed-off-by: Dinh Nguyen > --- Applied to clk-next -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- 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: linux-next: manual merge of the arm-soc tree with the arm tree
On Wed, 12 Aug 2015, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in:
>
> arch/arm/kernel/psci.c
>
> between commit:
>
> be120397e770 ("ARM: migrate to common PSCI client code")
>
> from the arm tree and commit:
>
> 19c233b79d1a ("ARM: appropriate __init annotation for const data")
>
> from the arm-soc tree.
>
> I fixed it up (the former removed the file, so I did that, then added
> the following patch) and can carry the fix as necessary (no action
> is required).
The fix is correct, thanks.
>
> From: Stephen Rothwell
> Date: Wed, 12 Aug 2015 09:39:15 +1000
> Subject: [PATCH] ARM: fix for PSCI code movement
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/firmware/psci.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
> index a6956007dd38..42700f09a8c5 100644
> --- a/drivers/firmware/psci.c
> +++ b/drivers/firmware/psci.c
> @@ -337,7 +337,7 @@ out_put_node:
> return err;
> }
>
> -static const struct of_device_id psci_of_match[] __initconst = {
> +static const struct of_device_id const psci_of_match[] __initconst = {
> { .compatible = "arm,psci", .data = psci_0_1_init},
> { .compatible = "arm,psci-0.2", .data = psci_0_2_init},
> {},
> --
> 2.5.0
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
>
--
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 3/5] mm/hwpoison: introduce put_hwpoison_page to put refcount for memory error handling
On 8/12/15 7:24 AM, Andrew Morton wrote:
On Mon, 10 Aug 2015 19:28:21 +0800 Wanpeng Li wrote:
Introduce put_hwpoison_page to put refcount for memory
error handling.
...
--- a/mm/memory-failure.c
+++ b/mm/memory-failure.c
@@ -922,6 +922,27 @@ int get_hwpoison_page(struct page *page)
}
EXPORT_SYMBOL_GPL(get_hwpoison_page);
+/**
+ * put_hwpoison_page() - Put refcount for memory error handling:
+ * @page: raw error page (hit by memory error)
+ */
+void put_hwpoison_page(struct page *page)
+{
+ struct page *head = compound_head(page);
+
+ if (PageHuge(head)) {
+ put_page(head);
+ return;
+ }
+
+ if (PageTransHuge(head))
+ if (page != head)
+ put_page(head);
+
+ put_page(page);
+}
+EXPORT_SYMBOL_GPL(put_hwpoison_page);
I don't believe the export is needed?
Indeed, thanks for your fix. :-)
Regards,
Wanpeng Li
--
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/2] smaps: fill missing fields for vma(VM_HUGETLB)
On Tue, 11 Aug 2015, Naoya Horiguchi wrote: > > This memory was not included in rss originally because memory in the > > hugetlb persistent pool is always resident. Unmapping the memory does not > > free memory. For this reason, hugetlb memory has always been treated as > > its own type of memory. > > Right, so it might be better not to use the word "RSS" for hugetlb, maybe > something like "HugetlbPages:" seems better to me. > When the pagesize is also specified, as it is in smaps, I think this would be the best option. Note that we can't distinguish between variable hugetlb sizes with VmFlags alone. -- 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/
linux-next: manual merge of the arm-soc tree with the arm tree
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in:
arch/arm/kernel/psci.c
between commit:
be120397e770 ("ARM: migrate to common PSCI client code")
from the arm tree and commit:
19c233b79d1a ("ARM: appropriate __init annotation for const data")
from the arm-soc tree.
I fixed it up (the former removed the file, so I did that, then added
the following patch) and can carry the fix as necessary (no action
is required).
From: Stephen Rothwell
Date: Wed, 12 Aug 2015 09:39:15 +1000
Subject: [PATCH] ARM: fix for PSCI code movement
Signed-off-by: Stephen Rothwell
---
drivers/firmware/psci.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/firmware/psci.c b/drivers/firmware/psci.c
index a6956007dd38..42700f09a8c5 100644
--- a/drivers/firmware/psci.c
+++ b/drivers/firmware/psci.c
@@ -337,7 +337,7 @@ out_put_node:
return err;
}
-static const struct of_device_id psci_of_match[] __initconst = {
+static const struct of_device_id const psci_of_match[] __initconst = {
{ .compatible = "arm,psci", .data = psci_0_1_init},
{ .compatible = "arm,psci-0.2", .data = psci_0_2_init},
{},
--
2.5.0
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
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] f2fs: avoid a build warning
If F2FS_CHECK_FS is turned off, we can get a build warning for unused variable.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/segment.h | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/segment.h b/fs/f2fs/segment.h
index d0bd952..b6e4ed1 100644
--- a/fs/f2fs/segment.h
+++ b/fs/f2fs/segment.h
@@ -581,15 +581,11 @@ static inline void verify_block_addr(struct f2fs_sb_info
*sbi, block_t blk_addr)
static inline void check_block_count(struct f2fs_sb_info *sbi,
int segno, struct f2fs_sit_entry *raw_sit)
{
+#ifdef CONFIG_F2FS_CHECK_FS
bool is_valid = test_bit_le(0, raw_sit->valid_map) ? true : false;
int valid_blocks = 0;
int cur_pos = 0, next_pos;
- /* check segment usage, and check boundary of a given segment number */
- f2fs_bug_on(sbi, GET_SIT_VBLOCKS(raw_sit) > sbi->blocks_per_seg
- || segno > TOTAL_SEGS(sbi) - 1);
-
-#ifdef CONFIG_F2FS_CHECK_FS
/* check bitmap with valid block count */
do {
if (is_valid) {
@@ -606,6 +602,9 @@ static inline void check_block_count(struct f2fs_sb_info
*sbi,
} while (cur_pos < sbi->blocks_per_seg);
BUG_ON(GET_SIT_VBLOCKS(raw_sit) != valid_blocks);
#endif
+ /* check segment usage, and check boundary of a given segment number */
+ f2fs_bug_on(sbi, GET_SIT_VBLOCKS(raw_sit) > sbi->blocks_per_seg
+ || segno > TOTAL_SEGS(sbi) - 1);
}
static inline pgoff_t current_sit_addr(struct f2fs_sb_info *sbi,
--
2.1.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/
