[PATCH v4 05/13] of: Document timings subnode of nvidia,tegra-mc
The MC driver needs some timing-specific information to program the EMEM during
a rate change of the EMC clock.
Signed-off-by: Tomeu Vizoso
---
v4: * Add more information about nvidia,emem-configuration
* Remove mandatory naming of the timings subnode
* Remove constraint on the unit-address of the timings and timing
subnodes
---
.../memory-controllers/nvidia,tegra-mc.txt | 84 +-
1 file changed, 82 insertions(+), 2 deletions(-)
diff --git
a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra-mc.txt
b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra-mc.txt
index f3db93c..3338a28 100644
--- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra-mc.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra-mc.txt
@@ -1,6 +1,9 @@
NVIDIA Tegra Memory Controller device tree bindings
===
+memory-controller node
+--
+
Required properties:
- compatible: Should be "nvidia,tegra-mc"
- reg: Physical base address and length of the controller's registers.
@@ -15,9 +18,49 @@ Required properties:
This device implements an IOMMU that complies with the generic IOMMU binding.
See ../iommu/iommu.txt for details.
-Example:
-
+emc-timings subnode
+---
+
+The node should contain a "emc-timings" subnode for each supported RAM type
(see field RAM_CODE in
+register PMC_STRAPPING_OPT_A).
+
+Required properties for "emc-timings" nodes :
+- nvidia,ram-code : Should contain the value of RAM_CODE this timing set is
used for.
+
+timing subnode
+--
+
+Each "emc-timings" node should contain a subnode for every supported EMC clock
rate.
+
+Required properties for timing nodes :
+- clock-frequency : Should contain the memory clock rate in Hz.
+- nvidia,emem-configuration : Values to be written to the EMEM register block.
For the Tegra124 SoC
+(see section "15.6.1 MC Registers" in the TRM), these are the registers whose
values need to be
+specified, according to the board documentation:
+
+ MC_EMEM_ARB_CFG
+ MC_EMEM_ARB_OUTSTANDING_REQ
+ MC_EMEM_ARB_TIMING_RCD
+ MC_EMEM_ARB_TIMING_RP
+ MC_EMEM_ARB_TIMING_RC
+ MC_EMEM_ARB_TIMING_RAS
+ MC_EMEM_ARB_TIMING_FAW
+ MC_EMEM_ARB_TIMING_RRD
+ MC_EMEM_ARB_TIMING_RAP2PRE
+ MC_EMEM_ARB_TIMING_WAP2PRE
+ MC_EMEM_ARB_TIMING_R2R
+ MC_EMEM_ARB_TIMING_W2W
+ MC_EMEM_ARB_TIMING_R2W
+ MC_EMEM_ARB_TIMING_W2R
+ MC_EMEM_ARB_DA_TURNS
+ MC_EMEM_ARB_DA_COVERS
+ MC_EMEM_ARB_MISC0
+ MC_EMEM_ARB_MISC1
+ MC_EMEM_ARB_RING1_THROTTLE
+Example SoC include file:
+
+/ {
mc: memory-controller@0,70019000 {
compatible = "nvidia,tegra124-mc";
reg = <0x0 0x70019000 0x0 0x1000>;
@@ -34,3 +77,40 @@ Example:
...
iommus = <&mc TEGRA_SWGROUP_SDMMC1A>;
};
+};
+
+Example board file:
+
+/ {
+ memory-controller@0,70019000 {
+ emc-timings-3 {
+ nvidia,ram-code = <3>;
+
+ timing-1275 {
+ clock-frequency = <1275>;
+
+ nvidia,emem-configuration = <
+ 0x40040001 /* MC_EMEM_ARB_CFG */
+ 0x800a /*
MC_EMEM_ARB_OUTSTANDING_REQ */
+ 0x0001 /* MC_EMEM_ARB_TIMING_RCD */
+ 0x0001 /* MC_EMEM_ARB_TIMING_RP */
+ 0x0002 /* MC_EMEM_ARB_TIMING_RC */
+ 0x /* MC_EMEM_ARB_TIMING_RAS */
+ 0x0002 /* MC_EMEM_ARB_TIMING_FAW */
+ 0x0001 /* MC_EMEM_ARB_TIMING_RRD */
+ 0x0002 /*
MC_EMEM_ARB_TIMING_RAP2PRE */
+ 0x0008 /*
MC_EMEM_ARB_TIMING_WAP2PRE */
+ 0x0003 /* MC_EMEM_ARB_TIMING_R2R */
+ 0x0002 /* MC_EMEM_ARB_TIMING_W2W */
+ 0x0003 /* MC_EMEM_ARB_TIMING_R2W */
+ 0x0006 /* MC_EMEM_ARB_TIMING_W2R */
+ 0x06030203 /* MC_EMEM_ARB_DA_TURNS */
+ 0x000a0402 /* MC_EMEM_ARB_DA_COVERS */
+ 0x77e30303 /* MC_EMEM_ARB_MISC0 */
+ 0x7f03 /* MC_EMEM_ARB_MISC1 */
+ 0x001f /*
MC_EMEM_ARB_RING1_THROTTLE */
+ >;
+ };
+ };
+ };
+};
--
1.9.3
--
To unsubscribe from this list: send the line "u
[PATCH v4 04/13] of: document new emc-timings subnode in nvidia,tegra124-car
The EMC clock needs some extra information for changing its rate.
Signed-off-by: Tomeu Vizoso
---
v4: * Remove comma from unit-address of CAR node in the example
* Simplify reg property value in the example
---
.../bindings/clock/nvidia,tegra124-car.txt | 44 +-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
index ded5d62..cab5cd7 100644
--- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
+++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.txt
@@ -19,10 +19,33 @@ Required properties :
In clock consumers, this cell represents the bit number in the CAR's
array of CLK_RST_CONTROLLER_RST_DEVICES_* registers.
+The node should contain a "emc-timings" subnode for each supported RAM type
(see
+field RAM_CODE in register PMC_STRAPPING_OPT_A), with its unit address being
its
+RAM_CODE.
+
+Required properties for "emc-timings" nodes :
+- nvidia,ram-code : Should contain the value of RAM_CODE this timing set
+ is used for.
+
+Each "emc-timings" node should contain a "timing" subnode for every supported
+EMC clock rate. The "timing" subnodes should have the clock rate in Hz as their
+unit address.
+
+Required properties for "timing" nodes :
+- clock-frequency : Should contain the memory clock rate to which this timing
+relates.
+- nvidia,parent-clock-frequency : Should contain the rate at which the current
+parent of the EMC clock should be running at this timing.
+- clocks : Must contain an entry for each entry in clock-names.
+ See ../clocks/clock-bindings.txt for details.
+- clock-names : Must include the following entries:
+ - emc-parent : the clock that should be the parent of the EMC clock at this
+timing.
+
Example SoC include file:
/ {
- tegra_car: clock {
+ tegra_car: clock@60006000 {
compatible = "nvidia,tegra124-car";
reg = <0x60006000 0x1000>;
#clock-cells = <1>;
@@ -60,4 +83,23 @@ Example board file:
&tegra_car {
clocks = <&clk_32k> <&osc>;
};
+
+ clock@60006000 {
+ emc-timings@3 {
+ nvidia,ram-code = <3>;
+
+ timing@1275 {
+ clock-frequency = <1275>;
+ nvidia,parent-clock-frequency = <40800>;
+ clocks = <&tegra_car TEGRA124_CLK_PLL_P>;
+ clock-names = "emc-parent";
+ };
+ timing@2040 {
+ clock-frequency = <2040>;
+ nvidia,parent-clock-frequency = <40800>;
+ clocks = <&tegra_car TEGRA124_CLK_PLL_P>;
+ clock-names = "emc-parent";
+ };
+ };
+ };
};
--
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/
[PATCH v4 03/13] soc/tegra: Add ram code reader helper
From: Mikko Perttunen
Needed for the EMC and MC drivers to know what timings from the DT to use.
Signed-off-by: Mikko Perttunen
Signed-off-by: Tomeu Vizoso
---
v4: Replace magic number with PMC_STRAPPING_OPT_A_RAM_CODE_SHIFT
---
drivers/soc/tegra/fuse/tegra-apbmisc.c | 19 +++
include/soc/tegra/fuse.h | 1 +
2 files changed, 20 insertions(+)
diff --git a/drivers/soc/tegra/fuse/tegra-apbmisc.c
b/drivers/soc/tegra/fuse/tegra-apbmisc.c
index 3bf5aba..dc96a62 100644
--- a/drivers/soc/tegra/fuse/tegra-apbmisc.c
+++ b/drivers/soc/tegra/fuse/tegra-apbmisc.c
@@ -28,8 +28,13 @@
#define APBMISC_SIZE 0x64
#define FUSE_SKU_INFO 0x10
+#define PMC_STRAPPING_OPT_A_RAM_CODE_SHIFT 4
+#define PMC_STRAPPING_OPT_A_RAM_CODE_MASK_LONG (0xf <<
PMC_STRAPPING_OPT_A_RAM_CODE_SHIFT)
+#define PMC_STRAPPING_OPT_A_RAM_CODE_MASK_SHORT(0x3 <<
PMC_STRAPPING_OPT_A_RAM_CODE_SHIFT)
+
static void __iomem *apbmisc_base;
static void __iomem *strapping_base;
+static bool long_ram_code;
u32 tegra_read_chipid(void)
{
@@ -54,6 +59,18 @@ u32 tegra_read_straps(void)
return 0;
}
+u32 tegra_read_ram_code(void)
+{
+ u32 straps = tegra_read_straps();
+
+ if (long_ram_code)
+ straps &= PMC_STRAPPING_OPT_A_RAM_CODE_MASK_LONG;
+ else
+ straps &= PMC_STRAPPING_OPT_A_RAM_CODE_MASK_SHORT;
+
+ return straps >> PMC_STRAPPING_OPT_A_RAM_CODE_SHIFT;
+}
+
static const struct of_device_id apbmisc_match[] __initconst = {
{ .compatible = "nvidia,tegra20-apbmisc", },
{},
@@ -112,4 +129,6 @@ void __init tegra_init_apbmisc(void)
strapping_base = of_iomap(np, 1);
if (!strapping_base)
pr_err("ioremap tegra strapping_base failed\n");
+
+ long_ram_code = of_property_read_bool(np, "nvidia,long-ram-code");
}
diff --git a/include/soc/tegra/fuse.h b/include/soc/tegra/fuse.h
index 8e12494..4ad6fd9 100644
--- a/include/soc/tegra/fuse.h
+++ b/include/soc/tegra/fuse.h
@@ -55,6 +55,7 @@ struct tegra_sku_info {
};
u32 tegra_read_straps(void);
+u32 tegra_read_ram_code(void);
u32 tegra_read_chipid(void);
int tegra_fuse_readl(unsigned long offset, u32 *value);
--
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/
[PATCH v4 01/13] clk: tegra124: Remove old emc clock
From: Mikko Perttunen
This clock has never been able to do anything.
Signed-off-by: Mikko Perttunen
Signed-off-by: Tomeu Vizoso
---
v2: * Don't remove emc_mux as it's being used by the MC clock now
---
drivers/clk/tegra/clk-tegra124.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/clk/tegra/clk-tegra124.c b/drivers/clk/tegra/clk-tegra124.c
index f5f9bac..07ec882 100644
--- a/drivers/clk/tegra/clk-tegra124.c
+++ b/drivers/clk/tegra/clk-tegra124.c
@@ -790,7 +790,6 @@ static struct tegra_clk tegra124_clks[tegra_clk_max]
__initdata = {
[tegra_clk_i2c2] = { .dt_id = TEGRA124_CLK_I2C2, .present = true },
[tegra_clk_uartc] = { .dt_id = TEGRA124_CLK_UARTC, .present = true },
[tegra_clk_mipi_cal] = { .dt_id = TEGRA124_CLK_MIPI_CAL, .present =
true },
- [tegra_clk_emc] = { .dt_id = TEGRA124_CLK_EMC, .present = true },
[tegra_clk_usb2] = { .dt_id = TEGRA124_CLK_USB2, .present = true },
[tegra_clk_usb3] = { .dt_id = TEGRA124_CLK_USB3, .present = true },
[tegra_clk_vde_8] = { .dt_id = TEGRA124_CLK_VDE, .present = true },
--
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/
[PATCH v4 00/13] Tegra124 EMC (external memory controller) support
Hello, in this v4 you can find these changes: * Adapt to changes in the latest version of Thierry's IOMMU series * OF bindings don't specify any unit-address or naming for the timings and timing subnodes. This is in line with how the display timings are specified. * Misc improvements on error handling and reporting * Misc style fixes * Adds a bit more information on the registers that need to be specified for each timing, and points to the TRM for more details. It depends on Thierry's MC patches at [0] and a branch can be found at [1]. So far it has been tested only on a Jetson TK1. Patch 1: Removes the old EMC clock, that was unused and not functional Patch 2: Documents bindings for the new long-ram-code property Patch 3: Adds API for reading the ram code Patches 4 to 6: Document OF additions Patch 7: Adds EMC node to Tegra124 DT Patch 8: Adds timings for Jetson TK1 board Patch 9: Adds functions to the MC driver so the EMC driver can stay within its own registers Patch 10: Adds the actual EMC driver, making use of the new MC API Patch 11: Adds EMC clock driver, making use of API provided by the EMC driver Patch 12: Adds debugfs entry for getting and setting the EMC rate Patch 13: On Tegra124, have the EMC clock be the parent of the MC clock Regards, Tomeu [0] https://github.com/thierryreding/linux/commits/staging/iommu [1] http://cgit.collabora.com/git/user/tomeu/linux.git/log/?h=emc-v4 Mikko Perttunen (9): clk: tegra124: Remove old emc clock soc/tegra: Add ram code reader helper of: Add Tegra124 EMC bindings ARM: tegra: Add EMC to Tegra124 device tree ARM: tegra: Add EMC timings to Jetson TK1 device tree memory: tegra: Add API needed by the EMC driver memory: tegra: Add EMC (external memory controller) driver clk: tegra: Add EMC clock driver memory: tegra: Add debugfs entry for getting and setting the EMC rate Tomeu Vizoso (4): of: Document long-ram-code property in nvidia,tegra20-apbmisc of: document new emc-timings subnode in nvidia,tegra124-car of: Document timings subnode of nvidia,tegra-mc clk: tegra: Set the EMC clock as the parent of the MC clock .../bindings/clock/nvidia,tegra124-car.txt | 44 +- .../memory-controllers/nvidia,tegra-mc.txt | 84 +- .../bindings/memory-controllers/tegra-emc.txt | 376 +++ .../bindings/misc/nvidia,tegra20-apbmisc.txt |2 + arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi | 2412 arch/arm/boot/dts/tegra124-jetson-tk1.dts |2 + arch/arm/boot/dts/tegra124.dtsi|7 + drivers/clk/tegra/Makefile |2 +- drivers/clk/tegra/clk-emc.c| 468 drivers/clk/tegra/clk-tegra124.c | 18 +- drivers/clk/tegra/clk.h|2 + drivers/memory/tegra/Kconfig | 10 + drivers/memory/tegra/Makefile |2 + drivers/memory/tegra/mc.c | 130 ++ drivers/memory/tegra/mc.h | 12 + drivers/memory/tegra/tegra124-emc.c| 1157 ++ drivers/memory/tegra/tegra124.c| 44 + drivers/soc/tegra/fuse/tegra-apbmisc.c | 19 + include/soc/tegra/fuse.h |1 + include/soc/tegra/memory.h | 19 + 20 files changed, 4793 insertions(+), 18 deletions(-) create mode 100644 Documentation/devicetree/bindings/memory-controllers/tegra-emc.txt create mode 100644 arch/arm/boot/dts/tegra124-jetson-tk1-emc.dtsi create mode 100644 drivers/clk/tegra/clk-emc.c create mode 100644 drivers/memory/tegra/tegra124-emc.c create mode 100644 include/soc/tegra/memory.h -- 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/
[PATCH v4 02/13] of: Document long-ram-code property in nvidia,tegra20-apbmisc
Needed to properly decode the ram code register. Signed-off-by: Tomeu Vizoso --- v3: * Clarify wording as suggested by Mikko --- Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt | 2 ++ 1 file changed, 2 insertions(+) diff --git a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt index b97b8be..d034ff8 100644 --- a/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt +++ b/Documentation/devicetree/bindings/misc/nvidia,tegra20-apbmisc.txt @@ -11,3 +11,5 @@ Required properties: The second entry gives the physical address and length of the registers indicating the strapping options. +Optional properties: +- nvidia,long-ram-code: If present, the RAM code is long (4 bit). If not, short (2 bit). -- 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 1/2] perf tools: enable LBR call stack support
On Thu, Nov 06, 2014 at 09:58:05AM -0500, kan.li...@intel.com wrote:
SNIP
> };
>
> diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c
> index 2f9e680..8c23607 100644
> --- a/tools/perf/util/evsel.c
> +++ b/tools/perf/util/evsel.c
> @@ -537,13 +537,24 @@ int perf_evsel__group_desc(struct perf_evsel *evsel,
> char *buf, size_t size)
> }
>
> static void
> -perf_evsel__config_callgraph(struct perf_evsel *evsel)
> +perf_evsel__config_callgraph(struct perf_evsel *evsel,
> + struct record_opts *opts)
> {
> bool function = perf_evsel__is_function_event(evsel);
> struct perf_event_attr *attr = &evsel->attr;
>
> perf_evsel__set_sample_bit(evsel, CALLCHAIN);
>
> + if (callchain_param.record_mode == CALLCHAIN_LBR) {
> + if (!opts->branch_stack) {
> + perf_evsel__set_sample_bit(evsel, BRANCH_STACK);
> + attr->branch_sample_type = PERF_SAMPLE_BRANCH_USER |
> + PERF_SAMPLE_BRANCH_CALL_STACK;
> + attr->exclude_user = 0;
I think we shouldn't siletly change attr->exclude_user,
if it was defined, we need to display warning that
we are changing that or fail
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] perf tools: enable LBR call stack support
On Thu, Nov 06, 2014 at 09:58:05AM -0500, kan.li...@intel.com wrote:
SNIP
> (sample_type & PERF_SAMPLE_STACK_USER))
> callchain_param.record_mode = CALLCHAIN_DWARF;
> + else if (sample_type & PERF_SAMPLE_BRANCH_STACK)
> + callchain_param.record_mode = CALLCHAIN_LBR;
> else
> callchain_param.record_mode = CALLCHAIN_FP;
> }
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index 0022980..72ed39b 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -97,6 +97,14 @@ int parse_callchain_record_opt(const char *arg)
> callchain_param.dump_size = size;
> }
> #endif /* HAVE_DWARF_UNWIND_SUPPORT */
> + } else if (!strncmp(name, "lbr", sizeof("lbr"))) {
> + if (!strtok_r(NULL, ",", &saveptr)) {
> + callchain_param.record_mode = CALLCHAIN_LBR;
> + ret = 0;
> + } else
> + pr_err("callchain: No more arguments "
> + "needed for -g lbr\n");
should it be 'needed for --call-graph' option? ^^^
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v2 1/2] drivers: pci: fix pci_mmap_fits() implementation for procfs mmap
On Mon, 2014-11-10 at 16:04 -0700, Bjorn Helgaas wrote: > But I'm not sure I have this right. If the procfs offset is either > the > CPU physical address or the BAR value, then pci_resource_to_user() > should be (depending on the arch) either a no-op or use > pci_resource_to_bus(). > > But that's not how it's implemented. Maybe it *could* be? If > pci_resource_to_user() gives you something that's not a CPU physical > address and not a bus address, what *does* it give you, and why would > we > need this third kind of thing? > > FWIW, I think the discussion leading up to pci_resource_to_user() is > here: > http://lkml.iu.edu/hypermail/linux/kernel/0504.3/0467.html Oh, man... I remember that was all a giant trainwreck and some stuff just couldn't be made completely right due to broken assumptions by the proc code and users of it... but I don't remember all the details. I think /proc users don't necessarily pass a BAR value but something they try to somewhat translates themselves via the "resources" file, which ends up working ... or not, depending on various factors such as 32 vs 64 bit etc... I wonder who still uses this interface Cheers, Ben. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv5 2/5] arm: socfpga: Enable OCRAM ECC on startup.
On 11/11/14, 6:14 PM, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > This patch enables the ECC for On-Chip RAM on machine > startup. The ECC has to be enabled before data is > is stored in memory otherwise the ECC will fail on > reads. > > Signed-off-by: Thor Thayer > --- > v2: Split OCRAM ECC portion separately. Addition of iounmap() > and reorganization of gen_pool_free. Remove defconfig from patch. > > v3/4: No change > > v5: Remove ocram.h, use io.h instead of clk-provider.h > Check prop in correct place. Add ECC EN defines. > --- > arch/arm/mach-socfpga/Makefile |1 + > arch/arm/mach-socfpga/core.h|1 + > arch/arm/mach-socfpga/ocram.c | 90 > +++ > arch/arm/mach-socfpga/socfpga.c |9 > 4 files changed, 101 insertions(+) > create mode 100644 arch/arm/mach-socfpga/ocram.c > Acked-by: Dinh Nguyen -- 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] coresight: bindings for coresight drivers
On Tue, Nov 11, 2014 at 02:52:17PM -0700, Mathieu Poirier wrote: > On 11 November 2014 11:04, Rob Herring wrote: > > On Tue, Nov 11, 2014 at 11:46 AM, wrote: > >> Greg, > >> > >> Please consider this as a supplement to the coresight patchset. It should > >> have > >> been sent with the rest of the patches but I missed the original ack from > >> Rob > >> Herring. > > > > Ummm... > > > >> > >> Thanks, > >> Mathieu > >> > >> From 69cae46640b8cdc836bf7b86211d5f2adf3d0270 Mon Sep 17 00:00:00 2001 > >> From: Mathieu Poirier > >> Date: Thu, 7 Aug 2014 12:34:06 -0600 > >> Subject: [PATCH] coresight: bindings for coresight drivers > >> > >> Coresight IP blocks allow for the support of HW assisted tracing > >> on ARM SoCs. Bindings for the currently available blocks are > >> presented herein. > >> > >> Signed-off-by: Pratik Patel > >> Signed-off-by: Mathieu Poirier > > > > And you still did. > > https://patchwork.ozlabs.org/patch/388318/ How does that help me? It's not on this patch, so I can't add it. And I can't even _take_ this patch, I need something that I can apply, not have to hand-edit in order to get it to apply properly. Please resend, _with_ the ack, and then I can queue it up. 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 3.17 000/319] 3.17.3-stable review
On Tue, Nov 11, 2014 at 10:25:39PM -0800, Guenter Roeck wrote: > On 11/11/2014 05:12 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.17.3 release. > >There are 319 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Fri Nov 14 01:07:52 UTC 2014. > >Anything received after that time might be too late. > > > > Build results: > total: 133 pass: 132 fail: 1 > Failed builds: > avr32:atngw100mkii_evklcd101_defconfig > > Qemu tests: > total: 30 pass: 30 fail: 0 > > The failing build is due to a link error: > > lib/lib.a(vsprintf.o): In function `vsnprintf': > vsprintf.c:(.text+0x16dc): relocation truncated to fit: > R_AVR32_16N_PCREL against symbol `_ctype' defined in .text section in > lib/lib.a(ctype.o) > > which has been observed on and off for the last few releases. > > Details are available at http://server.roeck-us.net:8010/builder. Thanks for testing, I'll not worry about avr32 as that's an odd one... 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: [PATCHv5 1/5] arm: socfpga: Enable L2 Cache ECC on startup.
On 11/11/14, 6:14 PM, ttha...@opensource.altera.com wrote: > From: Thor Thayer > > This patch enables the ECC for L2 cache on machine > startup. The ECC has to be enabled before data is > is stored in memory otherwise the ECC will fail on > reads. > > Signed-off-by: Thor Thayer > --- > v2: Split OCRAM initialization into separate patch. > > v3/4: No change > > v5: Remove l2cache.h, use io.h instead of clk-provider.h > Make copyright header inclusive. Remove MAINTAINERS entry. > --- > arch/arm/mach-socfpga/Makefile |1 + > arch/arm/mach-socfpga/core.h |2 ++ > arch/arm/mach-socfpga/l2_cache.c | 41 > ++ > arch/arm/mach-socfpga/socfpga.c |4 +++- > 4 files changed, 47 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/mach-socfpga/l2_cache.c > Acked-by: Dinh Nguyen -- 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] n_tty: Fix read_buf race condition, increment read_head after pushing data
On Tue, Nov 11, 2014 at 2:04 PM, Måns Rullgård wrote:
> Christian Riesch writes:
[...]>> diff --git a/drivers/tty/n_tty.c b/drivers/tty/n_tty.c
>> index 2e900a9..b09f326 100644
>> --- a/drivers/tty/n_tty.c
>> +++ b/drivers/tty/n_tty.c
>> @@ -321,7 +321,9 @@ static void n_tty_check_unthrottle(struct tty_struct
>> *tty)
>>
>> static inline void put_tty_queue(unsigned char c, struct n_tty_data *ldata)
>> {
>> - *read_buf_addr(ldata, ldata->read_head++) = c;
>> + *read_buf_addr(ldata, ldata->read_head) = c;
>> + /* increment read_head _after_ placing the character in the buffer */
>> + ldata->read_head++;
>> }
>
> Is that comment really necessary?
No, I am pretty sure that removing the comment would not break the code ;-)
I just thought it would be good to have some kind of reminder here.
Otherwise someone may think: Hey, it would be a good idea to do the
increment right in the first line. And submit a patch for it.
But I am also ok with removing the comment. So if you like me to post
a v3 without the comment, I'll be happy to do that.
Christian
--
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.14 000/203] 3.14.24-stable review
On Tue, Nov 11, 2014 at 10:29:14PM -0800, Guenter Roeck wrote: > On 11/11/2014 05:14 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.14.24 release. > >There are 203 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Fri Nov 14 01:15:14 UTC 2014. > >Anything received after that time might be too late. > > > > Build results: > total: 137 pass: 134 fail: 3 > Failed builds: > powerpc:allmodconfig (binutils 2.23) > powerpc:allmodconfig (binutils 2.24) > xtensa:allmodconfig > > Qemu tests: > total: 30 pass: 30 fail: 0 > > Builds fail due to > > drivers/of/selftest.c: In function 'of_selftest': > drivers/of/selftest.c:436:2: error: implicit declaration of function > 'of_selftest_property_match_string' [-Werror=implicit-function-declaration] > of_selftest_property_match_string(); > ^ > drivers/of/selftest.c: At top level: > drivers/of/selftest.c:135:20: warning: 'of_selftest_property_string' defined > but not used [-Wunused-function] > static void __init of_selftest_property_string(void) > ^ > > as mentioned earlier. I've now fixed this one, if you want to pull the latest stable-git tree. 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 v5 1/3] mfd: max8997: use regmap to access registers
This patch modifies max8997 driver and each associated function driver,
to use regmap instead of operating directly on i2c bus. It will allow to
simplify IRQ handling using regmap-irq.
Signed-off-by: Robert Baldyga
Reviewed-by: Krzysztof Kozlowski
[For extcon part]
Acked-by: Chanwoo Choi
[For leds part]
Acked-by: Bryan Wu
[For the mfd part]
Acked-by: Lee Jones
---
drivers/extcon/extcon-max8997.c | 31
drivers/input/misc/max8997_haptic.c | 34 +
drivers/leds/leds-max8997.c | 13 ++--
drivers/mfd/Kconfig | 1 +
drivers/mfd/max8997-irq.c | 64 +++-
drivers/mfd/max8997.c | 141
drivers/power/max8997_charger.c | 33 +
drivers/regulator/max8997.c | 87 +++---
drivers/rtc/rtc-max8997.c | 56 +++---
include/linux/mfd/max8997-private.h | 17 ++---
10 files changed, 228 insertions(+), 249 deletions(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 75e501c..2aafd5b 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#defineDEV_NAME"max8997-muic"
#defineDELAY_MS_DEFAULT2 /* unit:
millisecond */
@@ -116,7 +117,7 @@ enum max8997_muic_charger_type {
struct max8997_muic_info {
struct device *dev;
- struct i2c_client *muic;
+ struct max8997_dev *max8997;
struct extcon_dev *edev;
int prev_cable_type;
int prev_chg_type;
@@ -190,10 +191,10 @@ static int max8997_muic_set_debounce_time(struct
max8997_muic_info *info,
case ADC_DEBOUNCE_TIME_10MS:
case ADC_DEBOUNCE_TIME_25MS:
case ADC_DEBOUNCE_TIME_38_62MS:
- ret = max8997_update_reg(info->muic,
+ ret = regmap_update_bits(info->max8997->regmap_muic,
MAX8997_MUIC_REG_CONTROL3,
- time << CONTROL3_ADCDBSET_SHIFT,
- CONTROL3_ADCDBSET_MASK);
+ CONTROL3_ADCDBSET_MASK,
+ time << CONTROL3_ADCDBSET_SHIFT);
if (ret) {
dev_err(info->dev, "failed to set ADC debounce time\n");
return ret;
@@ -228,8 +229,8 @@ static int max8997_muic_set_path(struct max8997_muic_info
*info,
else
ctrl1 = CONTROL1_SW_OPEN;
- ret = max8997_update_reg(info->muic,
- MAX8997_MUIC_REG_CONTROL1, ctrl1, COMP_SW_MASK);
+ ret = regmap_update_bits(info->max8997->regmap_muic,
+ MAX8997_MUIC_REG_CONTROL1, COMP_SW_MASK, ctrl1);
if (ret < 0) {
dev_err(info->dev, "failed to update MUIC register\n");
return ret;
@@ -240,9 +241,9 @@ static int max8997_muic_set_path(struct max8997_muic_info
*info,
else
ctrl2 |= CONTROL2_LOWPWR_MASK; /* LowPwr=1, CPEn=0 */
- ret = max8997_update_reg(info->muic,
- MAX8997_MUIC_REG_CONTROL2, ctrl2,
- CONTROL2_LOWPWR_MASK | CONTROL2_CPEN_MASK);
+ ret = regmap_update_bits(info->max8997->regmap_muic,
+ MAX8997_MUIC_REG_CONTROL2,
+ CONTROL2_LOWPWR_MASK | CONTROL2_CPEN_MASK, ctrl2);
if (ret < 0) {
dev_err(info->dev, "failed to update MUIC register\n");
return ret;
@@ -543,8 +544,8 @@ static void max8997_muic_irq_work(struct work_struct *work)
if (info->irq == muic_irqs[i].virq)
irq_type = muic_irqs[i].irq;
- ret = max8997_bulk_read(info->muic, MAX8997_MUIC_REG_STATUS1,
- 2, info->status);
+ ret = regmap_bulk_read(info->max8997->regmap_muic,
+ MAX8997_MUIC_REG_STATUS1, info->status, 2);
if (ret) {
dev_err(info->dev, "failed to read muic register\n");
mutex_unlock(&info->mutex);
@@ -605,8 +606,8 @@ static int max8997_muic_detect_dev(struct max8997_muic_info
*info)
mutex_lock(&info->mutex);
/* Read STATUSx register to detect accessory */
- ret = max8997_bulk_read(info->muic,
- MAX8997_MUIC_REG_STATUS1, 2, info->status);
+ ret = regmap_bulk_read(info->max8997->regmap_muic,
+ MAX8997_MUIC_REG_STATUS1, info->status, 2);
if (ret) {
dev_err(info->dev, "failed to read MUIC register\n");
mutex_unlock(&info->mutex);
@@ -665,7 +666,7 @@ static int max8997_muic_probe(struct platform_device *pdev)
return -ENOMEM;
info->dev = &pdev->dev;
- info->muic = max8997->muic;
+ info->max8997
[PATCH v5 3/3] mfd: max8997: change irq names to upper case
This patch changes naming convention of MUIC interrupts form CamelCase
to upper case. It makes names more readable and consistent with another
interrupt names in max8997 driver.
Signed-off-by: Robert Baldyga
Reviewed-by: Krzysztof Kozlowski
[For the mfd part]
Acked-by: Lee Jones
---
drivers/extcon/extcon-max8997.c | 32
include/linux/mfd/max8997-private.h | 16
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 172dbd6..834b72f 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -46,15 +46,15 @@ struct max8997_muic_irq {
};
static struct max8997_muic_irq muic_irqs[] = {
- { MAX8997_MUICIRQ_ADCError, "muic-ADCERROR" },
- { MAX8997_MUICIRQ_ADCLow, "muic-ADCLOW" },
- { MAX8997_MUICIRQ_ADC, "muic-ADC" },
- { MAX8997_MUICIRQ_VBVolt, "muic-VBVOLT" },
- { MAX8997_MUICIRQ_DBChg,"muic-DBCHG" },
- { MAX8997_MUICIRQ_DCDTmr, "muic-DCDTMR" },
- { MAX8997_MUICIRQ_ChgDetRun,"muic-CHGDETRUN" },
- { MAX8997_MUICIRQ_ChgTyp, "muic-CHGTYP" },
- { MAX8997_MUICIRQ_OVP, "muic-OVP" },
+ { MAX8997_MUICIRQ_ADCERROR, "MUIC-ADCERROR" },
+ { MAX8997_MUICIRQ_ADCLOW, "MUIC-ADCLOW" },
+ { MAX8997_MUICIRQ_ADC, "MUIC-ADC" },
+ { MAX8997_MUICIRQ_VBVOLT, "MUIC-VBVOLT" },
+ { MAX8997_MUICIRQ_DBCHG,"MUIC-DBCHG" },
+ { MAX8997_MUICIRQ_DCDTMR, "MUIC-DCDTMR" },
+ { MAX8997_MUICIRQ_CHGDETRUN,"MUIC-CHGDETRUN" },
+ { MAX8997_MUICIRQ_CHGTYP, "MUIC-CHGTYP" },
+ { MAX8997_MUICIRQ_OVP, "MUIC-OVP" },
};
/* Define supported cable type */
@@ -553,17 +553,17 @@ static void max8997_muic_irq_work(struct work_struct
*work)
}
switch (irq_type) {
- case MAX8997_MUICIRQ_ADCError:
- case MAX8997_MUICIRQ_ADCLow:
+ case MAX8997_MUICIRQ_ADCERROR:
+ case MAX8997_MUICIRQ_ADCLOW:
case MAX8997_MUICIRQ_ADC:
/* Handle all of cable except for charger cable */
ret = max8997_muic_adc_handler(info);
break;
- case MAX8997_MUICIRQ_VBVolt:
- case MAX8997_MUICIRQ_DBChg:
- case MAX8997_MUICIRQ_DCDTmr:
- case MAX8997_MUICIRQ_ChgDetRun:
- case MAX8997_MUICIRQ_ChgTyp:
+ case MAX8997_MUICIRQ_VBVOLT:
+ case MAX8997_MUICIRQ_DBCHG:
+ case MAX8997_MUICIRQ_DCDTMR:
+ case MAX8997_MUICIRQ_CHGDETRUN:
+ case MAX8997_MUICIRQ_CHGTYP:
/* Handle charger cable */
ret = max8997_muic_chg_handler(info);
break;
diff --git a/include/linux/mfd/max8997-private.h
b/include/linux/mfd/max8997-private.h
index f42ea22..2817fa6 100644
--- a/include/linux/mfd/max8997-private.h
+++ b/include/linux/mfd/max8997-private.h
@@ -411,14 +411,14 @@ enum max8997_irq {
enum max8997_irq_muic {
MAX8997_MUICIRQ_ADC,
- MAX8997_MUICIRQ_ADCLow,
- MAX8997_MUICIRQ_ADCError,
-
- MAX8997_MUICIRQ_ChgTyp,
- MAX8997_MUICIRQ_ChgDetRun,
- MAX8997_MUICIRQ_DCDTmr,
- MAX8997_MUICIRQ_DBChg,
- MAX8997_MUICIRQ_VBVolt,
+ MAX8997_MUICIRQ_ADCLOW,
+ MAX8997_MUICIRQ_ADCERROR,
+
+ MAX8997_MUICIRQ_CHGTYP,
+ MAX8997_MUICIRQ_CHGDETRUN,
+ MAX8997_MUICIRQ_DCDTMR,
+ MAX8997_MUICIRQ_DBCHG,
+ MAX8997_MUICIRQ_VBVOLT,
MAX8997_MUICIRQ_OVP,
--
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: [PATCH 3.10 000/123] 3.10.60-stable review
On Wed, Nov 12, 2014 at 03:22:55PM +0900, Greg Kroah-Hartman wrote: > On Tue, Nov 11, 2014 at 09:21:48PM -0800, Guenter Roeck wrote: > > On 11/11/2014 05:16 PM, Greg Kroah-Hartman wrote: > > >This is the start of the stable review cycle for the 3.10.60 release. > > >There are 123 patches in this series, all will be posted as a response > > >to this one. If anyone has any issues with these being applied, please > > >let me know. > > > > > >Responses should be made by Fri Nov 14 01:17:00 UTC 2014. > > >Anything received after that time might be too late. > > > > > > > As an early heads up, I see some builds failing in 3.10 and 3.14 with > > > > drivers/of/selftest.c: In function 'of_selftest': > > drivers/of/selftest.c:224:2: error: implicit declaration of function > > 'of_selftest_property_match_string' [-Werror=implicit-function-declaration] > > of_selftest_property_match_string(); > > ^ > > drivers/of/selftest.c: At top level: > > drivers/of/selftest.c:129:20: warning: 'of_selftest_property_string' > > defined but not used [-Wunused-function] > > static void __init of_selftest_property_string(void) > > ^ > > > > Not surprising, since commit 'of: Fix overflow bug in string property > > parsing functions' replaces the now missing function with the defined > > but unused function, apparently without changing the caller. > > Oddly enough, the referenced upstream commit _does_ replace the > > function name for both caller and callee. > > Crap, I took the "ignore the rejects" too literally when applying that > patch, let me go rework it and see if I can fix it up. And I've fixed it now. I doubt it's worth rolling a new -rc release for this, given the low number of builds that are failing. 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 v5 2/3] mfd: max8997: handle IRQs using regmap
This patch modifies mfd driver to use regmap for handling interrupts.
It allows to simplify irq handling process. This modifications needed
to make small changes in function drivers, which use interrupts.
Signed-off-by: Robert Baldyga
Reviewed-by: Krzysztof Kozlowski
[For extcon part]
Acked-by: Chanwoo Choi
[For the mfd part]
Acked-by: Lee Jones
---
drivers/extcon/extcon-max8997.c | 3 +-
drivers/mfd/Kconfig | 2 +-
drivers/mfd/Makefile| 2 +-
drivers/mfd/max8997-irq.c | 373
drivers/mfd/max8997.c | 112 ++-
drivers/rtc/rtc-max8997.c | 2 +-
include/linux/mfd/max8997-private.h | 63 +-
7 files changed, 165 insertions(+), 392 deletions(-)
delete mode 100644 drivers/mfd/max8997-irq.c
diff --git a/drivers/extcon/extcon-max8997.c b/drivers/extcon/extcon-max8997.c
index 2aafd5b..172dbd6 100644
--- a/drivers/extcon/extcon-max8997.c
+++ b/drivers/extcon/extcon-max8997.c
@@ -677,7 +677,8 @@ static int max8997_muic_probe(struct platform_device *pdev)
struct max8997_muic_irq *muic_irq = &muic_irqs[i];
unsigned int virq = 0;
- virq = irq_create_mapping(max8997->irq_domain, muic_irq->irq);
+ virq = regmap_irq_get_virq(max8997->irq_data_muic,
+ muic_irq->irq);
if (!virq) {
ret = -EINVAL;
goto err_irq;
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index ca57035..8cfc11b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -464,7 +464,7 @@ config MFD_MAX8997
depends on I2C=y
select MFD_CORE
select REGMAP_I2C
- select IRQ_DOMAIN
+ select REGMAP_IRQ
help
Say yes here to add support for Maxim Semiconductor MAX8997/8966.
This is a Power Management IC with RTC, Flash, Fuel Gauge, Haptic,
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 53467e2..e043ee4 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -120,7 +120,7 @@ obj-$(CONFIG_MFD_MAX77693) += max77693.o
obj-$(CONFIG_MFD_MAX8907) += max8907.o
max8925-objs := max8925-core.o max8925-i2c.o
obj-$(CONFIG_MFD_MAX8925) += max8925.o
-obj-$(CONFIG_MFD_MAX8997) += max8997.o max8997-irq.o
+obj-$(CONFIG_MFD_MAX8997) += max8997.o
obj-$(CONFIG_MFD_MAX8998) += max8998.o max8998-irq.o
pcf50633-objs := pcf50633-core.o pcf50633-irq.o
diff --git a/drivers/mfd/max8997-irq.c b/drivers/mfd/max8997-irq.c
deleted file mode 100644
index 0e7ff39..000
--- a/drivers/mfd/max8997-irq.c
+++ /dev/null
@@ -1,373 +0,0 @@
-/*
- * max8997-irq.c - Interrupt controller support for MAX8997
- *
- * Copyright (C) 2011 Samsung Electronics Co.Ltd
- * MyungJoo Ham
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
- *
- * This driver is based on max8998-irq.c
- */
-
-#include
-#include
-#include
-#include
-#include
-#include
-
-static const u8 max8997_mask_reg[] = {
- [PMIC_INT1] = MAX8997_REG_INT1MSK,
- [PMIC_INT2] = MAX8997_REG_INT2MSK,
- [PMIC_INT3] = MAX8997_REG_INT3MSK,
- [PMIC_INT4] = MAX8997_REG_INT4MSK,
- [FUEL_GAUGE] = MAX8997_REG_INVALID,
- [MUIC_INT1] = MAX8997_MUIC_REG_INTMASK1,
- [MUIC_INT2] = MAX8997_MUIC_REG_INTMASK2,
- [MUIC_INT3] = MAX8997_MUIC_REG_INTMASK3,
- [GPIO_LOW] = MAX8997_REG_INVALID,
- [GPIO_HI] = MAX8997_REG_INVALID,
- [FLASH_STATUS] = MAX8997_REG_INVALID,
-};
-
-struct max8997_irq_data {
- int mask;
- enum max8997_irq_source group;
-};
-
-#define DECLARE_IRQ(idx, _group, _mask)\
- [(idx)] = { .group = (_group), .mask = (_mask) }
-static const struct max8997_irq_data max8997_irqs[] = {
- DECLARE_IRQ(MAX8997_PMICIRQ_PWRONR, PMIC_INT1, 1 << 0),
- DECLARE_IRQ(MAX8997_PMICIRQ_PWRONF, PMIC_INT1, 1 << 1),
- DECLARE_IRQ(MAX8997_PMICIRQ_PWRON1SEC, PMIC_INT1, 1 << 3),
- DECLARE_IRQ(MAX8997_PMICIRQ_JIGONR, PMIC_INT1, 1 << 4),
- DECLARE_IRQ(MAX8997_PMICIRQ_JIGONF, PMIC_INT1, 1 << 5),
- DECLARE_IRQ(MAX8997_PMICIRQ_LOWBAT2,PMIC_INT1, 1 << 6),
- DECLARE_IRQ(MAX8997_PMICIRQ_LOWBAT1,PMIC_INT1
[PATCH v5 0/3] mfd: max8997: add regmap support
This patchset modifies max8997 driver and associated function drivers to use register maps instead of operating directly on i2c bus. This change allowed to simplify irq handling, and to move some initializations to individual function drivers. Hence now when some functions are not enabled, their i2c clients, regmaps and irqs are not registered. Because patches are under review for very long time and I still don't have all needed Acks, I'm resending this series rebased to the latest next branch. Best regards Robert Baldyga Samsung R&D Institute Poland Changelog: v5: - rebase patches to last next branch v4: - remove patch moving regmap handling to function drivers v3: https://lkml.org/lkml/2014/3/13/101 - fix error handling - fix deinitializations order - move muic irq enum values renaming to separate patch v2: https://lkml.org/lkml/2014/3/12/237 - rebase patches on Lee Jones' MFD tree - add missing selects in Kconfig - add missing deinitializations - add interrupt disabling when suspend - few minor changes and typo fixes v1: https://lkml.org/lkml/2014/3/11/291 Robert Baldyga (3): mfd: max8997: use regmap to access registers mfd: max8997: handle IRQs using regmap mfd: max8997: change irq names to upper case drivers/extcon/extcon-max8997.c | 66 +++--- drivers/input/misc/max8997_haptic.c | 34 ++-- drivers/leds/leds-max8997.c | 13 +- drivers/mfd/Kconfig | 3 +- drivers/mfd/Makefile| 2 +- drivers/mfd/max8997-irq.c | 387 drivers/mfd/max8997.c | 245 +++ drivers/power/max8997_charger.c | 33 +-- drivers/regulator/max8997.c | 87 drivers/rtc/rtc-max8997.c | 58 +++--- include/linux/mfd/max8997-private.h | 82 ++-- 11 files changed, 381 insertions(+), 629 deletions(-) delete mode 100644 drivers/mfd/max8997-irq.c -- 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: [PATCH 00/17] RFC: userfault v2
Hi Andrea, Is there any new about this discussion? ;) Will you plan to support 'only wrprotect fault' in the userfault API? Thanks, zhanghailiang On 2014/10/30 19:31, zhanghailiang wrote: On 2014/10/30 1:46, Andrea Arcangeli wrote: Hi Zhanghailiang, On Mon, Oct 27, 2014 at 05:32:51PM +0800, zhanghailiang wrote: Hi Andrea, Thanks for your hard work on userfault;) This is really a useful API. I want to confirm a question: Can we support distinguishing between writing and reading memory for userfault? That is, we can decide whether writing a page, reading a page or both trigger userfault. I think this will help supporting vhost-scsi,ivshmem for migration, we can trace dirty page in userspace. Actually, i'm trying to relize live memory snapshot based on pre-copy and userfault, but reading memory from migration thread will also trigger userfault. It will be easy to implement live memory snapshot, if we support configuring userfault for writing memory only. Mail is going to be long enough already so I'll just assume tracking dirty memory in userland (instead of doing it in kernel) is worthy feature to have here. After some chat during the KVMForum I've been already thinking it could be beneficial for some usage to give userland the information about the fault being read or write, combined with the ability of mapping pages wrprotected to mcopy_atomic (that would work without false positives only with MADV_DONTFORK also set, but it's already set in qemu). That will require "vma->vm_flags & VM_USERFAULT" to be checked also in the wrprotect faults, not just in the not present faults, but it's not a massive change. Returning the read/write information is also a not massive change. This will then payoff mostly if there's also a way to remove the memory atomically (kind of remap_anon_pages). Would that be enough? I mean are you still ok if non present read fault traps too (you'd be notified it's a read) and you get notification for both wrprotect and non present faults? Hi Andrea, Thanks for your reply, and your patience;) Er, maybe i didn't describe clearly. What i really need for live memory snapshot is only wrprotect fault, like kvm's dirty tracing mechanism, *only tracing write action*. My initial solution scheme for live memory snapshot is: (1) pause VM (2) using userfaultfd to mark all memory of VM is wrprotect (readonly) (3) save deivce state to snapshot file (4) resume VM (5) snapshot thread begin to save page of memory to snapshot file (6) VM is going to run, and it is OK for VM or other thread to read ram (no fault trap), but if VM try to write page (dirty the page), there will be a userfault trap notification. (7) a fault-handle-thread reads the page request from userfaultfd, it will copy content of the page to some buffers, and then remove the page's wrprotect limit(still using the userfaultfd to tell kernel). (8) after step (7), VM can continue to write the page which is now can be write. (9) snapshot thread save the page cached in step (7) (10) repeat step (5)~(9) until all VM's memory is saved to snapshot file. So, what i need for userfault is supporting only wrprotect fault. i don't want to get notification for non present reading faults, it will influence VM's performance and the efficiency of doing snapshot. Also, i think this feature will benefit for migration of ivshmem and vhost-scsi which have no dirty-page-tracing now. The question then is how you mark the memory readonly to let the wrprotect faults trap if the memory already existed and you didn't map it yourself in the guest with mcopy_atomic with a readonly flag. My current plan would be: - keep MADV_USERFAULT|NOUSERFAULT just to set VM_USERFAULT for the fast path check in the not-present and wrprotect page fault - if VM_USERFAULT is set, find if there's a userfaultfd registered into that vma too if yes engage userfaultfd protocol otherwise raise SIGBUS (single threaded apps should be fine with SIGBUS and it'll avoid them to spawn a thread in order to talk the userfaultfd protocol) - if userfaultfd protocol is engaged, return read|write fault + fault address to read(ufd) syscalls - leave the "userfault" resolution mechanism independent of the userfaultfd protocol so we keep the two problems separated and we don't mix them in the same API which makes it even harder to finalize it. add mcopy_atomic (with a flag to map the page readonly too) The alternative would be to hide mcopy_atomic (and even remap_anon_pages in order to "remove" the memory atomically for the externalization into the cloud) as userfaultfd commands to write into the fd. But then there would be no much point to keep MADV_USERFAULT around if I do so and I could just remove it too or it doesn't look clean having to open the userfaultfd just to issue an hidden mcopy_atomic. So it becomes a decision if the basic SIGBUS mode for single
[PATCH 7/8] crypto: AF_ALG: add random number generator support
This patch adds the random number generator support for AF_ALG.
A random number generator's purpose is to generate data without
requiring the caller to provide any data. Therefore, the AF_ALG
interface handler for RNGs only implements a callback handler for
recvmsg.
The following parameters provided with a recvmsg are processed by the
RNG callback handler:
* sock - to resolve the RNG context data structure accessing the
RNG instance private to the socket
* len - this parameter allows userspace callers to specify how
many random bytes the RNG shall produce and return. As the
kernel context for the RNG allocates a buffer of 128 bytes to
store random numbers before copying them to userspace, the len
parameter is checked that it is not larger than 128. If a
caller wants more random numbers, a new request for recvmsg
shall be made.
The size of 128 bytes is chose because of the following considerations:
* to increase the memory footprint of the kernel too much (note,
that would be 128 bytes per open socket)
* 128 is divisible by any typical cryptographic block size an
RNG may have
* A request for random numbers typically only shall supply small
amount of data like for keys or IVs that should only require
one invocation of the recvmsg function.
Note, during instantiation of the RNG, the code checks whether the RNG
implementation requires seeding. If so, the RNG is seeded with output
from get_random_bytes.
A fully working example using all aspects of the RNG interface is
provided at http://www.chronox.de/libkcapi.html
Signed-off-by: Stephan Mueller
---
crypto/algif_rng.c | 186 +
1 file changed, 186 insertions(+)
create mode 100644 crypto/algif_rng.c
diff --git a/crypto/algif_rng.c b/crypto/algif_rng.c
new file mode 100644
index 000..d1904d7
--- /dev/null
+++ b/crypto/algif_rng.c
@@ -0,0 +1,186 @@
+/*
+ * algif_rng: User-space interface for random number generators
+ *
+ * This file provides the user-space API for random number generators.
+ *
+ * Copyright (C) 2014, Stephan Mueller
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, and the entire permission notice in its entirety,
+ *including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ *products derived from this software without specific prior
+ *written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL2 are
+ * required INSTEAD OF the above restrictions. (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Stephan Mueller ");
+MODULE_DESCRIPTION("User-space interface for random number generators");
+
+struct rng_ctx {
+#define MAXSIZE 128
+ u8 result[MAXSIZE];
+ unsigned int len;
+ struct crypto_rng *drng;
+};
+
+static int rng_recvmsg(struct kiocb *unused, struct socket *sock,
+ struct msghdr *msg, size_t len, int flags)
+{
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct rng_ctx *ctx = ask->private;
+ int err = -EFAULT;
+
+ if (0 == len)
+ return 0;
+ if (MAXSIZE < len)
+ len = MAXSIZE;
+
+ lock_sock(sk);
+ len = crypto_rng_get_bytes(ctx->drng, ctx->result, len);
+ if (0 > len)
+ goto unlock;
+
+ err = memcpy_toiovec(msg->msg_iov, ctx-
[PATCH 2/8] crypto: AF_ALG: user space interface for cipher info
The AF_ALG interface allows normal cipher (hash, encrypt, decrypt).
However, it does not allow user space to obtain the following generic
information about the currently active cipher:
* block size of the cipher
* IV size of the cipher
* for AEAD, the maximum authentication tag size
The patch adds a getsockopt interface for the symmetric ciphers to
answer such information requests from user space.
The kernel crypto API function calls are used to obtain the real data.
As all data are simple integer values, the getsockopt handler function
uses put_user() to return the integer value to user space in the
*optval parameter of getsockopt.
Signed-off-by: Stephan Mueller
---
crypto/algif_skcipher.c | 46 -
include/uapi/linux/if_alg.h | 3 +++
2 files changed, 48 insertions(+), 1 deletion(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 83187f4..7a1656b 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -522,6 +522,50 @@ static unsigned int skcipher_poll(struct file *file,
struct socket *sock,
return mask;
}
+static int skcipher_getsockopt(struct socket *sock, int level, int optname,
+ char __user *optval, int __user *optlen)
+{
+ struct sock *sk = sock->sk;
+ struct alg_sock *ask = alg_sk(sk);
+ struct skcipher_ctx *ctx = ask->private;
+ const struct af_alg_type *type;
+ int len = 0;
+ int err = -EOPNOTSUPP;
+
+ lock_sock(sk);
+ type = ask->type;
+
+ if (level != SOL_ALG || !type)
+ goto unlock;
+
+ switch (optname) {
+ case ALG_GET_BLOCKSIZE:
+ len = skcipher_crypto_blocksize(ctx);
+ err = 0;
+ break;
+ case ALG_GET_IVSIZE:
+ len = skcipher_crypto_ivsize_ctx(ctx);
+ err = 0;
+ break;
+ case ALG_GET_AEAD_AUTHSIZE:
+ if (ctx->aead) {
+ len = crypto_aead_authsize(crypto_aead_reqtfm(
+ &ctx->u.aead_req));
+ err = 0;
+ }
+ break;
+ default:
+ break;
+ }
+
+unlock:
+ release_sock(sk);
+ if (err >= 0)
+ err = put_user(len, optlen);
+
+ return err;
+}
+
static struct proto_ops algif_skcipher_ops = {
.family = PF_ALG,
@@ -531,7 +575,6 @@ static struct proto_ops algif_skcipher_ops = {
.ioctl = sock_no_ioctl,
.listen = sock_no_listen,
.shutdown = sock_no_shutdown,
- .getsockopt = sock_no_getsockopt,
.mmap = sock_no_mmap,
.bind = sock_no_bind,
.accept = sock_no_accept,
@@ -542,6 +585,7 @@ static struct proto_ops algif_skcipher_ops = {
.sendpage = skcipher_sendpage,
.recvmsg= skcipher_recvmsg,
.poll = skcipher_poll,
+ .getsockopt = skcipher_getsockopt,
};
static void *skcipher_bind(const char *name, u32 type, u32 mask)
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index 64e7008..267fd73 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -39,6 +39,9 @@ struct af_alg_aead_assoc {
#define ALG_SET_OP 3
#define ALG_SET_AEAD_ASSOC 4
#define ALG_SET_AEAD_AUTHSIZE 5
+#define ALG_GET_BLOCKSIZE 6
+#define ALG_GET_IVSIZE 7
+#define ALG_GET_AEAD_AUTHSIZE 8
/* Operations */
#define ALG_OP_DECRYPT 0
--
2.1.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 6/8] crypto: AF_ALG: make setkey optional
The current AF_ALG implementation requires that a userspace interface implementation must provide a callback for setkey. Such a call is not appliable to random number generators. To prepare AF_ALG for the addition of a random number generator user space interface, this function callback invocation is made optional. Signed-off-by: Stephan Mueller --- crypto/af_alg.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/crypto/af_alg.c b/crypto/af_alg.c index 635140b..47a199c 100644 --- a/crypto/af_alg.c +++ b/crypto/af_alg.c @@ -177,6 +177,9 @@ static int alg_setkey(struct sock *sk, char __user *ukey, u8 *key; int err; + if (!type->setkey) + return -EOPNOTSUPP; + key = sock_kmalloc(sk, keylen, GFP_KERNEL); if (!key) return -ENOMEM; -- 2.1.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 4/8] crypto: AF_ALG: crypto API calls to inline functions
To avoid excessive branches and cluttering the code, all kernel crypto
API calls are extracted into separate inline functions. These functions
invoke either the ablkcipher or the aead crypto API function calls, as
necessary.
Signed-off-by: Stephan Mueller
---
crypto/algif_skcipher.c | 141 ++--
1 file changed, 124 insertions(+), 17 deletions(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 9286cfc..fb8efc8 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -247,14 +247,121 @@ static void skcipher_data_wakeup(struct sock *sk)
rcu_read_unlock();
}
+static inline bool skcipher_is_aead(struct crypto_tfm *tfm)
+{
+ return ((crypto_tfm_alg_type(tfm) & CRYPTO_ALG_TYPE_MASK) ==
+ CRYPTO_ALG_TYPE_AEAD);
+}
+
+static inline unsigned int skcipher_crypto_ivsize(void *private)
+{
+ if (skcipher_is_aead(private))
+ return crypto_aead_ivsize(private);
+ else
+ return crypto_ablkcipher_ivsize(private);
+}
+
+static inline unsigned int skcipher_crypto_ivsize_ctx(struct skcipher_ctx *ctx)
+{
+ if (ctx->aead)
+ return crypto_aead_ivsize(crypto_aead_reqtfm(&ctx->u.aead_req));
+ else
+ return crypto_ablkcipher_ivsize(
+ crypto_ablkcipher_reqtfm(&ctx->u.ablkcipher_req));
+}
+
+static inline unsigned int skcipher_crypto_blocksize(struct skcipher_ctx *ctx)
+{
+ if (ctx->aead)
+ return crypto_aead_blocksize(
+ crypto_aead_reqtfm(&ctx->u.aead_req));
+ else
+ return crypto_ablkcipher_blocksize(
+ crypto_ablkcipher_reqtfm(&ctx->u.ablkcipher_req));
+}
+
+static inline unsigned int skcipher_crypto_reqsize(void *private)
+{
+ if (skcipher_is_aead(private))
+ return crypto_aead_reqsize(private);
+ else
+ return crypto_ablkcipher_reqsize(private);
+}
+
+static inline unsigned int skcipher_crypto_setkey(void *private, const u8 *key,
+ unsigned int keylen)
+{
+ if (skcipher_is_aead(private))
+ return crypto_aead_setkey(private, key, keylen);
+ else
+ return crypto_ablkcipher_setkey(private, key, keylen);
+}
+
+static inline void skcipher_crypto_free(void *private)
+{
+ if (skcipher_is_aead(private))
+ crypto_free_aead(private);
+ else
+ crypto_free_ablkcipher(private);
+}
+
+static inline void skcipher_request_set_tfm(struct skcipher_ctx *ctx, void
*tfm)
+{
+ if (ctx->aead)
+ aead_request_set_tfm(&ctx->u.aead_req, tfm);
+ else
+ ablkcipher_request_set_tfm(&ctx->u.ablkcipher_req, tfm);
+}
+
+static inline int skcipher_crypto_encrypt(struct skcipher_ctx *ctx)
+{
+ if (ctx->aead)
+ return crypto_aead_encrypt(&ctx->u.aead_req);
+ else
+ return crypto_ablkcipher_encrypt(&ctx->u.ablkcipher_req);
+}
+
+static inline int skcipher_crypto_decrypt(struct skcipher_ctx *ctx)
+{
+ if (ctx->aead)
+ return crypto_aead_decrypt(&ctx->u.aead_req);
+ else
+ return crypto_ablkcipher_decrypt(&ctx->u.ablkcipher_req);
+}
+
+static inline void skcipher_crypto_set_crypt(struct skcipher_ctx *ctx,
+struct scatterlist *src,
+struct scatterlist *dst,
+unsigned int cryptlen, u8 *iv)
+{
+ if (ctx->aead)
+ return aead_request_set_crypt(&ctx->u.aead_req, src, dst,
+ cryptlen, iv);
+ else
+ return ablkcipher_request_set_crypt(&ctx->u.ablkcipher_req, src,
+ dst, cryptlen, iv);
+}
+
+static inline void skcipher_request_set_callback(struct skcipher_ctx *ctx,
+u32 flags,
+crypto_completion_t complete,
+void *data)
+{
+ if (ctx->aead)
+ aead_request_set_callback(&ctx->u.aead_req, flags, complete,
+ data);
+ else
+ ablkcipher_request_set_callback(&ctx->u.ablkcipher_req, flags,
+ complete, data);
+}
+
static int skcipher_sendmsg(struct kiocb *unused, struct socket *sock,
struct msghdr *msg, size_t size)
{
struct sock *sk = sock->sk;
struct alg_sock *ask = alg_sk(sk);
struct skcipher_ctx *ctx = ask->private;
- struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(&ctx->req);
- unsigned ivsize = crypto_ablkcipher_ivsize(tfm);
+ unsigned ivsize = skcipher_crypto_ivsize_ctx(ctx);
struct skciphe
[PATCH 1/8] crypto: AF_ALG: add user space interface for AEAD
AEAD requires the following data in addition to normal symmetric
ciphers:
* Associated authentication data of arbitrary length
* Authentication tag for decryption
* Length of authentication tag for encryption
The authentication tag data is communicated as part of the actual
ciphertext as mandated by the kernel crypto API. Therefore we only need
to provide a user space interface for the associated authentication data
as well as for the authentication tag length.
This patch adds both as a setsockopt interface that is identical to the
AF_ALG interface for setting an IV and for selecting the cipher
operation type (encrypt or decrypt).
Signed-off-by: Stephan Mueller
---
crypto/af_alg.c | 17 +
include/crypto/if_alg.h | 2 ++
include/uapi/linux/if_alg.h | 7 +++
3 files changed, 26 insertions(+)
diff --git a/crypto/af_alg.c b/crypto/af_alg.c
index 6a3ad80..635140b 100644
--- a/crypto/af_alg.c
+++ b/crypto/af_alg.c
@@ -421,6 +421,23 @@ int af_alg_cmsg_send(struct msghdr *msg, struct
af_alg_control *con)
con->op = *(u32 *)CMSG_DATA(cmsg);
break;
+
+ case ALG_SET_AEAD_AUTHSIZE:
+ if (cmsg->cmsg_len < CMSG_LEN(sizeof(u32)))
+ return -EINVAL;
+ con->aead_authsize = *(u32 *)CMSG_DATA(cmsg);
+ break;
+
+ case ALG_SET_AEAD_ASSOC:
+ if (cmsg->cmsg_len < CMSG_LEN(sizeof(*con->aead_assoc)))
+ return -EINVAL;
+ con->aead_assoc = (void *)CMSG_DATA(cmsg);
+ if (cmsg->cmsg_len <
+ CMSG_LEN(con->aead_assoc->aead_assoclen +
+sizeof(*con->aead_assoc)))
+ return -EINVAL;
+ break;
+
default:
return -EINVAL;
}
diff --git a/include/crypto/if_alg.h b/include/crypto/if_alg.h
index d61c111..c741483 100644
--- a/include/crypto/if_alg.h
+++ b/include/crypto/if_alg.h
@@ -41,7 +41,9 @@ struct af_alg_completion {
struct af_alg_control {
struct af_alg_iv *iv;
+ struct af_alg_aead_assoc *aead_assoc;
int op;
+ unsigned int aead_authsize;
};
struct af_alg_type {
diff --git a/include/uapi/linux/if_alg.h b/include/uapi/linux/if_alg.h
index 0f9acce..64e7008 100644
--- a/include/uapi/linux/if_alg.h
+++ b/include/uapi/linux/if_alg.h
@@ -28,10 +28,17 @@ struct af_alg_iv {
__u8iv[0];
};
+struct af_alg_aead_assoc {
+ __u32 aead_assoclen;
+ __u8aead_assoc[0];
+};
+
/* Socket options */
#define ALG_SET_KEY1
#define ALG_SET_IV 2
#define ALG_SET_OP 3
+#define ALG_SET_AEAD_ASSOC 4
+#define ALG_SET_AEAD_AUTHSIZE 5
/* Operations */
#define ALG_OP_DECRYPT 0
--
2.1.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 5/8] crypto: AF_ALG: add AEAD support
This patch adds the AEAD support for AF_ALG.
The AEAD implementation uses the entire memory handling and
infrastructure of the existing skcipher implementation.
To use AEAD, the user space consumer has to use the salg_type named
"aead". The AEAD extension only uses the bind callback as the key
differentiator. The previously added functions that select whether to
use AEAD or ablkcipher crypto API functions depend on the TFM type
allocated during the bind() call.
The addition of AEAD brings a bit of overhead to calculate the size of
the ciphertext, because the AEAD implementation of the kernel crypto API
makes implied assumption on the location of the authentication tag. When
performing an encryption, the tag will be added to the created
ciphertext (note, the tag is placed adjacent to the ciphertext). For
decryption, the caller must hand in the ciphertext with the tag appended
to the ciphertext. Therefore, the selection of the used memory
needs to add/subtract the tag size from the source/destination buffers
depending on the encryption type. The code is provided with comments
explainint when and how that operation is performed.
Note: The AF_ALG interface does not support zero length plaintext or
zero length ciphertext. Such zero length input data may be used if one
wants to access the hash implementation of an AEAD directly (e.g. the
GHASH of GCM or CMAC for CCM). However, this is a use case that is not
of interest. GHASH or CMAC is directly available via the hash AF_ALG
interface and we therefore do not need to take precautions for this
use case.
A fully working example using all aspects of AEAD is provided at
http://www.chronox.de/libkcapi.html
Signed-off-by: Stephan Mueller
---
crypto/algif_skcipher.c | 153 +---
1 file changed, 144 insertions(+), 9 deletions(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index fb8efc8..1e2763d 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -387,6 +387,17 @@ static int skcipher_sendmsg(struct kiocb *unused, struct
socket *sock,
if (con.iv && con.iv->ivlen != ivsize)
return -EINVAL;
+
+ /*
+* AEAD associated data is limited to a sensible size
+* Size limit is set to some arbitrary length to avoid
+* user space eating up memory
+*/
+ if (ctx->aead &&
+ (con.aead_assoc->aead_assoclen > MAX_AEAD_ASSOCLEN ||
+!con.aead_assoc->aead_assoclen ||
+!con.aead_assoc || !con.aead_authsize))
+ return -EINVAL;
}
err = -EINVAL;
@@ -399,6 +410,25 @@ static int skcipher_sendmsg(struct kiocb *unused, struct
socket *sock,
ctx->enc = enc;
if (con.iv)
memcpy(ctx->iv, con.iv->iv, ivsize);
+ /* AEAD authentication data handling */
+ if (ctx->aead) {
+ if (con.aead_authsize)
+ err = crypto_aead_setauthsize(
+ crypto_aead_reqtfm(&ctx->u.aead_req),
+ con.aead_authsize);
+ if (err)
+ goto unlock;
+ /* set associated data */
+ memcpy(ctx->aead_assoc,
+ con.aead_assoc->aead_assoc,
+ con.aead_assoc->aead_assoclen);
+ sg_init_one(&ctx->sg_aead_assoc,
+ ctx->aead_assoc,
+ con.aead_assoc->aead_assoclen);
+ aead_request_set_assoc(&ctx->u.aead_req,
+ &ctx->sg_aead_assoc,
+ con.aead_assoc->aead_assoclen);
+ }
}
while (size) {
@@ -547,10 +577,41 @@ static int skcipher_recvmsg(struct kiocb *unused, struct
socket *sock,
int err = -EAGAIN;
int used;
long copied = 0;
+ unsigned int aead_authsize_enc = 0;
+ unsigned int aead_authsize_dec = 0;
lock_sock(sk);
+ /*
+ * AEAD memory structure: For encryption, the tag is appended to the
+ * ciphertext which implies that the memory allocated for the ciphertext
+ * must be increased by the tag length. For decryption, the tag
+ * is expected to be concatenated to the ciphertext. The plaintext
+ * therefore has a memory size of the ciphertext minus the tag length.
+ *
+ * Note: this memory calculation only works because we require the
+ * user space caller to:
+ * * perform encryption by invoking the recv function with a buffer
+ * length of ciphertext + tag size -- the send function can be
+ * invoked nor
[PATCH 0/8] crypto: AF_ALG: add AEAD and RNG support
Hi, This patch set adds AEAD and RNG support to the AF_ALG interface exported by the kernel crypto API. By extending AF_ALG with AEAD and RNG support, all cipher types the kernel crypto API allows access to are now accessible from userspace. The RNG support is stand-alone. The AEAD implementation is added to algif_skcipher.c to prevent re-implementation of the memory moving logic. The extension for the AEAD support can be summarized with the following types of changes: * select the correct crypto API functions (either the ablkcipher or the aead functions) * apply the additional data needed for AEAD at the right time (associated data, authentication tag) -- this includes the addition of user space interfaces to allow setting this data. * add the calculation for the memory size needed for encryption and decryption. In addition, the patch set adds a getsockopt implementation to skcipher to allow user space to inquire about properties of the ciphers (IV size, block size, authentication data size). This extension would be needed for a generic user space usage of these ciphers. The new AEAD and RNG interfaces are fully tested with the test application provided at [1]. That test application exercises all newly added user space interfaces. The patch set was tested on x86_64 and i386. [1] http://www.chronox.de/libkcapi.html Stephan Mueller (8): crypto: AF_ALG: add user space interface for AEAD crypto: AF_ALG: user space interface for cipher info crypto: AF_ALG: extend data structuers for AEAD crypto: AF_ALG: crypto API calls to inline functions crypto: AF_ALG: add AEAD support crypto: AF_ALG: make setkey optional crypto: AF_ALG: add random number generator support crypto: AF_ALG: enable RNG interface compilation crypto/Kconfig | 9 ++ crypto/Makefile | 1 + crypto/af_alg.c | 20 +++ crypto/algif_rng.c | 186 +++ crypto/algif_skcipher.c | 350 include/crypto/if_alg.h | 2 + include/uapi/linux/if_alg.h | 10 ++ 7 files changed, 550 insertions(+), 28 deletions(-) create mode 100644 crypto/algif_rng.c -- 2.1.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 3/8] crypto: AF_ALG: extend data structuers for AEAD
The data structure holding the state of an ongoing symmetric cipher
operation is extended by the data variables needed for AEAD.
The request data structures are encapsulated by a union as the symmetric
cipher implementation is either exclusively used for "normal" symmetric
ciphers or for AEAD ciphers.
The define MAX_AEAD_ASSOCLEN restricts the size of the associated
authentication data. The kernel must allocate memory for this data to be
stored for the cipher operation. To prevent an excessive use of memory,
it is limited to 128 bytes, which is considered to be a sensible size.
Signed-off-by: Stephan Mueller
---
crypto/algif_skcipher.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c
index 7a1656b..9286cfc 100644
--- a/crypto/algif_skcipher.c
+++ b/crypto/algif_skcipher.c
@@ -46,7 +46,15 @@ struct skcipher_ctx {
bool merge;
bool enc;
- struct ablkcipher_request req;
+ bool aead;
+ void *aead_assoc;
+ /* define arbitrary maximum length of associated data */
+ #define MAX_AEAD_ASSOCLEN 128
+ struct scatterlist sg_aead_assoc;
+ union {
+ struct ablkcipher_request ablkcipher_req;
+ struct aead_request aead_req;
+ } u;
};
#define MAX_SGL_ENTS ((4096 - sizeof(struct skcipher_sg_list)) / \
--
2.1.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 8/8] crypto: AF_ALG: enable RNG interface compilation
Enable compilation of the RNG AF_ALG support and provide a Kconfig option to compile the RNG AF_ALG support. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 9 + crypto/Makefile | 1 + 2 files changed, 10 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 87bbc9c..e127323 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1505,6 +1505,15 @@ config CRYPTO_USER_API_SKCIPHER This option enables the user-spaces interface for symmetric key cipher algorithms. +config CRYPTO_USER_API_RNG + tristate "User-space interface for random number generator algorithms" + depends on NET + select CRYPTO_RNG + select CRYPTO_USER_API + help + This option enables the user-spaces interface for random + number generator algorithms. + config CRYPTO_HASH_INFO bool diff --git a/crypto/Makefile b/crypto/Makefile index 1445b91..ba19465 100644 --- a/crypto/Makefile +++ b/crypto/Makefile @@ -99,6 +99,7 @@ obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o obj-$(CONFIG_CRYPTO_USER_API_HASH) += algif_hash.o obj-$(CONFIG_CRYPTO_USER_API_SKCIPHER) += algif_skcipher.o +obj-$(CONFIG_CRYPTO_USER_API_RNG) += algif_rng.o # # generic algorithms and the async_tx api -- 2.1.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 V2 2/2] PCI: generic: Add msi_parent DT binding
Hi,
On Wed, Nov 12, 2014 at 12:26 PM, Srikanth Thokala
wrote:
> Hi,
>
> On Wed, Nov 12, 2014 at 12:47 AM, wrote:
>> From: Suravee Suthikulpanit
>>
>> This patch introduces a new DT binding, msi-parent, which can
>> be used to specify MSI-parent phandle for a particular PCI
>> generic host controller.
>>
>> Also, it implements and registers set_msi_parent callback.
>>
>> Cc: Bjorn Helgass
>> Cc: Liviu Dudau
>> Cc: Will Deacon
>> Cc: Lorenzo Pieralisi
>> Signed-off-by: Suravee Suthikulpanit
>> ---
>> Documentation/devicetree/bindings/pci/host-generic-pci.txt | 3 +++
>> drivers/pci/host/pci-host-generic.c| 13
>> +
>> 2 files changed, 16 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
>> b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
>> index cf3e205..6996af7 100644
>> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
>> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
>> @@ -36,6 +36,8 @@ Properties of the host controller node:
>> - reg: The Configuration Space base address and size, as
>> accessed
>> from the parent bus.
>>
>> +- msi-parent : Specify the phandle of the corresponded MSI controller
>> + for this PCI host controller.
>>
>> Properties of the /chosen node:
>>
>> @@ -77,6 +79,7 @@ pci {
>> device_type = "pci";
>> #address-cells = <3>;
>> #size-cells = <2>;
>> +msi-parent = <&msictrl0>;
>> bus-range = <0x0 0x1>;
>>
>> // CPU_PHYSICAL(2) SIZE(2)
>> diff --git a/drivers/pci/host/pci-host-generic.c
>> b/drivers/pci/host/pci-host-generic.c
>> index 1895907..c4fbcda 100644
>> --- a/drivers/pci/host/pci-host-generic.c
>> +++ b/drivers/pci/host/pci-host-generic.c
>> @@ -42,6 +42,7 @@ struct gen_pci {
>> struct pci_host_bridge host;
>> struct gen_pci_cfg_windows cfg;
>> struct list_headresources;
>> + struct msi_chip *mchip;
>> };
>>
>> static void __iomem *gen_pci_map_cfg_bus_cam(struct pci_bus *bus,
>> @@ -122,9 +123,19 @@ static int gen_pci_config_write(struct pci_bus *bus,
>> unsigned int devfn,
>> return PCIBIOS_SUCCESSFUL;
>> }
>>
>> +static int gen_pci_set_msi_parent(struct pci_bus *bus)
>> +{
>> + struct gen_pci *pci = bus_to_gen_pci(bus);
>> +
>> + bus->msi = pci->mchip;
>> +
>> + return PCIBIOS_SUCCESSFUL;
>> +}
>> +
>> static struct pci_ops gen_pci_ops = {
>> .read = gen_pci_config_read,
>> .write = gen_pci_config_write,
>> + .set_msi_parent = gen_pci_set_msi_parent,
>
> We assign the msi chip through add_bus() call, do we still need this?
>
There are series of patches from Yijing Wang around this. You may have
to go through them.
Srikanth
> Srikanth
>
>> };
>>
>> static const struct of_device_id gen_pci_of_match[] = {
>> @@ -303,6 +314,8 @@ static int gen_pci_probe(struct platform_device *pdev)
>> return err;
>> }
>>
>> + pci->mchip = of_pci_find_msi_chip_by_node(of_parse_phandle(np,
>> + "msi-parent", 0));
>> pci_common_init_dev(dev, &hw);
>> return 0;
>> }
>> --
>> 1.9.3
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] MAINTAINERS: Add IIO include files
On Tuesday, November 11, 2014 11:37 PM, Daniel Baluta wrote: > > Files under include/linux/iio were not reported as part > of the IIO subsystem. > > Reported-by: Cristina Ciocan > Signed-off-by: Daniel Baluta (+cc Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald) Reviewed-by: Jingoo Han Best regards, Jingoo Han > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b2f927b..ebb9c38 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4631,6 +4631,7 @@ L: linux-...@vger.kernel.org > S: Maintained > F: drivers/iio/ > F: drivers/staging/iio/ > +F: include/linux/iio/ > > IKANOS/ADI EAGLE ADSL USB DRIVER > M: Matthieu Castet > -- > 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: [PATCH 19/22] dt/bindings: add micrel,rmii_ref_clk_sel_25_mhz to eth-phy binding
On Tue, Nov 11, 2014 at 07:18:25PM +0100, Johan Hovold wrote: > On Tue, Nov 11, 2014 at 05:57:42PM +, Mark Rutland wrote: > > On Tue, Nov 11, 2014 at 05:37:37PM +, Johan Hovold wrote: > > > Add "micrel,rmii_ref_clk_sel_25_mhz" to Micrel ethernet PHY binding > > > documentation. > > > > > > Cc: devicet...@vger.kernel.org > > > Signed-off-by: Johan Hovold > > > --- > > > Documentation/devicetree/bindings/net/micrel.txt | 5 + > > > 1 file changed, 5 insertions(+) > > > > > > diff --git a/Documentation/devicetree/bindings/net/micrel.txt > > > b/Documentation/devicetree/bindings/net/micrel.txt > > > index a1bab5eaae02..9b08dd6551dd 100644 > > > --- a/Documentation/devicetree/bindings/net/micrel.txt > > > +++ b/Documentation/devicetree/bindings/net/micrel.txt > > > @@ -19,6 +19,11 @@ Optional properties: > > > > > >See the respective PHY datasheet for the mode values. > > > > > > + - micrel,rmii_ref_clk_sel_25_mhz: rmii_ref_clk_sel bit selects 25 MHz > > > mode > > > + > > > + Whether 25 MHz (rather than 50 Mhz) clock mode is selected > > > + when the rmii_ref_clk_sel bit is set. > > > > s/_/-/ in property names please. > > Ouch, copied from variable name, sorry. > > > That said, I don't follow the meaning. Does this cause the kernel to do > > something different, or is is simply that a 25MHz ref clock is wired up? > > Yes, the driver currently sets this configuration bit based on a common > clock binding. > > However, it turns out the meaning of the bit is reversed on some PHY > variants. On most PHYs 50 MHz mode is selected by setting this bit, > whereas on the PHYs that need this new property, setting it selects 25 > MHz mode instead. Maybe rename the property to something like rmii-ref-clk-25mhz-active-high then? Also you should probably make it more explicit that this is a hardware property and not for adjusting the clock. It's not very nice from Micrel to create Phys with exactly the same device id but the meaning of this bit reversed. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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] brcmfmac: unlink URB when request timed out
On Tue, 2014-11-11 at 20:02 -0500, Mathy Vanhoef wrote: > On 11/10/2014 04:08 AM, Oliver Neukum wrote: > > Which means that you are freeing memory that may still be used by DMA > > at this time. > > In addition you have no guarantee that the unlink is indeed finished > > by the time the URB is reused. > > If you wish to take this approach you better forget about this URB > > and allocate a new one and free the buffer from the callback. > > Hi Oliver, > > Good catch. I think the DMA issue is also present in the current driver: it > frees the buffer without unlinking/killing the URB at all. Can a malicious USB Yes, it is present. > device force a timeout to occur (i.e. delay the call to the completion > handler)? If so this might be a use-after-free vulnerability. > > It seems using usb_kill_urb instead of usb_unlink_urb in the patch prevents > any > possible use-after-free. Can someone double check? usb_kill_urb() will do the job. Regards Oliver -- 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] PCI: generic: Add msi_parent DT binding
Hi,
On Wed, Nov 12, 2014 at 12:47 AM, wrote:
> From: Suravee Suthikulpanit
>
> This patch introduces a new DT binding, msi-parent, which can
> be used to specify MSI-parent phandle for a particular PCI
> generic host controller.
>
> Also, it implements and registers set_msi_parent callback.
>
> Cc: Bjorn Helgass
> Cc: Liviu Dudau
> Cc: Will Deacon
> Cc: Lorenzo Pieralisi
> Signed-off-by: Suravee Suthikulpanit
> ---
> Documentation/devicetree/bindings/pci/host-generic-pci.txt | 3 +++
> drivers/pci/host/pci-host-generic.c| 13 +
> 2 files changed, 16 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> index cf3e205..6996af7 100644
> --- a/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/host-generic-pci.txt
> @@ -36,6 +36,8 @@ Properties of the host controller node:
> - reg: The Configuration Space base address and size, as accessed
> from the parent bus.
>
> +- msi-parent : Specify the phandle of the corresponded MSI controller
> + for this PCI host controller.
>
> Properties of the /chosen node:
>
> @@ -77,6 +79,7 @@ pci {
> device_type = "pci";
> #address-cells = <3>;
> #size-cells = <2>;
> +msi-parent = <&msictrl0>;
> bus-range = <0x0 0x1>;
>
> // CPU_PHYSICAL(2) SIZE(2)
> diff --git a/drivers/pci/host/pci-host-generic.c
> b/drivers/pci/host/pci-host-generic.c
> index 1895907..c4fbcda 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -42,6 +42,7 @@ struct gen_pci {
> struct pci_host_bridge host;
> struct gen_pci_cfg_windows cfg;
> struct list_headresources;
> + struct msi_chip *mchip;
> };
>
> static void __iomem *gen_pci_map_cfg_bus_cam(struct pci_bus *bus,
> @@ -122,9 +123,19 @@ static int gen_pci_config_write(struct pci_bus *bus,
> unsigned int devfn,
> return PCIBIOS_SUCCESSFUL;
> }
>
> +static int gen_pci_set_msi_parent(struct pci_bus *bus)
> +{
> + struct gen_pci *pci = bus_to_gen_pci(bus);
> +
> + bus->msi = pci->mchip;
> +
> + return PCIBIOS_SUCCESSFUL;
> +}
> +
> static struct pci_ops gen_pci_ops = {
> .read = gen_pci_config_read,
> .write = gen_pci_config_write,
> + .set_msi_parent = gen_pci_set_msi_parent,
We assign the msi chip through add_bus() call, do we still need this?
Srikanth
> };
>
> static const struct of_device_id gen_pci_of_match[] = {
> @@ -303,6 +314,8 @@ static int gen_pci_probe(struct platform_device *pdev)
> return err;
> }
>
> + pci->mchip = of_pci_find_msi_chip_by_node(of_parse_phandle(np,
> + "msi-parent", 0));
> pci_common_init_dev(dev, &hw);
> return 0;
> }
> --
> 1.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: Tree for Nov 12
Hi all,
Changes since 2014:
The slave-dma tree lost its build failure.
The block tree lost its build failure.
The mfd tree lost its build failure.
The driver-core tree gained a conflict against the hwmon-staging tree.
The akpm-current tree still had its build failures for which I applied
two patches.
Non-merge commits (relative to Linus' tree): 5824
6102 files changed, 186257 insertions(+), 159975 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" and checkout or reset to the new
master.
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64 and a
multi_v7_defconfig for arm. After the final fixups (if any), it is also
built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and
allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm
defconfig.
Below is a summary of the state of the merge.
I am currently merging 228 trees (counting Linus' and 32 trees of patches
pending for Linus' tree).
Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds. And to Paul
Gortmaker for triage and bug fixes.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (206c5f60a3d9 Linux 3.18-rc4)
Merging fixes/master (b94d525e58dc Merge
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging kbuild-current/rc-fixes (7d1311b93e58 Linux 3.17-rc1)
Merging arc-current/for-curr (2ce7598c9a45 Linux 3.17-rc4)
Merging arm-current/fixes (9ff0bb5ba606 ARM: 8180/1: mm: implement no-highmem
fast path in kmap_atomic_pfn())
Merging m68k-current/for-linus (f7bbd12a4b7e m68k: Wire up bpf)
Merging metag-fixes/fixes (ffe6902b66aa asm-generic: remove _STK_LIM_MAX)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-merge/merge (396a34340cdf powerpc: Fix endianness of
flash_block_list in rtas_flash)
Merging powerpc-merge-mpe/fixes (8a97577a5967 Merge branch 'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux)
Merging sparc/master (ab5c780913bc sparc64: Do irq_{enter,exit}() around
generic_smp_call_function*().)
Merging net/master (48eb5b9c3dd2 ixgbe: phy: fix uninitialized status in
ixgbe_setup_phy_link_tnx)
Merging ipsec/master (d10845fc85b2 Merge branch 'gso_encap_fixes')
Merging sound-current/for-linus (b4565913460c ALSA: hda_intel: Add DeviceIDs
for Sunrise Point-LP)
Merging pci-current/for-linus (32f638fc11db PCI: Don't oops on virtual buses in
acpi_pci_get_bridge_handle())
Merging wireless/master (4e6ce4dc7ce7 ath9k: Fix RTC_DERIVED_CLK usage)
Merging driver-core.current/driver-core-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging tty.current/tty-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging usb.current/usb-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging usb-gadget-fixes/fixes (520fe7633692 usb: dwc3: ep0: fix for dead code)
Merging usb-serial-fixes/usb-linus (ffcfe30ebd8d USB: serial: cp210x: add IDs
for CEL MeshConnect USB Stick)
Merging staging.current/staging-linus (206c5f60a3d9 Linux 3.18-rc4)
Merging char-misc.current/char-misc-linus (0df1f2487d2f Linux 3.18-rc3)
Merging input-current/for-linus (4ab8f7f320f9 Input: alps - ignore potential
bare packets when device is out of sync)
Merging md-current/for-linus (d47648fcf061 raid5: avoid finding "discard"
stripe)
Merging crypto-current/master (24c65bc7037e hwrng: pseries - port to new read
API and fix stack corruption)
Merging ide/master (7546e52b5e3d Drivers: ide: Remove typedef atiixp_ide_timing)
Merging dwmw2/master (5950f0803ca9 pcmcia: remove RPX board stuff)
Merging devicetree-current/devicetree/merge (a87fa1d81a9f of: Fix overflow bug
in string property parsing functions)
Merging rr-fixes/fixes (3438cf549d2f param: fix crash on bad kernel arguments)
Merging vfio-fixes/for-linus (239a87020b26 Merge branch
'for-joerg/arm-smmu/fixes' of
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into for-linus)
Merging kselftest-fixes/fixes (7069a97a1415 selftests/net: move test out of
Makefile into a shell
Re: [PATCH 3/4] powernv: cpuidle: Redesign idle states management
Hi Shreyas,
On 11/03/2014 09:38 PM, Shreyas B. Prabhu wrote:
> diff --git a/arch/powerpc/kernel/idle_power7.S
> b/arch/powerpc/kernel/idle_power7.S
> index 283c603..df11acb 100644
> --- a/arch/powerpc/kernel/idle_power7.S
> +++ b/arch/powerpc/kernel/idle_power7.S
> _GLOBAL(power7_idle)
> /* Now check if user or arch enabled NAP mode */
> @@ -141,49 +192,16 @@ _GLOBAL(power7_idle)
>
> _GLOBAL(power7_nap)
> mr r4,r3
> - li r3,0
> + li r3,1
The comment at the top of this file states 0 for nap and 1 for sleep.
You will need to change that. As an alternative I would suggest using
the macros that you have already defined:PNV_THREAD_NAP and
PNV_THREAD_SLEEP to write to r3 above and remove the lines that say 0
for nap and 1 for sleep in the comments.
> b power7_powersave_common
> /* No return */
>
> @@ -210,12 +226,91 @@ _GLOBAL(power7_wakeup_tb_loss)
> BEGIN_FTR_SECTION
> CHECK_HMI_INTERRUPT
> END_FTR_SECTION_IFSET(CPU_FTR_HVMODE)
> +
> + li r7,1
> + mfspr r8,SPRN_PIR
> + /*
> + * The last 3 bits of PIR represents the thread id of a cpu
> + * in power8. This will need adjusting for power7.
> + */
> + andi. r8,r8,0x07 /* Get thread id into r8 */
> + rotld r7,r7,r8
> + /* r7 now has 'thread_id'th bit set */
> +
> + ld r14,PACA_CORE_IDLE_STATE_PTR(r13)
> +lwarx_loop2:
> + lwarx r15,0,r14
> + andi. r9,r15,PNV_CORE_IDLE_LOCK_BIT
> + /*
> + * Lock bit is set in one of the 2 cases-
> + * a. In the sleep/winkle enter path, the last thread is executing
> + * fastsleep workaround code.
> + * b. In the wake up path, another thread is executing fastsleep
> + * workaround undo code or resyncing timebase or restoring context
> + * In either case loop until the lock bit is cleared.
> + */
> + bne lwarx_loop2
> +
> + cmpwi cr2,r15,0
> + or r15,r15,r7 /* Set thread bit */
> +
> + beq cr2,first_thread
> +
> + /* Not first thread in core to wake up */
> + stwcx. r15,0,r14
> + bne-lwarx_loop2
> + b common_exit
> +
> +first_thread:
> + /* First thread in core to wakeup */
> + ori r15,r15,PNV_CORE_IDLE_LOCK_BIT
> + stwcx. r15,0,r14
> + bne-lwarx_loop2
> +
> + LOAD_REG_ADDR(r3, pnv_need_fastsleep_workaround)
> + lbz r3,0(r3)
> + cmpwi r3,1
> + /* skip fastsleep workaround if its not needed */
> + bne timebase_resync
> +
> + /* Undo fast sleep workaround */
> + mfcrr16 /* Backup CR into a non-volatile register */
Don't you want to do this ^^ before calling opal_call_realmode for
timebase resync below also?
> + li r3,1
> + li r4,0
> + li r0,OPAL_CONFIG_CPU_IDLE_STATE
> + bl opal_call_realmode
> + mtcrr16 /* Restore CR */
> +
> + /* Do timebase resync if we are waking up from sleep. Use cr1 value
> + * set in exceptions-64s.S */
> + ble cr1,clear_lock
> +
> +timebase_resync:
> /* Time base re-sync */
> - li r3,OPAL_RESYNC_TIMEBASE
> + li r0,OPAL_RESYNC_TIMEBASE
> bl opal_call_realmode;
> -
> diff --git a/arch/powerpc/platforms/powernv/setup.c
> b/arch/powerpc/platforms/powernv/setup.c
> index 34c6665..980c964 100644
> --- a/arch/powerpc/platforms/powernv/setup.c
> +++ b/arch/powerpc/platforms/powernv/setup.c
> @@ -36,6 +36,8 @@
> #include
> #include
> #include
> +#include
> +#include
>
> #include "powernv.h"
>
> @@ -292,11 +294,55 @@ static void __init pnv_setup_machdep_rtas(void)
>
> static u32 supported_cpuidle_states;
>
> +static void pnv_alloc_idle_core_states(void)
> +{
> + int i, j;
> + int nr_cores = cpu_nr_cores();
> + u32 *core_idle_state;
> +
> + /*
> + * Deep idle states like sleep and winkle are per core idle states.
> + * A core enters these states only when all the threads enter either
> + * the particular idle state or a deeper one. There are tasks like
> + * fastsleep hardware bug workaround and hypervisor core state save
> + * which have to be done only by the last thread of the core entering
> + * deep idle state and similarly tasks like timebase resync, hypervisor
> + * core register restore that have to be done only by the first thread
> + * waking up from these states. Introducing core_idle_state, a per core
> + * structure which will keep track threads entering idle states deeper
> + * than sleep.
Since you already have explained ^^ in the changelog, you do not need to
elaborate it here.
> + * core_idle_state - First 8 bits track the idle state of each thread
> + * of the core. The 8th bit is the lock bit. Initially all thread bits
> + * are set. They are cleared when the thread enters deep idle state
> + * like sleep and winkle. Initially the lock bit is cleared.
you can simpl
Re: memblock: Refactor functions to set/clear MEMBLOCK_HOTPLUG
(2014/11/11 4:05), tony.l...@intel.com wrote:
> There is a lot of duplication in the rubric around actually setting or
> clearing a mem region flag. Create a new helper function to do this and
> reduce each of memblock_mark_hotplug() and memblock_clear_hotplug() to
> a single line.
>
> Signed-off-by: Tony Luck
>
> ---
The refactoring looks good.
Thanks,
Yasuaki Ishimatsu
>
> This will be useful if someone were to add a new mem region flag - which
> I hope to be doing some day soon. But it looks like a plausible cleanup
> even without that - so I'd like to get it out of the way now.
>
> diff --git a/mm/memblock.c b/mm/memblock.c
> index 6ecb0d937fb5..252b77bdf65e 100644
> --- a/mm/memblock.c
> +++ b/mm/memblock.c
> @@ -715,16 +715,13 @@ int __init_memblock memblock_reserve(phys_addr_t base,
> phys_addr_t size)
> }
>
> /**
> - * memblock_mark_hotplug - Mark hotpluggable memory with flag
> MEMBLOCK_HOTPLUG.
> - * @base: the base phys addr of the region
> - * @size: the size of the region
>*
> - * This function isolates region [@base, @base + @size), and mark it with
> flag
> - * MEMBLOCK_HOTPLUG.
> + * This function isolates region [@base, @base + @size), and sets/clears flag
>*
>* Return 0 on succees, -errno on failure.
>*/
> -int __init_memblock memblock_mark_hotplug(phys_addr_t base, phys_addr_t size)
> +static int __init_memblock memblock_setclr_flag(phys_addr_t base,
> + phys_addr_t size, int set, int flag)
> {
> struct memblock_type *type = &memblock.memory;
> int i, ret, start_rgn, end_rgn;
> @@ -734,37 +731,37 @@ int __init_memblock memblock_mark_hotplug(phys_addr_t
> base, phys_addr_t size)
> return ret;
>
> for (i = start_rgn; i < end_rgn; i++)
> - memblock_set_region_flags(&type->regions[i], MEMBLOCK_HOTPLUG);
> + if (set)
> + memblock_set_region_flags(&type->regions[i], flag);
> + else
> + memblock_clear_region_flags(&type->regions[i], flag);
>
> memblock_merge_regions(type);
> return 0;
> }
>
> /**
> - * memblock_clear_hotplug - Clear flag MEMBLOCK_HOTPLUG for a specified
> region.
> + * memblock_mark_hotplug - Mark hotpluggable memory with flag
> MEMBLOCK_HOTPLUG.
>* @base: the base phys addr of the region
>* @size: the size of the region
>*
> - * This function isolates region [@base, @base + @size), and clear flag
> - * MEMBLOCK_HOTPLUG for the isolated regions.
> + * Return 0 on succees, -errno on failure.
> + */
> +int __init_memblock memblock_mark_hotplug(phys_addr_t base, phys_addr_t size)
> +{
> + return memblock_setclr_flag(base, size, 1, MEMBLOCK_HOTPLUG);
> +}
> +
> +/**
> + * memblock_clear_hotplug - Clear flag MEMBLOCK_HOTPLUG for a specified
> region.
> + * @base: the base phys addr of the region
> + * @size: the size of the region
>*
>* Return 0 on succees, -errno on failure.
>*/
> int __init_memblock memblock_clear_hotplug(phys_addr_t base, phys_addr_t
> size)
> {
> - struct memblock_type *type = &memblock.memory;
> - int i, ret, start_rgn, end_rgn;
> -
> - ret = memblock_isolate_range(type, base, size, &start_rgn, &end_rgn);
> - if (ret)
> - return ret;
> -
> - for (i = start_rgn; i < end_rgn; i++)
> - memblock_clear_region_flags(&type->regions[i],
> - MEMBLOCK_HOTPLUG);
> -
> - memblock_merge_regions(type);
> - return 0;
> + return memblock_setclr_flag(base, size, 0, MEMBLOCK_HOTPLUG);
> }
>
> /**
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org
>
--
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/
[RFC v6 3/3] usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
From: Todd Poynor
usb: phy: hold wakeupsource when USB is enumerated in peripheral mode
Some systems require a mechanism to prevent system to enter into suspend
state when USB is connected and enumerated in peripheral mode.
This patch provides an interface to hold a wakeupsource to prevent suspend.
PHY drivers can use this interface when USB is connected and enumerated in
peripheral mode.
A timed wakeupsource is temporarily held on USB disconnect events, to allow
the rest of the system to react to the USB disconnection (dropping host
sessions, updating charger status, etc.) prior to re-allowing suspend.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Cc: Arve Hj�nnev�g
Cc: Benoit Goby
Signed-off-by: Todd Poynor
[kiran: Added context to commit message, squished build fixes
from Benoit Goby and Arve Hjønnevåg, changed wakelocks usage
to wakeupsource, merged Todd's refactoring logic and simplified
the structures and code and addressed community feedback]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/phy.c | 29 +++--
include/linux/usb/phy.h | 5 +
2 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 2b1039e..b5c5fd3 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -329,6 +329,7 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
int ret = 0;
unsigned long flags;
struct usb_phy *phy;
+ char wsource_name[40];
if (x->type != USB_PHY_TYPE_UNDEFINED) {
dev_err(x->dev, "not accepting initialized PHY %s\n", x->label);
@@ -351,6 +352,10 @@ int usb_add_phy(struct usb_phy *x, enum usb_phy_type type)
x->type = type;
list_add_tail(&x->head, &phy_list);
+ snprintf(wsource_name, sizeof(wsource_name), "vbus-%s",
+ dev_name(x->dev));
+ wakeup_source_init(&x->wsource, wsource_name);
+
out:
spin_unlock_irqrestore(&phy_lock, flags);
return ret;
@@ -402,6 +407,7 @@ void usb_remove_phy(struct usb_phy *x)
spin_lock_irqsave(&phy_lock, flags);
if (x) {
+ wakeup_source_trash(&x->wsource);
list_for_each_entry(phy_bind, &phy_bind_list, list)
if (phy_bind->phy == x)
phy_bind->phy = NULL;
@@ -446,13 +452,32 @@ int usb_bind_phy(const char *dev_name, u8 index,
EXPORT_SYMBOL_GPL(usb_bind_phy);
/**
- * usb_phy_set_event - set event to phy event
+ * usb_phy_set_event - set event to phy event and
+ * hold/temporarily hold wakeupsource
* @x: the phy returned by usb_get_phy();
*
- * This sets event to phy event
+ * This holds per-PHY wakeupsource/timed wakeupsource
*/
void usb_phy_set_event(struct usb_phy *x, unsigned long event)
{
+
x->last_event = event;
+
+ switch (event) {
+ case USB_EVENT_ENUMERATED:
+ __pm_stay_awake(&x->wsource);
+ break;
+
+ case USB_EVENT_NONE:
+ case USB_EVENT_ID:
+ case USB_EVENT_VBUS:
+ case USB_EVENT_CHARGER:
+ __pm_wakeup_event(&x->wsource,
+ msecs_to_jiffies(TEMPORARY_HOLD_TIME));
+ break;
+
+ default:
+ break;
+ }
}
EXPORT_SYMBOL_GPL(usb_phy_set_event);
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 3c713ff..bc58fb8 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -12,6 +12,8 @@
#include
#include
+#define TEMPORARY_HOLD_TIME2000
+
enum usb_phy_interface {
USBPHY_INTERFACE_MODE_UNKNOWN,
USBPHY_INTERFACE_MODE_UTMI,
@@ -89,6 +91,9 @@ struct usb_phy {
/* for notification of usb_phy_events */
struct atomic_notifier_head notifier;
+ /* wakeup source */
+ struct wakeup_sourcewsource;
+
/* to pass extra port status to the root hub */
u16 port_status;
u16 port_change;
--
1.8.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/
[RFC v6 2/3] usb: phy: handle per-PHY connect and disconnect events
From: Todd Poynor
usb: phy: handle per-PHY connect and disconnect events
When usb is connected and enumerated in device mode or when usb is
disconnected,call usb_phy_set_event from phy drivers to handle per-PHY event.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Cc: Arve Hj�nnev�g
Cc: Benoit Goby
Signed-off-by: Todd Poynor
[kiran: Added context to commit message, squished build fixes
from Benoit Goby and Arve Hj�nnev�g, changed wakelocks usage
to wakeupsource, merged Todd's refactoring logic and simplified
the structures and code and addressed community feedback]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/phy-ab8500-usb.c| 15 +++
drivers/usb/phy/phy-gpio-vbus-usb.c | 2 ++
drivers/usb/phy/phy-mv-usb.c| 2 ++
drivers/usb/phy/phy-tahvo.c | 2 ++
4 files changed, 21 insertions(+)
diff --git a/drivers/usb/phy/phy-ab8500-usb.c b/drivers/usb/phy/phy-ab8500-usb.c
index 11ab2c4..d79fa3e 100644
--- a/drivers/usb/phy/phy-ab8500-usb.c
+++ b/drivers/usb/phy/phy-ab8500-usb.c
@@ -447,6 +447,7 @@ static int ab9540_usb_link_status_update(struct ab8500_usb
*ab,
event = UX500_MUSB_NONE;
/* Fallback to default B_IDLE as nothing is connected. */
ab->phy.state = OTG_STATE_B_IDLE;
+ usb_phy_set_event(&ab->phy, USB_EVENT_NONE);
break;
case USB_LINK_ACA_RID_C_NM_9540:
@@ -461,12 +462,14 @@ static int ab9540_usb_link_status_update(struct
ab8500_usb *ab,
ab8500_usb_peri_phy_en(ab);
atomic_notifier_call_chain(&ab->phy.notifier,
UX500_MUSB_PREPARE, &ab->vbus_draw);
+ usb_phy_set_event(&ab->phy, USB_EVENT_ENUMERATED);
}
if (ab->mode == USB_IDLE) {
ab->mode = USB_PERIPHERAL;
ab8500_usb_peri_phy_en(ab);
atomic_notifier_call_chain(&ab->phy.notifier,
UX500_MUSB_PREPARE, &ab->vbus_draw);
+ usb_phy_set_event(&ab->phy, USB_EVENT_ENUMERATED);
}
if (event != UX500_MUSB_RIDC)
event = UX500_MUSB_VBUS;
@@ -502,6 +505,7 @@ static int ab9540_usb_link_status_update(struct ab8500_usb
*ab,
event = UX500_MUSB_CHARGER;
atomic_notifier_call_chain(&ab->phy.notifier,
event, &ab->vbus_draw);
+ usb_phy_set_event(&ab->phy, USB_EVENT_CHARGER);
break;
case USB_LINK_PHYEN_NO_VBUS_NO_IDGND_9540:
@@ -526,6 +530,7 @@ static int ab9540_usb_link_status_update(struct ab8500_usb
*ab,
ab->mode = USB_IDLE;
ab->phy.otg->default_a = false;
ab->vbus_draw = 0;
+ usb_phy_set_event(&ab->phy, USB_EVENT_NONE);
}
}
break;
@@ -585,6 +590,7 @@ static int ab8540_usb_link_status_update(struct ab8500_usb
*ab,
* is connected
*/
ab->phy.state = OTG_STATE_B_IDLE;
+ usb_phy_set_event(&ab->phy, USB_EVENT_NONE);
break;
case USB_LINK_ACA_RID_C_NM_8540:
@@ -598,6 +604,7 @@ static int ab8540_usb_link_status_update(struct ab8500_usb
*ab,
ab8500_usb_peri_phy_en(ab);
atomic_notifier_call_chain(&ab->phy.notifier,
UX500_MUSB_PREPARE, &ab->vbus_draw);
+ usb_phy_set_event(&ab->phy, USB_EVENT_ENUMERATED);
}
if (event != UX500_MUSB_RIDC)
event = UX500_MUSB_VBUS;
@@ -626,6 +633,7 @@ static int ab8540_usb_link_status_update(struct ab8500_usb
*ab,
event = UX500_MUSB_CHARGER;
atomic_notifier_call_chain(&ab->phy.notifier,
event, &ab->vbus_draw);
+ usb_phy_set_event(&ab->phy, USB_EVENT_CHARGER);
break;
case USB_LINK_PHYEN_NO_VBUS_NO_IDGND_8540:
@@ -648,6 +656,7 @@ static int ab8540_usb_link_status_update(struct ab8500_usb
*ab,
ab->mode = USB_IDLE;
ab->phy.otg->default_a = false;
ab->vbus_draw = 0;
+ usb_phy_set_event(&ab->phy, USB_EVENT_NONE);
}
break;
@@ -694,6 +703,7 @@ static int ab8505_usb_link_status_update(struct ab8500_usb
*ab,
* is connected
*/
ab->phy.state = OTG_STATE_B_IDLE;
+ usb_phy_set_event(&ab->phy, USB_EVENT_NONE);
break;
case USB_LINK_ACA_RID_C_NM_8505:
[RFC v6 1/3] usb: phy: introduce usb_phy_set_event interface
From: Todd Poynor
usb: phy: introduce usb_phy_set_event interface
PHY drivers require a generic interface to handle per-PHY events.
usb_phy_set_event interface sets event to phy event.
PHY drivers call this interface for each phy event.
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: Android Kernel Team
Cc: John Stultz
Cc: Sumit Semwal
Cc: Arve Hj�nnev�g
Cc: Benoit Goby
Signed-off-by: Todd Poynor
[kiran: Added context to commit message, squished build fixes
from Benoit Goby and Arve Hj�nnev�g, changed wakelocks usage
to wakeupsource, merged Todd's refactoring logic and simplified
the structures and code and addressed community feedback]
Signed-off-by: Kiran Raparthy
---
drivers/usb/phy/phy.c | 12
include/linux/usb/phy.h | 5 +
2 files changed, 17 insertions(+)
diff --git a/drivers/usb/phy/phy.c b/drivers/usb/phy/phy.c
index 045cd30..2b1039e 100644
--- a/drivers/usb/phy/phy.c
+++ b/drivers/usb/phy/phy.c
@@ -444,3 +444,15 @@ int usb_bind_phy(const char *dev_name, u8 index,
return 0;
}
EXPORT_SYMBOL_GPL(usb_bind_phy);
+
+/**
+ * usb_phy_set_event - set event to phy event
+ * @x: the phy returned by usb_get_phy();
+ *
+ * This sets event to phy event
+ */
+void usb_phy_set_event(struct usb_phy *x, unsigned long event)
+{
+ x->last_event = event;
+}
+EXPORT_SYMBOL_GPL(usb_phy_set_event);
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 353053a..3c713ff 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -210,6 +210,7 @@ extern void usb_put_phy(struct usb_phy *);
extern void devm_usb_put_phy(struct device *dev, struct usb_phy *x);
extern int usb_bind_phy(const char *dev_name, u8 index,
const char *phy_dev_name);
+extern void usb_phy_set_event(struct usb_phy *x, unsigned long event);
#else
static inline struct usb_phy *usb_get_phy(enum usb_phy_type type)
{
@@ -251,6 +252,10 @@ static inline int usb_bind_phy(const char *dev_name, u8
index,
{
return -EOPNOTSUPP;
}
+
+static inline void usb_phy_set_event(struct usb_phy *x, unsigned long event)
+{
+}
#endif
static inline int
--
1.8.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] kdump, x86: report actual value of phys_base in VMCOREINFO
Currently, VMCOREINFO note information reports the virtual address of
phys_base that is assigned to symbol phys_base. But this doesn't make
sense because to refer to value of the phys_base, it's necessary to
get the value of phys_base itself we are now about to refer to.
Userland tools related to kdump such as makedumpfile and crash utility
so far have made some efforts to calculate phys_base from memory
mapping information on a variety of crash dump formats. But there's no
guarantee to keep maintaining it in the future.
This is also useful for crash dump mechanism running outside Linux
kernel such as virtual machine hypervisor such as qemu dump, which
ordinary users use via virsh dump, or ones implemented on vendor
specific firmware. They cannot get phys_base without special mechanism
because phys_base is kernel information.
To get VMCOREINFO in vmcore, it's easy to use strings and grep
commands like this; VMCOREINFO consists of simple string:
$ strings vmcore-3.10.0-121.el7.x86_64 | grep -E ".*VMCOREINFO.*" -A 100
VMCOREINFO
OSRELEASE=3.10.0-121.el7.x86_64
PAGESIZE=4096
...
Similarly, this is also useful to get value of phys_base in kdump 2nd
kernel contained in vmcore using the above-mentioned external crash
dump mechanism; kdump 2nd kernel is an inherently relocated kernel.
This commit doesn't remove VMCOREINFO_SYMBOL(phys_base) line because
makedumpfile refers to it and if removing it, old versions
makedumpfile doesn't work well.
Signed-off-by: HATAYAMA Daisuke
---
arch/x86/kernel/machine_kexec_64.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/machine_kexec_64.c
b/arch/x86/kernel/machine_kexec_64.c
index 4859810..e6d00a4 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -334,6 +334,7 @@ void arch_crash_save_vmcoreinfo(void)
#endif
vmcoreinfo_append_str("KERNELOFFSET=%lx\n",
(unsigned long)&_text - __START_KERNEL);
+ VMCOREINFO_LENGTH(phys_base, phys_base);
}
/* arch-dependent functionality related to kexec file-based syscall */
--
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/
[RFC v6 0/3] usb: phy: hold wakeupsource on usb phy events.
This patch set aims to hold wakeupsource per-PHY on usb connect/disconnect events. First patch introduces usb_phy_set_event which just sets event to phy event. In second patch, phy drivers call usb_phy_set_event for each phy event. In third patch, wakeupsource is held when usb is enumerated in peripheral mode and wakeupsource held temporarily on disconnect event(to allow other parts of the system react to disconnect event). v6: * Break the patch into three sub patches patch 1: Introduce usb_phy_set_event patch 2: Call usb_phy_set_event from phy drivers patch 3: Hold wakeupsource for connect events and temporarily hold wakeupsource for disconnect events. * Include usb_phy_wsource_init and usb_phy_wource_trash functionality in usb_add_phy and usb_remove_phy respectively. v5: * with the new approach,i was able to chnage only 5 phy drivers as mentioned below to use the wakeupsource funtionality. drivers/phy/phy-omap-control.c drivers/usb/phy/phy-ab8500-usb.c drivers/usb/phy/phy-tahvo.c drivers/usb/phy/phy-mv-usb.c drivers/usb/phy/phy-gpio-vbus-usb.c * Notification method not used any more. * introduced usb_phy_set_event in phy.c to hold wakeupsource * introduced usb_phy_wsource_init/usb_phy_wsource_trash in phy.c to initialize/relese per-PHY wakeupsource.These interfaces called from probe/remove functions of phy drivers. * usb_phy_set_event called from phy drivers where usb enumeration event is handled. * usb_phy_set_event expects usb_phy handle where as phy-omap-control.c provides its own type(omap_control_phy), so directly called __pm_stay_awake and� __pm_awake_event from phy-omap-control.c instead of calling usb_phy_set_event. v4: * Temporarily hold wakeupsource patch integrated into main patch. * As per feedback,dropped "enabled" module parameter. * Introduced otgws_otg_usb3_notifications function to handle event notifications from usb3 phy. * Handled wakeupsource initialization,spinlock,registration of notifier block per-PHY. * Updated usb_phy structure. v3: * As per the feedback,no global phy pointer used. * called the one-liner wakeupsource handling calls directly instead of indirect functions implemented in v2. * Removed indirect function get_phy_hook and used usb_get_phy to get the phy handle.. v2: * wakeupsource handling implemeted per-PHY * Implemented wakeupsource handling calls in phy * included Todd's refactoring logic. v1: * changed to "disabled by default" from "enable by default". * Kconfig help text modified * Included better commit text * otgws_nb moved to otg_wakeupsource_init function * Introduced get_phy_hook to handle otgws_xceiv per-PHY Initial RFC: * Included build fix from Benoit Goby and Arve Hj�nnev�g * Removed lock->held field in driver as this mechanism is provided in wakeupsource driver. * wakelock(wl) terminology replaced with wakeup_source(ws). Todd Poynor (3): usb: phy: introduce usb_phy_set_event interface usb: phy: Handle per-PHY event for connect and disconnect events usb: phy: Hold wakeupsource when USB is enumerated in peripheral mode drivers/usb/phy/phy-ab8500-usb.c| 15 +++ drivers/usb/phy/phy-gpio-vbus-usb.c | 2 ++ drivers/usb/phy/phy-mv-usb.c| 2 ++ drivers/usb/phy/phy-tahvo.c | 2 ++ drivers/usb/phy/phy.c | 37 + include/linux/usb/phy.h | 10 ++ 6 files changed, 68 insertions(+) -- 1.8.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 net-next 2/2] r8152: adjust rtl_start_rx
David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, November 12, 2014 1:44 PM
[...]
> What do other USB network drivers do in similar situations?
According to the usbnet.c, it would make sure to submit the
number of min(10, RX_QLEN(dev)) rx buffers. If there are
not enough rx buffers, it schedule a tasklet for next try.
The brief flow is as following.
1. Call open().
- schedule a tasklet.
2. Tasklet is called.
if (dev->rxq.qlen < RX_QLEN(dev)) {
- submit rx buffers util the number of
min(10, RX_QLEN(dev)). If the error
occurs, break the loop.
- If the dev->rxq.qlen < RX_QLEN(dev),
schedule the tasklet.
}
Best Regards,
Hayes
--
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.10 000/123] 3.10.60-stable review
On 11/11/2014 05:16 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.60 release. There are 123 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Nov 14 01:17:00 UTC 2014. Anything received after that time might be too late. Build results: total: 137 pass: 133 fail: 4 Failed builds: powerpc:allmodconfig (binutils 2.23) powerpc:allmodconfig (binutils 2.24) sparc64:allmodconfig xtensa:allmodconfig Qemu tests: total: 27 pass: 27 fail: 0 Same build failures as with 3.14. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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.14 000/203] 3.14.24-stable review
On 11/11/2014 05:14 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.24 release. There are 203 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Nov 14 01:15:14 UTC 2014. Anything received after that time might be too late. Build results: total: 137 pass: 134 fail: 3 Failed builds: powerpc:allmodconfig (binutils 2.23) powerpc:allmodconfig (binutils 2.24) xtensa:allmodconfig Qemu tests: total: 30 pass: 30 fail: 0 Builds fail due to drivers/of/selftest.c: In function 'of_selftest': drivers/of/selftest.c:436:2: error: implicit declaration of function 'of_selftest_property_match_string' [-Werror=implicit-function-declaration] of_selftest_property_match_string(); ^ drivers/of/selftest.c: At top level: drivers/of/selftest.c:135:20: warning: 'of_selftest_property_string' defined but not used [-Wunused-function] static void __init of_selftest_property_string(void) ^ as mentioned earlier. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- 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 3/3] irqchip: dw-apb-ictl: add PM support
This patch adds in support for S2R for dw-apb-ictl irqchip driver.
We can used relaxed variants in the resume hook because there's no DMA
at all here, the device type memory attribute can ensure the operations
order and relaxed version imply compiler barrier.
Signed-off-by: Jisheng Zhang
---
drivers/irqchip/irq-dw-apb-ictl.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c
b/drivers/irqchip/irq-dw-apb-ictl.c
index c136b67..53bb732 100644
--- a/drivers/irqchip/irq-dw-apb-ictl.c
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -50,6 +50,21 @@ static void dw_apb_ictl_handler(unsigned int irq, struct
irq_desc *desc)
chained_irq_exit(chip, desc);
}
+#ifdef CONFIG_PM
+static void dw_apb_ictl_resume(struct irq_data *d)
+{
+ struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
+
+ irq_gc_lock(gc);
+ writel_relaxed(~0, gc->reg_base + ct->regs.enable);
+ writel_relaxed(*ct->mask_cache, gc->reg_base + ct->regs.mask);
+ irq_gc_unlock(gc);
+}
+#else
+#define dw_apb_ictl_resume NULL
+#endif /* CONFIG_PM */
+
static int __init dw_apb_ictl_init(struct device_node *np,
struct device_node *parent)
{
@@ -127,13 +142,17 @@ static int __init dw_apb_ictl_init(struct device_node *np,
gc->reg_base = iobase;
gc->chip_types[0].regs.mask = APB_INT_MASK_L;
+ gc->chip_types[0].regs.enable = APB_INT_ENABLE_L;
gc->chip_types[0].chip.irq_mask = irq_gc_mask_set_bit;
gc->chip_types[0].chip.irq_unmask = irq_gc_mask_clr_bit;
+ gc->chip_types[0].chip.irq_resume = dw_apb_ictl_resume;
if (nrirqs > 32) {
gc->chip_types[1].regs.mask = APB_INT_MASK_H;
+ gc->chip_types[1].regs.enable = APB_INT_ENABLE_H;
gc->chip_types[1].chip.irq_mask = irq_gc_mask_set_bit;
gc->chip_types[1].chip.irq_unmask = irq_gc_mask_clr_bit;
+ gc->chip_types[1].chip.irq_resume = dw_apb_ictl_resume;
}
irq_set_handler_data(irq, gc);
--
2.1.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/
[PATCH v2 2/3] irqchip: dw-apb-ictl: enable IRQ_GC_MASK_CACHE_PER_TYPE
The irq_chip_type instances have separate mask registers, so we need to
enable IRQ_GC_MASK_CACHE_PER_TYPE to actually handle separate mask registers.
Signed-off-by: Jisheng Zhang
Acked-by: Sebastian Hesselbarth
---
drivers/irqchip/irq-dw-apb-ictl.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/irqchip/irq-dw-apb-ictl.c
b/drivers/irqchip/irq-dw-apb-ictl.c
index fcc3385..c136b67 100644
--- a/drivers/irqchip/irq-dw-apb-ictl.c
+++ b/drivers/irqchip/irq-dw-apb-ictl.c
@@ -115,6 +115,7 @@ static int __init dw_apb_ictl_init(struct device_node *np,
ret = irq_alloc_domain_generic_chips(domain, 32, (nrirqs > 32) ? 2 : 1,
np->name, handle_level_irq, clr, 0,
+IRQ_GC_MASK_CACHE_PER_TYPE |
IRQ_GC_INIT_MASK_CACHE);
if (ret) {
pr_err("%s: unable to alloc irq domain gc\n", np->full_name);
--
2.1.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/
[PATCH v2 1/3] irqchip: dw-apb-ictl: always use use {readl|writel}_relaxed
There's no DMA at all, the device type memory attribute can ensure the operations order and relaxed version imply compiler barrier, so we are safe to use relaxed version to improve the performance a bit. Signed-off-by: Jisheng Zhang Acked-by: Sebastian Hesselbarth --- drivers/irqchip/irq-dw-apb-ictl.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/irqchip/irq-dw-apb-ictl.c b/drivers/irqchip/irq-dw-apb-ictl.c index 31e231e..fcc3385 100644 --- a/drivers/irqchip/irq-dw-apb-ictl.c +++ b/drivers/irqchip/irq-dw-apb-ictl.c @@ -94,16 +94,16 @@ static int __init dw_apb_ictl_init(struct device_node *np, */ /* mask and enable all interrupts */ - writel(~0, iobase + APB_INT_MASK_L); - writel(~0, iobase + APB_INT_MASK_H); - writel(~0, iobase + APB_INT_ENABLE_L); - writel(~0, iobase + APB_INT_ENABLE_H); + writel_relaxed(~0, iobase + APB_INT_MASK_L); + writel_relaxed(~0, iobase + APB_INT_MASK_H); + writel_relaxed(~0, iobase + APB_INT_ENABLE_L); + writel_relaxed(~0, iobase + APB_INT_ENABLE_H); - reg = readl(iobase + APB_INT_ENABLE_H); + reg = readl_relaxed(iobase + APB_INT_ENABLE_H); if (reg) nrirqs = 32 + fls(reg); else - nrirqs = fls(readl(iobase + APB_INT_ENABLE_L)); + nrirqs = fls(readl_relaxed(iobase + APB_INT_ENABLE_L)); domain = irq_domain_add_linear(np, nrirqs, &irq_generic_chip_ops, NULL); -- 2.1.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: [PATCHv12 0/3] power_supply: Introduce power supply charging driver
Sebastian, I would appreciate if you could share your plans on this patch?. As you agreed on the IRC session, can you push this patch to staging? Meanwhile we will work to close the TODOs captured in the IRC session (http://elektranox.org/battery.txt) -Jenny > v1: Introduced feature as a framework within power supply class driver with > separate files for battid framework and charging framework > v2: Fixed review comments, moved macros and inline functions to power_supply.h > v3: Moved the feature as a separate driver, combined battid framework and > charging framework inside the power supply charging driver. Moved > charger specific properties to power_supply_charger.h and plugged the > driver with power supply subsystem using power_supply_notifier > introduced in my previous patch. Also a sample charger chip driver > (bq24261) patch added to give more idea on the psy charging driver > usage > v4: Fixed review comments, no major design changes. > v5: Fixed makefile inconsistencies, removed unused pdata callbacks > v6: Fixed nested loops, commenting style > v7: added kerneldocs for structs and minor fixes > v8: used msecs_to_jiffies instead of HZ directly, modified Kconfig help text > for POWER_SUPPLY_CHARGING_ALGO_PSE > v9: Removed string lookups, static cable initialization > v10: Fixed bug in algorithm lookup > v11: Few variable name changes for better readability > v12: Enabled polling and RTC wakeup which is supported in charger-manager as > suggested by Sebastian. Fixed review comments from Sebastian and Pavel > > Jenny TC (3): > power_supply: Introduce generic psy charging driver > power_supply: Introduce PSE compliant algorithm > power_supply: bq24261 charger driver > > Documentation/power/power_supply_charger.txt | 349 +++ > drivers/power/Kconfig| 33 + > drivers/power/Makefile |3 + > drivers/power/bq24261_charger.c | 1348 > ++ > drivers/power/charging_algo_pse.c| 217 + > drivers/power/power_supply_charger.c | 1186 ++ > drivers/power/power_supply_charger.h | 225 + > drivers/power/power_supply_core.c|3 + > include/linux/power/bq24261-charger.h| 25 + > include/linux/power/power_supply_charger.h | 374 +++ > include/linux/power_supply.h | 161 +++ > 11 files changed, 3924 insertions(+) > create mode 100644 Documentation/power/power_supply_charger.txt > create mode 100644 drivers/power/bq24261_charger.c > create mode 100644 drivers/power/charging_algo_pse.c > create mode 100644 drivers/power/power_supply_charger.c > create mode 100644 drivers/power/power_supply_charger.h > create mode 100644 include/linux/power/bq24261-charger.h > create mode 100644 include/linux/power/power_supply_charger.h > > -- > 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build warnings after merge of the mips tree
Hi Ralf,
After merging the mips tree, today's linux-next build (powerpc64
allnoconfig) produced these warnings:
In file included from fs/compat_binfmt_elf.c:145:0:
fs/binfmt_elf.c: In function 'load_elf_binary':
fs/binfmt_elf.c:718:13: warning: passing argument 1 of 'arch_elf_pt_proc' from
incompatible pointer type
retval = arch_elf_pt_proc(&loc->elf_ex, elf_ppnt,
^
In file included from include/linux/elfcore-compat.h:4:0,
from fs/compat_binfmt_elf.c:20:
include/linux/elf.h:81:19: note: expected 'struct elf64_hdr *' but argument is
of type 'struct elf32_hdr *'
static inline int arch_elf_pt_proc(struct elfhdr *ehdr,
^
In file included from fs/compat_binfmt_elf.c:145:0:
fs/binfmt_elf.c:718:13: warning: passing argument 2 of 'arch_elf_pt_proc' from
incompatible pointer type
retval = arch_elf_pt_proc(&loc->elf_ex, elf_ppnt,
^
In file included from include/linux/elfcore-compat.h:4:0,
from fs/compat_binfmt_elf.c:20:
include/linux/elf.h:81:19: note: expected 'struct elf64_phdr *' but argument is
of type 'struct elf32_phdr *'
static inline int arch_elf_pt_proc(struct elfhdr *ehdr,
^
In file included from fs/compat_binfmt_elf.c:145:0:
fs/binfmt_elf.c:747:14: warning: passing argument 1 of 'arch_elf_pt_proc' from
incompatible pointer type
retval = arch_elf_pt_proc(&loc->interp_elf_ex,
^
In file included from include/linux/elfcore-compat.h:4:0,
from fs/compat_binfmt_elf.c:20:
include/linux/elf.h:81:19: note: expected 'struct elf64_hdr *' but argument is
of type 'struct elf32_hdr *'
static inline int arch_elf_pt_proc(struct elfhdr *ehdr,
^
In file included from fs/compat_binfmt_elf.c:145:0:
fs/binfmt_elf.c:747:14: warning: passing argument 2 of 'arch_elf_pt_proc' from
incompatible pointer type
retval = arch_elf_pt_proc(&loc->interp_elf_ex,
^
In file included from include/linux/elfcore-compat.h:4:0,
from fs/compat_binfmt_elf.c:20:
include/linux/elf.h:81:19: note: expected 'struct elf64_phdr *' but argument is
of type 'struct elf32_phdr *'
static inline int arch_elf_pt_proc(struct elfhdr *ehdr,
^
In file included from fs/compat_binfmt_elf.c:145:0:
fs/binfmt_elf.c:761:11: warning: passing argument 1 of 'arch_check_elf' from
incompatible pointer type
retval = arch_check_elf(&loc->elf_ex, !!interpreter, &arch_state);
^
In file included from include/linux/elfcore-compat.h:4:0,
from fs/compat_binfmt_elf.c:20:
include/linux/elf.h:104:19: note: expected 'struct elf64_hdr *' but argument is
of type 'struct elf32_hdr *'
static inline int arch_check_elf(struct elfhdr *ehdr, bool has_interp,
^
Probably introduced by commit 7b76fe94c0e4 ("binfmt_elf: allow arch
code to examine PT_LOPROC ... PT_HIPROC headers") and maybe the
preceeding commits as well.
binfmt_elf.c is included by compat_binfmt_elf.c after defining some
things to build the compat versions of things.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgp7lUzmupNKF.pgp
Description: OpenPGP digital signature
Re: [PATCH 3.17 000/319] 3.17.3-stable review
On 11/11/2014 05:12 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.17.3 release. There are 319 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Nov 14 01:07:52 UTC 2014. Anything received after that time might be too late. Build results: total: 133 pass: 132 fail: 1 Failed builds: avr32:atngw100mkii_evklcd101_defconfig Qemu tests: total: 30 pass: 30 fail: 0 The failing build is due to a link error: lib/lib.a(vsprintf.o): In function `vsnprintf': vsprintf.c:(.text+0x16dc): relocation truncated to fit: R_AVR32_16N_PCREL against symbol `_ctype' defined in .text section in lib/lib.a(ctype.o) which has been observed on and off for the last few releases. Details are available at http://server.roeck-us.net:8010/builder. Guenter -- 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 0/3] irqchip: dw-apb-ictl: IRQ_GC_MASK_CACHE_PER_TYPE and PM support
These patches try to improve dw-apb-ictl irqchip driver a bit.
The first patch improves the performance a bit -- use the relaxed version
The two dw-apb-ictl's irq_chip_type instances have separate mask registers, so
the second patch enables IRQ_GC_MASK_CACHE_PER_TYPE.
The last patch adds suspend/resume support to the driver.
Tested on Marvell BG2Q-DMP board.
Changes in v2:
- Add Sebastian's Acks
- Update the first commit as Sebastian and Thomas suggested
- Add into commit log summary of the discussion why relaxed variants can be
used
Jisheng Zhang (3):
irqchip: dw-apb-ictl: always use use {readl|writel}_relaxed
irqchip: dw-apb-ictl: enable IRQ_GC_MASK_CACHE_PER_TYPE
irqchip: dw-apb-ictl: add PM support
drivers/irqchip/irq-dw-apb-ictl.c | 32 ++--
1 file changed, 26 insertions(+), 6 deletions(-)
--
2.1.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 3.10 000/123] 3.10.60-stable review
On Tue, Nov 11, 2014 at 09:21:48PM -0800, Guenter Roeck wrote: > On 11/11/2014 05:16 PM, Greg Kroah-Hartman wrote: > >This is the start of the stable review cycle for the 3.10.60 release. > >There are 123 patches in this series, all will be posted as a response > >to this one. If anyone has any issues with these being applied, please > >let me know. > > > >Responses should be made by Fri Nov 14 01:17:00 UTC 2014. > >Anything received after that time might be too late. > > > > As an early heads up, I see some builds failing in 3.10 and 3.14 with > > drivers/of/selftest.c: In function 'of_selftest': > drivers/of/selftest.c:224:2: error: implicit declaration of function > 'of_selftest_property_match_string' [-Werror=implicit-function-declaration] > of_selftest_property_match_string(); > ^ > drivers/of/selftest.c: At top level: > drivers/of/selftest.c:129:20: warning: 'of_selftest_property_string' defined > but not used [-Wunused-function] > static void __init of_selftest_property_string(void) > ^ > > Not surprising, since commit 'of: Fix overflow bug in string property > parsing functions' replaces the now missing function with the defined > but unused function, apparently without changing the caller. > Oddly enough, the referenced upstream commit _does_ replace the > function name for both caller and callee. Crap, I took the "ignore the rejects" too literally when applying that patch, let me go rework it and see if I can fix it up. thanks for letting me know. 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/
✔ Alert ! Your PayPal Account Will Be limited PP1366
-- Reminder: We need your help -- We emailed you a little while ago to ask for your help resolving an issue with your account. What's the problem? Until this issue is resolved, you'll be able to log in to your PayPal account but you might not be able to add money to it or use some of your account features. You must follow this link to resolve your issue: (For some security reasons. Your account will be disabled next 24 Hours) you can paste this link into your web browser: http://paypal.com.au.security-check.aquaempire.com.sg Notice : In case you find the link disabled . Use COPY-PAST in a new Secure Window to reactivate. Before we can offer you certain products and services, federal regulations require that we collect specific information to verify your identity. This information includes your name, address, date of birth, and National Tax ID or Social Security Number. We haven't been able to verify your identity using the information you provided, so we need some additional documentation from you. Case ID Number: PP-003-462-000-607 How you can help It's usually pretty easy to take care of things like this. Most of the time, we just need a little more information about your account or latest transactions. Please log in to your account and go to the Resolution Center to find out what you need to do. If we don't hear from you soon, we may limit what you can do with your account until the issue is resolved. Sincerely, PayPal -- Help Center: http://paypal.com.au.security-check.aquaempire.com.sg This email was sent by an automated system, so if you reply, nobody will see it. To get in touch with us, log in to your account and click "Contact Us" at the bottom of any page. Copyright © 2014 PayPal, Inc. All rights reserved. PayPal is located at 2211 N. First St., San Jose, CA 95131. PayPal Email ID PP1366 - ef5987d0fa716 -- 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: Future of NOHZ full/isolation development (was Re: [NOHZ] Remove scheduler_tick_max_deferment)
On 11 November 2014 22:45, Frederic Weisbecker wrote:
> Here is a summarized list:
>
> * Unbound workqueues affinity (to housekeeper)
> * Unbound timers affinity (to housekeeper)
> * 1 Hz residual scheduler tick offlining to housekeeper
> * Fix some scheduler accounting that don't even work with 1 Hz: cpu load
> accounting, rt_scale, load balancing, etc...
> * Lighten the syscall path and get rid of cputime accounting + RCU hooks
> for people who want isolation + fast syscalls and faults.
> * Work on non-affinable workqueues
> * Work on non-affinable timers
> * ...
+ spurious interrupts with NOHZ_FULL on all architectures which break isolation
but doesn't get caught with traces. Can be observed with this:
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 481fa54..91d490d 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -1244,7 +1244,8 @@ void hrtimer_interrupt(struct clock_event_device *dev)
{
struct hrtimer_cpu_base *cpu_base = this_cpu_ptr(&hrtimer_bases);
ktime_t expires_next, now, entry_time, delta;
- int i, retries = 0;
+ int i, retries = 0, count = 0;
+ static int total_spurious;
BUG_ON(!cpu_base->hres_active);
cpu_base->nr_events++;
@@ -1304,10 +1305,14 @@ void hrtimer_interrupt(struct clock_event_device *dev)
break;
}
+ count++;
__run_hrtimer(timer, &basenow);
}
}
+ if (!count)
+ pr_err("%s: Totalspurious: %d\n", __func__,
++total_spurious);
+
/*
* Store the new expiry value so the migration code can verify
* against 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 10/10] PCI/MSI: Remove useless bus->msi assignment
On 2014/11/12 12:24, Bjorn Helgaas wrote:
> On Mon, Oct 27, 2014 at 03:48:47PM +0800, Yijing Wang wrote:
>> Thierry introduced MSI chip(now renamed to MSI controller)
>> framework to associate MSI chip and PCI bus in arm.
>> Other platforms still use its own arch MSI functions to
>> support MSI capability. Thierry introduced the bus->msi
>> assignment to make child bus can inherit bus->msi from the parent.
>> But in fact, drivers which used MSI chip always associate
>> MSI chip and PCI bus by add .add_bus() in arm PCI host bridge
>> drivers. Now we have saved MSI chip in pci_sys_data.
>> We can remove this bus->msi assignment safely.
>>
>> Signed-off-by: Yijing Wang
>> CC: Thierry Reding
>> CC: Thomas Petazzoni
>> ---
>> drivers/pci/msi.c |5 -
>> drivers/pci/probe.c |1 -
>> 2 files changed, 0 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> index f085f7f..27b6a54 100644
>> --- a/drivers/pci/msi.c
>> +++ b/drivers/pci/msi.c
>> @@ -37,11 +37,6 @@ struct msi_controller * __weak
>> pcibios_msi_controller(struct pci_bus *bus)
>>
>> struct msi_controller *pci_msi_controller(struct pci_bus *bus)
>> {
>> -struct msi_controller *ctrl = bus->msi;
>> -
>> -if (ctrl)
>> -return ctrl;
>> -
>> return pcibios_msi_controller(bus);
>> }
>>
>> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
>> index 5ed9930..4b18bf2 100644
>> --- a/drivers/pci/probe.c
>> +++ b/drivers/pci/probe.c
>> @@ -682,7 +682,6 @@ static struct pci_bus *pci_alloc_child_bus(struct
>> pci_bus *parent,
>>
>> child->parent = parent;
>> child->ops = parent->ops;
>> -child->msi = parent->msi;
>
> Does this mean that struct pci_bus.msi is now unused? If not, where is it
> still used?
Yes, now all arm platforms save msi_chip in pci_sys_data, no one uses it again,
actually, no platform/pcihost never use it, because all arm pci host drivers use
pcibios_add_bus() to associate it and pci bus before. Remove it is safety.
Thanks!
Yijing.
>
>> child->sysdata = parent->sysdata;
>> child->bus_flags = parent->bus_flags;
>>
>> --
>> 1.7.1
>>
>
> .
>
--
Thanks!
Yijing
--
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] of/base: Fix PowerPC address parsing hack
We have a historical hack that treats missing ranges properties as the
equivalent of an empty one. This is needed for ancient PowerMac "bad"
device-trees, and shouldn't be enabled for any other PowerPC platform,
otherwise we get some nasty layout of devices in sysfs or even
duplication when a set of otherwise identically named devices is
created multiple times under a different parent node with no ranges
property.
This fix is needed for the PowerNV i2c busses to be exposed properly
and will fix a number of other embedded cases.
Signed-off-by: Benjamin Herrenschmidt
CC:
---
diff --git a/drivers/of/address.c b/drivers/of/address.c
index e371825..e37f017 100644
--- a/drivers/of/address.c
+++ b/drivers/of/address.c
@@ -7,6 +7,10 @@
#include
#include
+#ifdef CONFIG_PPC
+#include
+#endif
+
/* Max address size we deal with */
#define OF_MAX_ADDR_CELLS 4
#define OF_CHECK_ADDR_COUNT(na)((na) > 0 && (na) <= OF_MAX_ADDR_CELLS)
@@ -428,12 +432,13 @@ static int of_translate_one(struct device_node *parent,
struct of_bus *bus,
* This code is only enabled on powerpc. --gcl
*/
ranges = of_get_property(parent, rprop, &rlen);
-#if !defined(CONFIG_PPC)
+#if defined(CONFIG_PPC)
+ if (!machine_is(powermac))
+#endif /* defined(CONFIG_PPC) */
if (ranges == NULL) {
- pr_err("OF: no ranges; cannot translate\n");
+ pr_debug("OF: no ranges; cannot translate\n");
return 1;
}
-#endif /* !defined(CONFIG_PPC) */
if (ranges == NULL || rlen == 0) {
offset = of_read_number(addr, na);
memset(addr, 0, pna * 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/
Re: [PATCH net-next 2/2] r8152: adjust rtl_start_rx
From: Hayes Wang Date: Wed, 12 Nov 2014 05:23:03 + > David Miller [mailto:da...@davemloft.net] >> Sent: Wednesday, November 12, 2014 1:13 PM > [...] >> I really want to know why you are spending so much effort on this. >> >> Is there a real situation that happened very often, which you >> diagnosed in detail, and therefore you want to address? > > No. I just consider the possible situation and want to > make the driver better. If you think this is unnecessary, > I would remove it. What do other USB network drivers do in similar situations? -- 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/
[PULL] params fix
The following changes since commit 206c5f60a3d902bc4b56dab2de3e88de5eb06108: Linux 3.18-rc4 (2014-11-09 14:55:29 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux.git for you to fetch changes up to 3438cf549d2f3ee8e52c82acc8e2a9710ac21a5b: param: fix crash on bad kernel arguments (2014-11-11 17:03:19 +1030) Daniel Thompson (1): param: fix crash on bad kernel arguments init/main.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 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] Params: Fix parse_args() return code checking
Richard Weinberger writes: > parse_args() returns beside of NULL also ERR_PTR(). Thanks, already queued in my fixes branch. Cheers, Rusty. -- 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: [PATCHv2 0/2] ARM: dts: Fix the number of DMA channels for Exynos3250/4
Dear Kukjin, Please ignore this patchset because this patchset are wrong. Best Regards, Chanwoo Choi On 11/12/2014 11:50 AM, Chanwoo Choi wrote: > This patch fix minor issuse to correct the number of DMA channels for > Exynos3250 and Exynos4 series. The PL330 DMA of Exynos3250/Exynos4 support > 16 channels simultaneously but, PL330 DMA driver don't use 'dma-channels' > property directly. This patchset fix the correct information > of Exynos3250/Exynos4's PL330 DMA simply. > > Changes from v1: > - Fix the nubmer for DMA channesl for Exynos4415 > > Chanwoo Choi (2): > ARM: dts: Fix the number of DMA channels for Exynos3250 > ARM: dts: Fix the number of DMA channels for Exynos4 > > arch/arm/boot/dts/exynos3250.dtsi | 4 ++-- > arch/arm/boot/dts/exynos4.dtsi| 4 ++-- > arch/arm/boot/dts/exynos4415.dtsi | 4 ++-- > 3 files changed, 6 insertions(+), 6 deletions(-) > -- 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 0/4] staging: panel: Module parameters clean-up
On Wed, Nov 12, 2014 at 02:08:05AM +0100, Mariusz Gorski wrote: > This small set of patches (although it also could be a single patch...) > rearranges groups of defines, redefines and module parameter declarations, > so that they always appear in the same order defined by Kconfig, which > makes it more pleasant to read and understand. It's a preparation for > a bigger clean-up of current init code. > > Mariusz Gorski (4): > staging: panel: Reorder initial DEFAULT_* defines > staging: panel: Reorder DEFAULT_* values redefines > staging: panel: Reorder module parameter declarations > staging: panel: Use better names for two defined values Whole patchset Acked-By: Willy Tarreau BTW Mariusz, please use this e-mail address instead of the meta-x.org one in the future. Thanks, Willy -- 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 net-next 2/2] r8152: adjust rtl_start_rx
David Miller [mailto:da...@davemloft.net] > Sent: Wednesday, November 12, 2014 1:13 PM [...] > I really want to know why you are spending so much effort on this. > > Is there a real situation that happened very often, which you > diagnosed in detail, and therefore you want to address? No. I just consider the possible situation and want to make the driver better. If you think this is unnecessary, I would remove it. Best Regards, Hayes -- 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.10 000/123] 3.10.60-stable review
On 11/11/2014 05:16 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.60 release. There are 123 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Fri Nov 14 01:17:00 UTC 2014. Anything received after that time might be too late. As an early heads up, I see some builds failing in 3.10 and 3.14 with drivers/of/selftest.c: In function 'of_selftest': drivers/of/selftest.c:224:2: error: implicit declaration of function 'of_selftest_property_match_string' [-Werror=implicit-function-declaration] of_selftest_property_match_string(); ^ drivers/of/selftest.c: At top level: drivers/of/selftest.c:129:20: warning: 'of_selftest_property_string' defined but not used [-Wunused-function] static void __init of_selftest_property_string(void) ^ Not surprising, since commit 'of: Fix overflow bug in string property parsing functions' replaces the now missing function with the defined but unused function, apparently without changing the caller. Oddly enough, the referenced upstream commit _does_ replace the function name for both caller and callee. Guenter -- 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 net-next 2/2] r8152: adjust rtl_start_rx
From: Hayes Wang Date: Wed, 12 Nov 2014 05:07:40 + > How about that when a error occurs, add the remaining rx > to the list without submission? Then, the remianing rx > could be re-submitted later, and the rtl_start_rx() could > be completed as soon as possible. I really want to know why you are spending so much effort on this. Is there a real situation that happened very often, which you diagnosed in detail, and therefore you want to address? -- 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 net-next 2/2] r8152: adjust rtl_start_rx
David Miller [mailto:da...@davemloft.net]
> Sent: Wednesday, November 12, 2014 10:51 AM
[...]
> Ok, but if we are looping here in rtl_start_rx() and r8152_submit_rx()
> fails due to a memory allocation failure, there is nothing which is
> going to make such a memory allocation succeed in the next iteration
> of the loop.
>
> Unless you can prove that often it can succeed after an initial
> failure, this is just wasted work and in fact making it take longer
> for the system to reclaim memory when under pressure because these
> extra iterations are completely wasted cpu work.
How about that when a error occurs, add the remaining rx
to the list without submission? Then, the remianing rx
could be re-submitted later, and the rtl_start_rx() could
be completed as soon as possible.
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 0a30fd3..3273e3d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1991,14 +1991,35 @@ static void rxdy_gated_en(struct r8152 *tp, bool enable)
static int rtl_start_rx(struct r8152 *tp)
{
+ struct list_head rx_queue;
int i, ret = 0;
INIT_LIST_HEAD(&tp->rx_done);
for (i = 0; i < RTL8152_MAX_RX; i++) {
INIT_LIST_HEAD(&tp->rx_info[i].list);
ret = r8152_submit_rx(tp, &tp->rx_info[i], GFP_KERNEL);
- if (ret)
+ if (ret) {
+ i++;
break;
+ }
+ }
+
+ INIT_LIST_HEAD(&rx_queue);
+ for (; i < RTL8152_MAX_RX; i++) {
+ struct rx_agg *agg = &tp->rx_info[i];
+ struct urb *urb = agg->urb;
+
+ INIT_LIST_HEAD(&agg->list);
+ urb->actual_length = 0;
+ list_add_tail(&agg->list, &rx_queue);
+ }
+
+ if (!list_empty(&rx_queue)) {
+ unsigned long flags;
+
+ spin_lock_irqsave(&tp->rx_lock, flags);
+ list_splice_tail(&rx_queue, &tp->rx_done);
+ spin_unlock_irqrestore(&tp->rx_lock, flags);
}
return ret;
Best Regards,
Hayes
--
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 v18 4/5] ARM: dts: add main Thermal info to rk3288
This patch is depend on rk3288-thermal.dtsi,or
it will compile error.
If for some reason we are unable to shut it down
in orderly fashion (kernel is stuck holding a lock or
similar), then hardware TSHUT will reset it.
If the temperature over a period of time High,over 95C
the resulting TSHUT gave CRU module,let it reset
the entire chip,or via GPIO give PMIC.
Signed-off-by: Caesar Wang
Reviewed-by: Dmitry Torokhov
---
arch/arm/boot/dts/rk3288.dtsi | 27 +++
1 file changed, 27 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 9cd269a..c7a2691 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include "skeleton.dtsi"
/ {
@@ -66,6 +67,7 @@
216000 90
126000 90
>;
+ #cooling-cells = <2>; /* min followed by max */
clock-latency = <4>;
clocks = <&cru ARMCLK>;
};
@@ -346,6 +348,25 @@
status = "disabled";
};
+ thermal-zones {
+ #include "rk3288-thermal.dtsi"
+ };
+
+ tsadc: tsadc@ff28 {
+ compatible = "rockchip,rk3288-tsadc";
+ reg = <0xff28 0x100>;
+ interrupts = ;
+ clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+ resets = <&cru SRST_TSADC>;
+ reset-names = "tsadc-apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&otp_out>;
+ #thermal-sensor-cells = <1>;
+ rockchip,hw-tshut-temp = <95000>;
+ status = "disabled";
+ };
+
usb_host0_ehci: usb@ff50 {
compatible = "generic-ehci";
reg = <0xff50 0x100>;
@@ -965,6 +986,12 @@
};
};
+ tsadc {
+ otp_out: otp-out {
+ rockchip,pins = <0 10 RK_FUNC_1
&pcfg_pull_none>;
+ };
+ };
+
pwm0 {
pwm0_pin: pwm0-pin {
rockchip,pins = <7 0 RK_FUNC_1 &pcfg_pull_none>;
--
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 v18 3/5] ARM: dts: add RK3288 Thermal data
This patch changes a dtsi file to contain the thermal data
on RK3288 and later SoCs. This data will
enable a thermal shutdown over 90C.
Signed-off-by: Caesar Wang
Reviewed-by: Dmitry Torokhov
---
arch/arm/boot/dts/rk3288-thermal.dtsi | 78 +++
1 file changed, 78 insertions(+)
create mode 100644 arch/arm/boot/dts/rk3288-thermal.dtsi
diff --git a/arch/arm/boot/dts/rk3288-thermal.dtsi
b/arch/arm/boot/dts/rk3288-thermal.dtsi
new file mode 100644
index 000..a8a5ea7
--- /dev/null
+++ b/arch/arm/boot/dts/rk3288-thermal.dtsi
@@ -0,0 +1,78 @@
+/*
+ * Device Tree Source for RK3288 SoC thermal
+ *
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include
+
+reserve_thermal: reserve_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <5000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <&tsadc 0>;
+
+};
+
+cpu_thermal: cpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <5000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <&tsadc 1>;
+
+ trips {
+ cpu_alert0: cpu_alert0 {
+ temperature = <7>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ cpu_crit: cpu_crit {
+ temperature = <9>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
+
+gpu_thermal: gpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <5000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <&tsadc 2>;
+
+ trips {
+ gpu_alert0: gpu_alert0 {
+ temperature = <7>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ gpu_crit: gpu_crit {
+ temperature = <9>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&gpu_alert0>;
+ cooling-device =
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+};
--
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 v18 2/5] thermal: rockchip: add driver for thermal
Thermal is TS-ADC Controller module supports
user-defined mode and automatic mode.
User-defined mode refers,TSADC all the control signals entirely by
software writing to register for direct control.
Automaic mode refers to the module automatically poll TSADC output,
and the results were checked.If you find that the temperature High
in a period of time,an interrupt is generated to the processor
down-measures taken;If the temperature over a period of time High,
the resulting TSHUT gave CRU module,let it reset the entire chip,
or via GPIO give PMIC.
Signed-off-by: zhaoyifeng
Signed-off-by: Caesar Wang
Reviewed-by: Dmitry Torokhov
---
drivers/thermal/Kconfig| 10 +
drivers/thermal/Makefile | 1 +
drivers/thermal/rockchip_thermal.c | 721 +
3 files changed, 732 insertions(+)
create mode 100644 drivers/thermal/rockchip_thermal.c
diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index ef5587f..527632d 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -133,6 +133,16 @@ config SPEAR_THERMAL
Enable this to plug the SPEAr thermal sensor driver into the Linux
thermal framework.
+config ROCKCHIP_THERMAL
+ tristate "Rockchip thermal driver"
+ depends on ARCH_ROCKCHIP
+ depends on RESET_CONTROLLER
+ help
+ Rockchip thermal driver provides support for Temperature sensor
+ ADC (TS-ADC) found on Rockchip SoCs. It supports one critical
+ trip point. Cpufreq is used as the cooling device and will throttle
+ CPUs when the Temperature crosses the passive trip point.
+
config RCAR_THERMAL
tristate "Renesas R-Car thermal driver"
depends on ARCH_SHMOBILE || COMPILE_TEST
diff --git a/drivers/thermal/Makefile b/drivers/thermal/Makefile
index 31e232f..21da0a8 100644
--- a/drivers/thermal/Makefile
+++ b/drivers/thermal/Makefile
@@ -19,6 +19,7 @@ thermal_sys-$(CONFIG_CPU_THERMAL) += cpu_cooling.o
# platform thermal drivers
obj-$(CONFIG_SPEAR_THERMAL)+= spear_thermal.o
+obj-$(CONFIG_ROCKCHIP_THERMAL) += rockchip_thermal.o
obj-$(CONFIG_RCAR_THERMAL) += rcar_thermal.o
obj-$(CONFIG_KIRKWOOD_THERMAL) += kirkwood_thermal.o
obj-y += samsung/
diff --git a/drivers/thermal/rockchip_thermal.c
b/drivers/thermal/rockchip_thermal.c
new file mode 100644
index 000..524e3d6
--- /dev/null
+++ b/drivers/thermal/rockchip_thermal.c
@@ -0,0 +1,721 @@
+/*
+ * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * If the temperature over a period of time High,
+ * the resulting TSHUT gave CRU module,let it reset the entire chip,
+ * or via GPIO give PMIC.
+ */
+enum tshut_mode {
+ TSHUT_MODE_CRU = 0,
+ TSHUT_MODE_GPIO,
+};
+
+/**
+ * the system Temperature Sensors tshut(tshut) polarity
+ * the bit 8 is tshut polarity.
+ * 0: low active, 1: high active
+ */
+enum tshut_polarity {
+ TSHUT_LOW_ACTIVE = 0,
+ TSHUT_HIGH_ACTIVE,
+};
+
+/**
+ * The system has three Temperature Sensors. channel 0 is reserved,
+ * channel 1 is for CPU, and channel 2 is for GPU.
+ */
+enum sensor_id {
+ SENSOR_CPU = 1,
+ SENSOR_GPU,
+};
+
+struct rockchip_tsadc_chip {
+ /* The hardware-controlled tshut property */
+ long tshut_temp;
+ enum tshut_mode tshut_mode;
+ enum tshut_polarity tshut_polarity;
+
+ /* Chip-wide methods */
+ void (*initialize)(void __iomem *reg, enum tshut_polarity p);
+ void (*irq_ack)(void __iomem *reg);
+ void (*control)(void __iomem *reg, bool on);
+
+ /* Per-sensor methods */
+ int (*get_temp)(int chn, void __iomem *reg, long *temp);
+ void (*set_alarm_temp)(int chn, void __iomem *reg, long temp);
+ void (*set_tshut_temp)(int chn, void __iomem *reg, long temp);
+ void (*set_tshut_mode)(int chn, void __iomem *reg, enum tshut_mode m);
+};
+
+struct rockchip_thermal_sensor {
+ struct rockchip_thermal_data *thermal;
+ struct thermal_zone_device *tzd;
+ enum sensor_id id;
+};
+
+#define NUM_SENSORS2 /* Ignore unused sensor 0 */
+
+struct rockchip_thermal_data {
+ const struct rockchip_tsadc_chip *chip;
+ struct platform_device *pdev;
+ struct reset_control *reset;
+
+ struct rockchip_thermal_sensor sensors[NUM_SENSORS];
+
+ struct clk *clk;
+ struct clk *pclk;
+
[PATCH v18 0/5] Rockchip soc thermal driver
This series patchs tested on rk3288 SDK board and pinky-v1,v2 board. I believe the driver can be used on the rk3288-evb board. Add this driver, The system will shutdown when the thermal temperture over 100C.If for some reason we are unable to shut it down in orderly fashion (kernel is stuck holding a lock or similar) then hardware will reset it. This series patchs depend on patch by Mikko Perttunen adding support for hardware-supported trip points. It allows us to reduce polling frequency while still being able to react when we cross the tripping point. See https://lkml.org/lkml/2014/6/27/76 otherwise thermal_zone_of_sensor_register() will compile error, e.g: CC [M] drivers/thermal/rockchip_thermal.o drivers/thermal/rockchip_thermal.c: In function `rockchip_thermal_register_sensor': drivers/thermal/rockchip_thermal.c:482:7: error: too many arguments to function `thermal_zone_of_sensor_register' rockchip_thermal_set_trips); Changes in v18: * address comments from Eduardo Valentin and Dmitry Torokhov.. - we need reset tsadc-controller before enable tsadc auto mode, when we add the thermal function in coreboot,we always enable tsadc controller. So we need reset tsadc-controller to avoid the TSADC is abnormal. - put the document behind the driver. - Tested on pinky1,2,jeffy board,we will fix cooling-map temperature from 80C to 70C, critical temperature from 100C to 90C. Changes in v17: * address comments from Heiko Stubner and . - rename the tshut property - the critiacal temperature only indeed 100C when add the cooling map, it's for the more secure,fix the temperature from 120C to 100C. Changes in v16: * address comments from Dmitry Torokhov. - add thermal->chip->control(thermal->regs, false) in remove() - adjust TSHUT in resume(). Changes in v15: * address comments from Dmitry Torokhov. - enable TSHUT move into rk_tsadcv2_tshut_temp(). - drop the id argument in rk_tsadcv2_control(). Changes in v14: * address comments from Dmitry Torokhov. - adjust-alarm-rate-depending-on-clock. - 0001-rockchip-thermal-do-not-register-cpufreq-cooling-dev. Changes in v13: - add cooling-maps for cpu-thermal. - put tshut polarity in device tree. Changes in v12: * address comments from Dmitry Torokhov and Vladimir Zapolskiy. - split-sensor-handling. - rename-rockchip_tsadc_platform_data. Changes in v11: * address comments from Vladimir Zapolskiy. - fix cpufreq_cooling_unregister() to put in correct position. - fix "data->chn",at least can get valid Tsensor temp. Changes in v10: * address comments from Doug Anderson. - fix TSHUT polarity,ensure support TSHUT. - add the decription for rk_tsadcv2_initialize(). Changes in v9: * address comments from Dmitry Torokhov. - fix some style be defined - remove some unused code. - clk_disable_unprepare->clk_disable in suspend() Changes in v8: * address comments from Dmitry Torokhov and Doug Anderson. - add three Teperture Sensors. - support CRU and GPIO reset chip. - rename rk3xxx-cpu-thermal.dtsi as rk3288-thermal.dtsi - alarm-temp via set_trips() callback - remove "reset-gpios" Changes in v7: - fix get data->clk=0 when in probe() function. - fix some style code. - modify dts,main add rk3xxx-cpu-thermal.dtsi Changes in v6: * address comments from Tomeu Vizoso. - use thermal's generic framework. Changes in v5: * address comments from Eduardo Valentin,rui.zhang and Heiko Stubner: - with BIT() macro - manage clocks in suspend/resume. - license is fixed as GPLv2. - #include "thermal_core.h"->#include - use the generic trip-points.the hw-shut-temp isn't generic trip-points. - The method of binding and unbinding be fixed. - The pin-name tsadc->otp_out Changes in v4: * address comments from Jonathan Cameron,huangtao and zhaoyifeng: - this series thermal driver still be put in driver/thermal/ - modify the thermal driver description. Changes in v3:(add dts configure) * address comments from Dmitry Torokhov and Arnd Bergmann: - fix clock-names in rockchip-thermal.txt - remove rockchip_thermal_control() in rockchip_set_mode() - fix some code style. - add dts configure. Changes in v2: * address comments from Heiko Stubner: - fix dt-bindings in rockchip-thermal.txt - remove Author mark - rename TSADC_XXX->TSADCV2_XXX,it eill ready to merge compatible other SoCs. - fix a identation - remove clk_set_rate(),it's no necessary. - fix the SIMPLE_DEV_PM_OPS() function style. Caesar Wang (5): thermal: rockchip: a
[PATCH v18 5/5] ARM: dts: enable Thermal on rk3288-evb board
when a thermal temperature over TSHUT.Default to via
CRU reset the entire chip on rk3288-evb Board,
TSHUT is low active on rk3288-evb board.
Signed-off-by: Caesar Wang
Reviewed-by: Dmitry Torokhov
---
arch/arm/boot/dts/rk3288-evb.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288-evb.dtsi
b/arch/arm/boot/dts/rk3288-evb.dtsi
index cb83cea..3e067dd 100644
--- a/arch/arm/boot/dts/rk3288-evb.dtsi
+++ b/arch/arm/boot/dts/rk3288-evb.dtsi
@@ -148,6 +148,12 @@
status = "okay";
};
+&tsadc {
+ rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU 1:GPIO */
+ rockchip,hw-tshut-polarity = <0>; /* tshut polarity 0:LOW 1:HIGH */
+ status = "okay";
+};
+
&pinctrl {
backlight {
bl_en: bl-en {
--
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 v18 1/5] dt-bindings: document Rockchip thermal
This add the necessary binding documentation for the thermal
found on Rockchip SoCs
Signed-off-by: zhaoyifeng
Signed-off-by: Caesar Wang
Reviewed-by: Dmitry Torokhov
---
.../bindings/thermal/rockchip-thermal.txt | 68 ++
1 file changed, 68 insertions(+)
create mode 100644
Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
diff --git a/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
new file mode 100644
index 000..ef802de
--- /dev/null
+++ b/Documentation/devicetree/bindings/thermal/rockchip-thermal.txt
@@ -0,0 +1,68 @@
+* Temperature Sensor ADC (TSADC) on rockchip SoCs
+
+Required properties:
+- compatible : "rockchip,rk3288-tsadc"
+- reg : physical base address of the controller and length of memory mapped
+ region.
+- interrupts : The interrupt number to the cpu. The interrupt specifier format
+ depends on the interrupt controller.
+- clocks : Must contain an entry for each entry in clock-names.
+- clock-names : Shall be "tsadc" for the converter-clock, and "apb_pclk" for
+ the peripheral clock.
+- resets : Must contain an entry for each entry in reset-names.
+ See ../reset/reset.txt for details.
+- reset-names : Must include the name "tsadc-apb".
+- #thermal-sensor-cells : Should be 1. See ./thermal.txt for a description.
+- rockchip,hw-tshut-temp : The hardware-controlled shutdown temperature value.
+- rockchip,hw-tshut-mode : The hardware-controlled shutdown mode 0:CRU 1:GPIO.
+- rockchip,hw-tshut-polarity : The hardware-controlled active polarity 0:LOW
+ 1:HIGH.
+
+Exiample:
+tsadc: tsadc@ff28 {
+ compatible = "rockchip,rk3288-tsadc";
+ reg = <0xff28 0x100>;
+ interrupts = ;
+ clocks = <&cru SCLK_TSADC>, <&cru PCLK_TSADC>;
+ clock-names = "tsadc", "apb_pclk";
+ resets = <&cru SRST_TSADC>;
+ reset-names = "tsadc-apb";
+ pinctrl-names = "default";
+ pinctrl-0 = <&otp_out>;
+ #thermal-sensor-cells = <1>;
+ rockchip,hw-tshut-temp = <95000>;
+ rockchip,hw-tshut-mode = <0>;
+ rockchip,hw-tshut-polarity = <0>;
+};
+
+Example: referring to thermal sensors:
+thermal-zones {
+ cpu_thermal: cpu_thermal {
+ polling-delay-passive = <1000>; /* milliseconds */
+ polling-delay = <5000>; /* milliseconds */
+
+ /* sensor ID */
+ thermal-sensors = <&tsadc 1>;
+
+ trips {
+ cpu_alert0: cpu_alert {
+ temperature = <7>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "passive";
+ };
+ cpu_crit: cpu_crit {
+ temperature = <9>; /* millicelsius */
+ hysteresis = <2000>; /* millicelsius */
+ type = "critical";
+ };
+ };
+
+ cooling-maps {
+ map0 {
+ trip = <&cpu_alert0>;
+ cooling-device =
+ <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
+ };
+ };
+ };
+};
--
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: [PATCH v4 4/6] hw_random: fix unregister race.
On Mon, Nov 10, 2014 at 09:47:27PM +0800, Herbert Xu wrote: > On Mon, Nov 03, 2014 at 11:56:24PM +0800, Amos Kong wrote: > > > > @@ -98,6 +99,8 @@ static inline void cleanup_rng(struct kref *kref) > > > > if (rng->cleanup) > > rng->cleanup(rng); > > You need a compiler barrier here to prevent reordering. Michael Büsch pointed out that we should actually have a memory barrier here. I thought we didn't need it because I was only worried about the code in my original complaint. However, expecting driver writers to use correct synchronisation primitives is surely asking too much. So let's add an smp_wmb() here to ensure all side-effects of cleanup is visible. Thanks, -- 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] Btrfs: ctree: reduce args where only fs_info used
This patch is part of a larger project to cleanup
btrfs's internal usage of struct btrfs_root. Many
functions take btrfs_root only to grab a pointer
to fs_info.
This causes programmers to ponder which root can
be passed. Since only the fs_info is read affected
functions can accept any root, except this is only
obvious upon inspection.
This patch reduces the specificty of such functions
to accept the fs_info directly.
This patch does not address the two functions in
ctree.c (insert_ptr, and split_item) which only
use root for BUG_ONs in ctree.c
This patch affects the following functions:
1) fixup_low_keys
2) btrfs_set_item_key_safe
Signed-off-by: Daniel Dressler
---
fs/btrfs/ctree.c | 27 +++
fs/btrfs/ctree.h | 3 ++-
fs/btrfs/file-item.c | 2 +-
fs/btrfs/file.c | 8
4 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index 19bc616..db5a60f 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -3139,7 +3139,8 @@ again:
* higher levels
*
*/
-static void fixup_low_keys(struct btrfs_root *root, struct btrfs_path *path,
+static void fixup_low_keys(struct btrfs_fs_info *fs_info,
+ struct btrfs_path *path,
struct btrfs_disk_key *key, int level)
{
int i;
@@ -3150,7 +3151,7 @@ static void fixup_low_keys(struct btrfs_root *root,
struct btrfs_path *path,
if (!path->nodes[i])
break;
t = path->nodes[i];
- tree_mod_log_set_node_key(root->fs_info, t, tslot, 1);
+ tree_mod_log_set_node_key(fs_info, t, tslot, 1);
btrfs_set_node_key(t, key, tslot);
btrfs_mark_buffer_dirty(path->nodes[i]);
if (tslot != 0)
@@ -3164,7 +3165,8 @@ static void fixup_low_keys(struct btrfs_root *root,
struct btrfs_path *path,
* This function isn't completely safe. It's the caller's responsibility
* that the new key won't break the order
*/
-void btrfs_set_item_key_safe(struct btrfs_root *root, struct btrfs_path *path,
+void btrfs_set_item_key_safe(struct btrfs_fs_info *fs_info,
+struct btrfs_path *path,
struct btrfs_key *new_key)
{
struct btrfs_disk_key disk_key;
@@ -3186,7 +3188,7 @@ void btrfs_set_item_key_safe(struct btrfs_root *root,
struct btrfs_path *path,
btrfs_set_item_key(eb, &disk_key, slot);
btrfs_mark_buffer_dirty(eb);
if (slot == 0)
- fixup_low_keys(root, path, &disk_key, 1);
+ fixup_low_keys(fs_info, path, &disk_key, 1);
}
/*
@@ -3944,7 +3946,7 @@ static noinline int __push_leaf_left(struct
btrfs_trans_handle *trans,
clean_tree_block(trans, root, right);
btrfs_item_key(right, &disk_key, 0);
- fixup_low_keys(root, path, &disk_key, 1);
+ fixup_low_keys(root->fs_info, path, &disk_key, 1);
/* then fixup the leaf pointer in the path */
if (path->slots[0] < push_items) {
@@ -4181,6 +4183,7 @@ static noinline int split_leaf(struct btrfs_trans_handle
*trans,
int mid;
int slot;
struct extent_buffer *right;
+ struct btrfs_fs_info *fs_info = root->fs_info;
int ret = 0;
int wret;
int split;
@@ -4284,10 +4287,10 @@ again:
btrfs_set_header_backref_rev(right, BTRFS_MIXED_BACKREF_REV);
btrfs_set_header_owner(right, root->root_key.objectid);
btrfs_set_header_level(right, 0);
- write_extent_buffer(right, root->fs_info->fsid,
+ write_extent_buffer(right, fs_info->fsid,
btrfs_header_fsid(), BTRFS_FSID_SIZE);
- write_extent_buffer(right, root->fs_info->chunk_tree_uuid,
+ write_extent_buffer(right, fs_info->chunk_tree_uuid,
btrfs_header_chunk_tree_uuid(right),
BTRFS_UUID_SIZE);
@@ -4310,7 +4313,7 @@ again:
path->nodes[0] = right;
path->slots[0] = 0;
if (path->slots[1] == 0)
- fixup_low_keys(root, path, &disk_key, 1);
+ fixup_low_keys(fs_info, path, &disk_key, 1);
}
btrfs_mark_buffer_dirty(right);
return ret;
@@ -4626,7 +4629,7 @@ void btrfs_truncate_item(struct btrfs_root *root, struct
btrfs_path *path,
btrfs_set_disk_key_offset(&disk_key, offset + size_diff);
btrfs_set_item_key(leaf, &disk_key, slot);
if (slot == 0)
- fixup_low_keys(root, path, &disk_key, 1);
+ fixup_low_keys(root->fs_info, path, &disk_key, 1);
}
item = btrfs_item_nr(slot);
@@ -4727,7 +4730,7 @@ void setup_items_for_insert(struct btrfs_root *root,
struct btrfs_path *path,
if (path->slots[0] == 0) {
bt
Re: [PATCH v4 3/6] hw_random: use reference counts on each struct hwrng.
Amos Kong writes:
> From: Rusty Russell
>
> current_rng holds one reference, and we bump it every time we want
> to do a read from it.
>
> This means we only hold the rng_mutex to grab or drop a reference,
> so accessing /sys/devices/virtual/misc/hw_random/rng_current doesn't
> block on read of /dev/hwrng.
>
> Using a kref is overkill (we're always under the rng_mutex), but
> a standard pattern.
>
> This also solves the problem that the hwrng_fillfn thread was
> accessing current_rng without a lock, which could change (eg. to NULL)
> underneath it.
>
> v4: decrease last reference for triggering the cleanup
This doesn't make any sense:
> +static void drop_current_rng(void)
> +{
> + struct hwrng *rng = current_rng;
> +
> + BUG_ON(!mutex_is_locked(&rng_mutex));
> + if (!current_rng)
> + return;
> +
> + /* release current_rng reference */
> + kref_put(¤t_rng->ref, cleanup_rng);
> + current_rng = NULL;
> +
> + /* decrease last reference for triggering the cleanup */
> + kref_put(&rng->ref, cleanup_rng);
> +}
Why would it drop the refcount twice? This doesn't make sense.
Hmm, because you added kref_init, which initializes the reference count
to 1, you created this bug.
Leave out the kref_init, and let it naturally be 0 (until, and if, it
becomes current_rng). Add a comment if you want.
Thanks,
Rusty.
--
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 4/6] hw_random: fix unregister race.
Amos Kong writes:
> From: Rusty Russell
>
> The previous patch added one potential problem: we can still be
> reading from a hwrng when it's unregistered. Add a wait for zero
> in the hwrng_unregister path.
>
> v4: add cleanup_done flag to insure that cleanup is done
That's a bit weird. The usual pattern would be to hold a reference
until we're actually finished, but this reference is a bit weird.
We hold the mutex across cleanup, so we could grab that but we have to
take care sleeping inside wait_event, otherwise Peter will have to fix
my code again :)
AFAICT the wake_woken() stuff isn't merged yet, so your patch will
have to do for now.
> @@ -98,6 +99,8 @@ static inline void cleanup_rng(struct kref *kref)
>
> if (rng->cleanup)
> rng->cleanup(rng);
> + rng->cleanup_done = true;
> + wake_up_all(&rng_done);
> }
>
> static void set_current_rng(struct hwrng *rng)
> @@ -536,6 +539,11 @@ void hwrng_unregister(struct hwrng *rng)
> kthread_stop(hwrng_fill);
> } else
> mutex_unlock(&rng_mutex);
> +
> + /* Just in case rng is reading right now, wait. */
> + wait_event(rng_done, rng->cleanup_done &&
> +atomic_read(&rng->ref.refcount) == 0);
> +
The atomic_read() isn't necessary here.
However, you should probably init cleanup_done in hwrng_register().
(Probably noone does unregister then register, but let's be clear).
Thanks,
Rusty.
> }
> EXPORT_SYMBOL_GPL(hwrng_unregister);
>
> diff --git a/include/linux/hw_random.h b/include/linux/hw_random.h
> index c212e71..7832e50 100644
> --- a/include/linux/hw_random.h
> +++ b/include/linux/hw_random.h
> @@ -46,6 +46,7 @@ struct hwrng {
> /* internal. */
> struct list_head list;
> struct kref ref;
> + bool cleanup_done;
> };
>
> /** Register a new Hardware Random Number Generator driver. */
> --
> 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/
[PATCH v3 01/13] crypto: Documentation - crypto API high level spec
The design of the kernel crypto API as well as hints to program with the kernel crypto API are given. The documentation contains: * design aspects of crypto API * develper specific hints * references to the API function description * source code examples CC: Marek Vasut Signed-off-by: Stephan Mueller --- Documentation/DocBook/crypto-API.tmpl | 1253 + 1 file changed, 1253 insertions(+) create mode 100644 Documentation/DocBook/crypto-API.tmpl diff --git a/Documentation/DocBook/crypto-API.tmpl b/Documentation/DocBook/crypto-API.tmpl new file mode 100644 index 000..c763d30 --- /dev/null +++ b/Documentation/DocBook/crypto-API.tmpl @@ -0,0 +1,1253 @@ + +http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd"; []> + + + + Linux Kernel Crypto API + + + +Stephan +Mueller + + + smuel...@chronox.de + + + + +Marek +Vasut + + + ma...@denx.de + + + + + + + 2014 + Stephan Mueller + + + + + + This documentation 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. + + + + This program is distributed in the hope that it will be + useful, but WITHOUT ANY WARRANTY; without even the implied + warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + See the GNU General Public License for more details. + + + + You should have received a copy of the GNU General Public + License along with this program; if not, write to the Free + Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, + MA 02111-1307 USA + + + + For more details see the file COPYING in the source + distribution of Linux. + + + + + + + + Kernel Crypto API Interface Specification + + Introduction + + + The kernel crypto API offers a rich set of cryptographic ciphers as + well as other data transformation mechanisms and methods to invoke + these. This document contains a description of the API and provides + example code. + + + + To understand and properly use the kernel crypto API a brief + explanation of its structure is given. Based on the architecture, + the API can be separated into different components. Following the + architecture specification, hints to developers of ciphers are + provided. Pointers to the API function call documentation are + given at the end. + + + + The kernel crypto API refers to all algorithms as "transformations". + Therefore, a cipher handle variable usually has the name "tfm". + Besides cryptographic operations, the kernel crypto API also knows + compression transformations and handles them the same way as ciphers. + + + + The kernel crypto API serves the following entity types: + + + + consumers requesting cryptographic services + + + data transformation implementations (typically ciphers) + that can be called by consumers using the kernel crypto + API + + + + + + This specification is intended for consumers of the kernel crypto + API as well as for developers implementing ciphers. This API + specification, however, does not discusses all API calls available + to data transformation implementations (i.e. implementations of + ciphers and other transformations (such as CRC or even compression + algorithms) that can register with the kernel crypto API). + + + + Note: The terms "transformation" and cipher algorithm are used + interchangably. + + + + Terminology + + The transformation implementation is an actual code or interface + to hardware which implements a certain transformation with precisely + defined behavior. + + + + The transformation object (TFM) is an instance of a transformation + implementation. There can be multiple transformation objects + associated with a single transformation implementation. Each of + those transformation objects is held by a crypto API consumer or + another transformation. Transformation object is allocated when a + crypto API consumer requests a transformation implementation. + The consumer is then provided with a structure, which contains + a transformation object (TFM). + + + + The structure that contains transformation objects may also be + referred to as a "cipher handle". Such a cipher handle is always + subject to the following phases that are reflected in the API calls + applicable to such a cipher handle: + + + + + Initialization of a cipher handle. + + + Execution of all intended cipher operations applicable + for the handle where the cipher handle mus
[PATCH v3 00/13] crypto: Documentation of kernel crypto API
Hi, The following patch set adds documentation files under Documentation/crypto/ covering the high-level description of the API. In addition, it contains source code comments added to the header files of the kernel crypto API documenting the API functions. The documentation is provided in a DocBook whose output can be reviewed at: http://www.chronox.de/crypto-API/index.html Changes v2: * Split out the user space documentation into separate document including the user space example code * Change the license of the user space interface code to match the license of the code that I used as a reference. * Addition of a precise pointer to the user space interface code reference code. * Add a missing memset(0) to the user space example code. * Move the API function call documentation into the header files in the hope for a better maintainability. * Merge the developer-related documentation from Marek Vasut Changes v3: * Replaced user space example code with reference to libkcapi as a reference implementation and a simple library hiding the Netlink details. * Converted all kernel documentation into a basis for a DocBook as suggested by Jonathan Corbet * Included (hopefully) all suggestions provided over the last two weeks Stephan Mueller (13): crypto: Documentation - crypto API high level spec crypto: Documentation - compile crypto API spec crypto: Documentation - userspace interface spec crypto: Documentation - RNG API documentation crypto: Documentation - hash data structures crypto: Documentation - AHASH API documentation crypto: Documentation - SHASH API documentation crypto: Documentation - cipher data structures crypto: Documentation - ABLKCIPHER API documentation crypto: Documentation - AEAD API documentation crypto: Documentation - BLKCIPHER API documentation crypto: Documentation - CIPHER API documentation crypto: Documentation - HASH API documentation Documentation/DocBook/Makefile|2 +- Documentation/DocBook/crypto-API.tmpl | 1253 + Documentation/crypto/crypto-API-userspace.txt | 205 include/crypto/hash.h | 487 ++ include/crypto/rng.h | 80 ++ include/linux/crypto.h| 1099 +- 6 files changed, 3122 insertions(+), 4 deletions(-) create mode 100644 Documentation/DocBook/crypto-API.tmpl create mode 100644 Documentation/crypto/crypto-API-userspace.txt -- 2.1.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 v3 07/13] crypto: Documentation - SHASH API documentation
The API function calls exported by the kernel crypto API for SHASHes
to be used by consumers are documented.
Signed-off-by: Stephan Mueller
---
include/crypto/hash.h | 164 ++
1 file changed, 164 insertions(+)
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index b2c193a..3d66e8b 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -583,6 +583,33 @@ static inline void ahash_request_set_crypt(struct
ahash_request *req,
req->result = result;
}
+/**
+ * DOC: Synchronous Message Digest API
+ *
+ * The synchronous message digest API is used with the ciphers of type
+ * CRYPTO_ALG_TYPE_SHASH (listed as type "shash" in /proc/crypto)
+ *
+ * The message digest API is able to maintain state information for the
+ * caller.
+ *
+ * The synchronous message digest API can store user-related context in in its
+ * shash_desc request data structure.
+ */
+
+/**
+ * crypto_alloc_shash() - allocate message digest handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * message digest cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Allocate a cipher handle for a message digest. The returned &struct
+ * crypto_shash is the cipher handle that is required for any subsequent
+ * API invocation for that message digest.
+ *
+ * Return: allocated cipher handle in case of success; IS_ERR() is true in case
+ *of an error, PTR_ERR() returns the error code.
+ */
struct crypto_shash *crypto_alloc_shash(const char *alg_name, u32 type,
u32 mask);
@@ -591,6 +618,10 @@ static inline struct crypto_tfm *crypto_shash_tfm(struct
crypto_shash *tfm)
return &tfm->base;
}
+/**
+ * crypto_free_shash() - zeroize and free the message digest handle
+ * @tfm: cipher handle to be freed
+ */
static inline void crypto_free_shash(struct crypto_shash *tfm)
{
crypto_destroy_tfm(tfm, crypto_shash_tfm(tfm));
@@ -602,6 +633,15 @@ static inline unsigned int crypto_shash_alignmask(
return crypto_tfm_alg_alignmask(crypto_shash_tfm(tfm));
}
+/**
+ * crypto_shash_blocksize() - obtain block size for cipher
+ * @tfm: cipher handle
+ *
+ * The block size for the message digest cipher referenced with the cipher
+ * handle is returned.
+ *
+ * Return: block size of cipher
+ */
static inline unsigned int crypto_shash_blocksize(struct crypto_shash *tfm)
{
return crypto_tfm_alg_blocksize(crypto_shash_tfm(tfm));
@@ -617,6 +657,15 @@ static inline struct shash_alg *crypto_shash_alg(struct
crypto_shash *tfm)
return __crypto_shash_alg(crypto_shash_tfm(tfm)->__crt_alg);
}
+/**
+ * crypto_shash_digestsize() - obtain message digest size
+ * @tfm: cipher handle
+ *
+ * The size for the message digest created by the message digest cipher
+ * referenced with the cipher handle is returned.
+ *
+ * Return: digest size of cipher
+ */
static inline unsigned int crypto_shash_digestsize(struct crypto_shash *tfm)
{
return crypto_shash_alg(tfm)->digestsize;
@@ -642,6 +691,21 @@ static inline void crypto_shash_clear_flags(struct
crypto_shash *tfm, u32 flags)
crypto_tfm_clear_flags(crypto_shash_tfm(tfm), flags);
}
+/**
+ * crypto_shash_descsize() - obtain the operational state size
+ * @tfm: cipher handle
+ *
+ * The size of the operational state the cipher needs during operation is
+ * returned for the hash referenced with the cipher handle. This size is
+ * required to calculate the memory requirements to allow the caller allocating
+ * sufficient memory for operational state.
+ *
+ * The operational state is defined with struct shash_desc where the size of
+ * that data structure is to be calculated as
+ * sizeof(struct shash_desc) + crypto_shash_descsize(alg)
+ *
+ * Return: size of the operational state
+ */
static inline unsigned int crypto_shash_descsize(struct crypto_shash *tfm)
{
return tfm->descsize;
@@ -652,29 +716,129 @@ static inline void *shash_desc_ctx(struct shash_desc
*desc)
return desc->__ctx;
}
+/**
+ * crypto_shash_setkey() - set key for message digest
+ * @tfm: cipher handle
+ * @key: buffer holding the key
+ * @keylen: length of the key in bytes
+ *
+ * The caller provided key is set for the keyed message digest cipher. The
+ * cipher handle must point to a keyed message digest cipher in order for this
+ * function to succeed.
+ *
+ * Return: 0 if the setting of the key was successful; < 0 if an error occurred
+ */
int crypto_shash_setkey(struct crypto_shash *tfm, const u8 *key,
unsigned int keylen);
+
+/**
+ * crypto_shash_digest() - calculate message digest for buffer
+ * @desc: see crypto_shash_final()
+ * @data: see crypto_shash_update()
+ * @len: see crypto_shash_update()
+ * @out: see crypto_shash_final()
+ *
+ * This function is a "short-hand" for the function calls of crypto_shash_init,
+ * crypto_shash_update
[PATCH v3 05/13] crypto: Documentation - hash data structures
The hash data structures needed to be filled in by cipher developers are
documented.
Signed-off-by: Stephan Mueller
---
include/crypto/hash.h | 95 +++
1 file changed, 95 insertions(+)
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index 74b13ec..bf458fc 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -17,6 +17,28 @@
struct crypto_ahash;
+/**
+ * DOC: Message Digest Algorithm Definitions
+ *
+ * These data structures define modular message digest algorithm
+ * implementations, managed via crypto_register_ahash(),
+ * crypto_register_shash(), crypto_unregister_ahash() and
+ * crypto_unregister_shash().
+ */
+
+/**
+ * struct hash_alg_common - define properties of message digest
+ * @digestsize: Size of the result of the transformation. A buffer of this size
+ * must be available to the @final and @finup calls, so they can
+ * store the resulting hash into it. For various predefined sizes,
+ * search include/crypto/ using
+ * git grep _DIGEST_SIZE include/crypto.
+ * @statesize: Size of the block for partial state of the transformation. A
+ *buffer of this size must be passed to the @export function as it
+ *will save the partial state of the transformation into it. On the
+ *other side, the @import function will load the state from a
+ *buffer of this size as well.
+ */
struct hash_alg_common {
unsigned int digestsize;
unsigned int statesize;
@@ -37,6 +59,62 @@ struct ahash_request {
void *__ctx[] CRYPTO_MINALIGN_ATTR;
};
+/**
+ * struct ahash_alg - asynchronous message digest definition
+ * @init: Initialize the transformation context. Intended only to initialize
the
+ * state of the HASH transformation at the begining. This shall fill in
+ * the internal structures used during the entire duration of the whole
+ * transformation. No data processing happens at this point.
+ * @update: Push a chunk of data into the driver for transformation. This
+ *function actually pushes blocks of data from upper layers into the
+ *driver, which then passes those to the hardware as seen fit. This
+ *function must not finalize the HASH transformation by calculating the
+ *final message digest as this only adds more data into the
+ *transformation. This function shall not modify the transformation
+ *context, as this function may be called in parallel with the same
+ *transformation object. Data processing can happen synchronously
+ *[SHASH] or asynchronously [AHASH] at this point.
+ * @final: Retrieve result from the driver. This function finalizes the
+ *transformation and retrieves the resulting hash from the driver and
+ *pushes it back to upper layers. No data processing happens at this
+ *point.
+ * @finup: Combination of @update and @final. This function is effectively a
+ *combination of @update and @final calls issued in sequence. As some
+ *hardware cannot do @update and @final separately, this callback was
+ *added to allow such hardware to be used at least by IPsec. Data
+ *processing can happen synchronously [SHASH] or asynchronously [AHASH]
+ *at this point.
+ * @digest: Combination of @init and @update and @final. This function
+ * effectively behaves as the entire chain of operations, @init,
+ * @update and @final issued in sequence. Just like @finup, this was
+ * added for hardware which cannot do even the @finup, but can only do
+ * the whole transformation in one run. Data processing can happen
+ * synchronously [SHASH] or asynchronously [AHASH] at this point.
+ * @setkey: Set optional key used by the hashing algorithm. Intended to push
+ * optional key used by the hashing algorithm from upper layers into
+ * the driver. This function can store the key in the transformation
+ * context or can outright program it into the hardware. In the former
+ * case, one must be careful to program the key into the hardware at
+ * appropriate time and one must be careful that .setkey() can be
+ * called multiple times during the existence of the transformation
+ * object. Not all hashing algorithms do implement this function as it
+ * is only needed for keyed message digests. SHAx/MDx/CRCx do NOT
+ * implement this function. HMAC(MDx)/HMAC(SHAx)/CMAC(AES) do implement
+ * this function. This function must be called before any other of the
+ * @init, @update, @final, @finup, @digest is called. No data
+ * processing happens at this point.
+ * @export: Export partial state of the transformation. This function dumps the
+ * entire state of the ongoing transformation into a provided block of
+ * data so it can be @import
[PATCH v3 02/13] crypto: Documentation - compile crypto API spec
Add the crypto API documentation into the DocBook Makefile to allow it being compiled Signed-off-by: Stephan Mueller --- Documentation/DocBook/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile index bec0665..9c7d92d 100644 --- a/Documentation/DocBook/Makefile +++ b/Documentation/DocBook/Makefile @@ -15,7 +15,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \ 80211.xml debugobjects.xml sh.xml regulator.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \ tracepoint.xml drm.xml media_api.xml w1.xml \ - writing_musb_glue_layer.xml + writing_musb_glue_layer.xml crypto-API.xml include Documentation/DocBook/media/Makefile -- 2.1.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 v3 03/13] crypto: Documentation - userspace interface spec
The userspace interface of the kernel crypto API is documented with
* a general explanation
* a discussion of the memory in-place operation
* the description of the message digest API
* the description of the symmetric cipher API
The documentation refers to libkcapi as a working example on how to use
the kernel crypto API from user space.
Signed-off-by: Stephan Mueller
---
Documentation/crypto/crypto-API-userspace.txt | 205 ++
1 file changed, 205 insertions(+)
create mode 100644 Documentation/crypto/crypto-API-userspace.txt
diff --git a/Documentation/crypto/crypto-API-userspace.txt
b/Documentation/crypto/crypto-API-userspace.txt
new file mode 100644
index 000..ac619cd
--- /dev/null
+++ b/Documentation/crypto/crypto-API-userspace.txt
@@ -0,0 +1,205 @@
+Introduction
+
+
+The concepts of the kernel crypto API visible to kernel space is fully
+applicable to the user space interface as well. Therefore, the kernel crypto
API
+high level discussion for the in-kernel use cases applies here as well.
+
+The major difference, however, is that user space can only act as a consumer
+and never as a provider of a transformation or cipher algorithm.
+
+The following covers the user space interface exported by the kernel crypto
+API. A working example of this description is libkcapi that can be obtained
from
+[1]. That library can be used by user space applications that require
+cryptographic services from the kernel.
+
+Some details of the in-kernel kernel crypto API aspects do not
+apply to user space, however. This includes the difference between synchronous
+and asynchronous invocations. The user space API call is fully synchronous.
+In addition, only a subset of all cipher types are available as documented
+below.
+
+
+User space API general remarks
+==
+
+The kernel crypto API is accessible from user space. Currently, the following
+ciphers are accessible:
+
+ * Message digest including keyed message digest (HMAC, CMAC)
+
+ * Symmetric ciphers
+
+Note, AEAD ciphers are currently not supported via the symmetric cipher
+interface.
+
+The interface is provided via Netlink using the type AF_ALG. In addition, the
+setsockopt option type is SOL_ALG. In case the user space header files do not
+export these flags yet, use the following macros:
+
+#ifndef AF_ALG
+#define AF_ALG 38
+#endif
+#ifndef SOL_ALG
+#define SOL_ALG 279
+#endif
+
+A cipher is accessed with the same name as done for the in-kernel API calls.
+This includes the generic vs. unique naming schema for ciphers as well as the
+enforcement of priorities for generic names.
+
+To interact with the kernel crypto API, a Netlink socket must be created by
+the user space application. User space invokes the cipher operation with the
+send/write system call family. The result of the cipher operation is obtained
+with the read/recv system call family.
+
+The following API calls assume that the Netlink socket descriptor is already
+opened by the user space application and discusses only the kernel crypto API
+specific invocations.
+
+To initialize a Netlink interface, the following sequence has to be performed
+by the consumer:
+
+ 1. Create a socket of type AF_ALG with the struct sockaddr_alg parameter
+ specified below for the different cipher types.
+
+ 2. Invoke bind with the socket descriptor
+
+ 3. Invoke accept with the socket descriptor. The accept system call
+ returns a new file descriptor that is to be used to interact with
+ the particular cipher instance. When invoking send/write or recv/read
+ system calls to send data to the kernel or obtain data from the
+ kernel, the file descriptor returned by accept must be used.
+
+In-place cipher operation
+=
+
+Just like the in-kernel operation of the kernel crypto API, the user space
+interface allows the cipher operation in-place. That means that the input
buffer
+used for the send/write system call and the output buffer used by the read/recv
+system call may be one and the same. This is of particular interest for
+symmetric cipher operations where a copying of the output data to its final
+destination can be avoided.
+
+If a consumer on the other hand wants to maintain the plaintext and the
+ciphertext in different memory locations, all a consumer needs to do is to
+provide different memory pointers for the encryption and decryption operation.
+
+Message digest API
+==
+
+The message digest type to be used for the cipher operation is selected when
+invoking the bind syscall. bind requires the caller to provide a filled
+struct sockaddr data structure. This data structure must be filled as follows:
+
+struct sockaddr_alg sa = {
+ .salg_family = AF_ALG,
+ .salg_type = "hash", /* this selects the hash logic in the kernel */
+ .salg_name = "sha1" /* this is the cipher name */
+};
+
+The salg_type value "has
[PATCH v3 09/13] crypto: Documentation - ABLKCIPHER API documentation
The API function calls exported by the kernel crypto API for
asynchronous block ciphers to be used by consumers are documented.
Signed-off-by: Stephan Mueller
---
include/linux/crypto.h | 206 +
1 file changed, 206 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 752360e..39c8fc6 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -821,6 +821,50 @@ static inline u32 crypto_skcipher_mask(u32 mask)
return mask;
}
+/**
+ * DOC: Asynchronous Block Cipher API
+ *
+ * Asynchronous block cipher API is used with the ciphers of type
+ * CRYPTO_ALG_TYPE_ABLKCIPHER (listed as type "ablkcipher" in /proc/crypto).
+ *
+ * Asynchronous cipher operations imply that the function invocation for a
+ * cipher request returns immediately before the completion of the operation.
+ * The cipher request is scheduled as a separate kernel thread and therefore
+ * load-balanced on the different CPUs via the process scheduler. To allow
+ * the kernel crypto API to inform the caller about the completion of a cipher
+ * request, the caller must provide a callback function. That function is
+ * invoked with the cipher handle when the request completes.
+ *
+ * To support the asynchronous operation, additional information than just the
+ * cipher handle must be supplied to the kernel crypto API. That additional
+ * information is given by filling in the ablkcipher_request data structure.
+ *
+ * For the asynchronous block cipher API, the state is maintained with the tfm
+ * cipher handle. A single tfm can be used across multiple calls and in
+ * parallel. For asynchronous block cipher calls, context data supplied and
+ * only used by the caller can be referenced the request data structure in
+ * addition to the IV used for the cipher request. The maintenance of such
+ * state information would be important for a crypto driver implementer to
+ * have, because when calling the callback function upon completion of the
+ * cipher operation, that callback function may need some information about
+ * which operation just finished if it invoked multiple in parallel. This
+ * state information is unused by the kernel crypto API.
+ */
+
+/**
+ * crypto_alloc_ablkcipher() - allocate asynchronous block cipher handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * ablkcipher cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Allocate a cipher handle for an ablkcipher. The returned struct
+ * crypto_ablkcipher is the cipher handle that is required for any subsequent
+ * API invocation for that ablkcipher.
+ *
+ * Return: allocated cipher handle in case of success; IS_ERR() is true in case
+ *of an error, PTR_ERR() returns the error code.
+ */
struct crypto_ablkcipher *crypto_alloc_ablkcipher(const char *alg_name,
u32 type, u32 mask);
@@ -830,11 +874,25 @@ static inline struct crypto_tfm *crypto_ablkcipher_tfm(
return &tfm->base;
}
+/**
+ * crypto_free_ablkcipher() - zeroize and free cipher handle
+ * @tfm: cipher handle to be freed
+ */
static inline void crypto_free_ablkcipher(struct crypto_ablkcipher *tfm)
{
crypto_free_tfm(crypto_ablkcipher_tfm(tfm));
}
+/**
+ * crypto_has_ablkcipher() - Search for the availability of an ablkcipher.
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * ablkcipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Return: true when the ablkcipher is known to the kernel crypto API; false
+ *otherwise
+ */
static inline int crypto_has_ablkcipher(const char *alg_name, u32 type,
u32 mask)
{
@@ -848,12 +906,31 @@ static inline struct ablkcipher_tfm
*crypto_ablkcipher_crt(
return &crypto_ablkcipher_tfm(tfm)->crt_ablkcipher;
}
+/**
+ * crypto_ablkcipher_ivsize() - obtain IV size
+ * @tfm: cipher handle
+ *
+ * The size of the IV for the ablkcipher referenced by the cipher handle is
+ * returned. This IV size may be zero if the cipher does not need an IV.
+ *
+ * Return: IV size in bytes
+ */
static inline unsigned int crypto_ablkcipher_ivsize(
struct crypto_ablkcipher *tfm)
{
return crypto_ablkcipher_crt(tfm)->ivsize;
}
+/**
+ * crypto_ablkcipher_blocksize() - obtain block size of cipher
+ * @tfm: cipher handle
+ *
+ * The block size for the ablkcipher referenced with the cipher handle is
+ * returned. The caller may use that information to allocate appropriate
+ * memory for the data returned by the encryption or decryption operation
+ *
+ * Return: block size of cipher
+ */
static inline unsigned int crypto_ablkcipher_blocksize(
struct crypto_ablkcipher *tfm)
{
@@ -883,6 +960,22 @@ static inline void crypto_ablkcipher_clear_flags(struct
crypto_ablkcipher *tfm
[PATCH v3 06/13] crypto: Documentation - AHASH API documentation
The API function calls exported by the kernel crypto API for AHASHes
to be used by consumers are documented.
Signed-off-by: Stephan Mueller
---
include/crypto/hash.h | 228 ++
1 file changed, 228 insertions(+)
diff --git a/include/crypto/hash.h b/include/crypto/hash.h
index bf458fc..b2c193a 100644
--- a/include/crypto/hash.h
+++ b/include/crypto/hash.h
@@ -202,11 +202,35 @@ struct crypto_shash {
struct crypto_tfm base;
};
+/**
+ * DOC: Asynchronous Message Digest API
+ *
+ * The asynchronous message digest API is used with the ciphers of type
+ * CRYPTO_ALG_TYPE_AHASH (listed as type "ahash" in /proc/crypto)
+ *
+ * The asynchronous cipher operation discussion provided for the
+ * CRYPTO_ALG_TYPE_ABLKCIPHER API applies here as well.
+ */
+
static inline struct crypto_ahash *__crypto_ahash_cast(struct crypto_tfm *tfm)
{
return container_of(tfm, struct crypto_ahash, base);
}
+/**
+ * crypto_alloc_ahash() - allocate ahash cipher handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * ahash cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Allocate a cipher handle for an ahash. The returned struct
+ * crypto_ahash is the cipher handle that is required for any subsequent
+ * API invocation for that ahash.
+ *
+ * Return: allocated cipher handle in case of success; IS_ERR() is true in case
+ *of an error, PTR_ERR() returns the error code.
+ */
struct crypto_ahash *crypto_alloc_ahash(const char *alg_name, u32 type,
u32 mask);
@@ -215,6 +239,10 @@ static inline struct crypto_tfm *crypto_ahash_tfm(struct
crypto_ahash *tfm)
return &tfm->base;
}
+/**
+ * crypto_free_ahash() - zeroize and free the ahash handle
+ * @tfm: cipher handle to be freed
+ */
static inline void crypto_free_ahash(struct crypto_ahash *tfm)
{
crypto_destroy_tfm(tfm, crypto_ahash_tfm(tfm));
@@ -238,6 +266,16 @@ static inline struct hash_alg_common
*crypto_hash_alg_common(
return __crypto_hash_alg_common(crypto_ahash_tfm(tfm)->__crt_alg);
}
+/**
+ * crypto_ahash_digestsize() - obtain message digest size
+ * @tfm: cipher handle
+ *
+ * The size for the message digest created by the message digest cipher
+ * referenced with the cipher handle is returned.
+ *
+ *
+ * Return: message digest size of cipher
+ */
static inline unsigned int crypto_ahash_digestsize(struct crypto_ahash *tfm)
{
return crypto_hash_alg_common(tfm)->digestsize;
@@ -263,12 +301,32 @@ static inline void crypto_ahash_clear_flags(struct
crypto_ahash *tfm, u32 flags)
crypto_tfm_clear_flags(crypto_ahash_tfm(tfm), flags);
}
+/**
+ * crypto_ahash_reqtfm() - obtain cipher handle from request
+ * @req: asynchronous request handle that contains the reference to the ahash
+ * cipher handle
+ *
+ * Return the ahash cipher handle that is registered with the asynchronous
+ * request handle ahash_request.
+ *
+ * Return: ahash cipher handle
+ */
static inline struct crypto_ahash *crypto_ahash_reqtfm(
struct ahash_request *req)
{
return __crypto_ahash_cast(req->base.tfm);
}
+/**
+ * crypto_ahash_reqsize() - obtain size of the request data structure
+ * @tfm: cipher handle
+ *
+ * Return the size of the ahash state size. With the crypto_ahash_export
+ * function, the caller can export the state into a buffer whose size is
+ * defined with this function.
+ *
+ * Return: size of the ahash state
+ */
static inline unsigned int crypto_ahash_reqsize(struct crypto_ahash *tfm)
{
return tfm->reqsize;
@@ -279,38 +337,166 @@ static inline void *ahash_request_ctx(struct
ahash_request *req)
return req->__ctx;
}
+/**
+ * crypto_ahash_setkey - set key for cipher handle
+ * @tfm: cipher handle
+ * @key: buffer holding the key
+ * @keylen: length of the key in bytes
+ *
+ * The caller provided key is set for the ahash cipher. The cipher
+ * handle must point to a keyed hash in order for this function to succeed.
+ *
+ * Return: 0 if the setting of the key was successful; < 0 if an error occurred
+ */
int crypto_ahash_setkey(struct crypto_ahash *tfm, const u8 *key,
unsigned int keylen);
+
+/**
+ * crypto_ahash_finup() - update and finalize message digest
+ * @req: reference to the ahash_request handle that holds all information
+ * needed to perform the cipher operation
+ *
+ * This function is a "short-hand" for the function calls of
+ * crypto_ahash_update and crypto_shash_final. The parameters have the same
+ * meaning as discussed for those separate functions.
+ *
+ * Return: 0 if the message digest creation was successful; < 0 if an error
+ *occurred
+ */
int crypto_ahash_finup(struct ahash_request *req);
+
+/**
+ * crypto_ahash_final() - calculate message digest
+ * @req: reference to the ahash_request handle that holds all information
+ * ne
[PATCH v3 10/13] crypto: Documentation - AEAD API documentation
The API function calls exported by the kernel crypto API for AEAD
ciphers to be used by consumers are documented.
Signed-off-by: Stephan Mueller
---
include/linux/crypto.h | 251 +
1 file changed, 251 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 39c8fc6..4704e71 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -1174,11 +1174,55 @@ static inline void ablkcipher_request_set_crypt(
req->info = iv;
}
+/**
+ * DOC: Authenticated Encryption With Associated Data (AEAD) Cipher API
+ *
+ * The AEAD cipher API is used with the ciphers of type CRYPTO_ALG_TYPE_AEAD
+ * (listed as type "aead" in /proc/crypto)
+ *
+ * The most prominent examples for this type of encryption is GCM and CCM.
+ * However, the kernel supports other types of AEAD ciphers which are defined
+ * with the following cipher string:
+ *
+ * authenc(keyed message digest, block cipher)
+ *
+ * For example: authenc(hmac(sha256), cbc(aes))
+ *
+ * The example code provided for the asynchronous block cipher operation
+ * applies here as well. Naturally all *ablkcipher* symbols must be exchanged
+ * the *aead* pendants discussed in the following. In addtion, for the AEAD
+ * operation, the aead_request_set_assoc function must be used to set the
+ * pointer to the associated data memory location before performing the
+ * encryption or decryption operation. In case of an encryption, the associated
+ * data memory is filled during the encryption operation. For decryption, the
+ * associated data memory must contain data that is used to verify the
integrity
+ * of the decrypted data. Another deviation from the asynchronous block cipher
+ * operation is that the caller should explicitly check for -EBADMSG of the
+ * crypto_aead_decrypt. That error indicates an authentication error, i.e.
+ * a breach in the integrity of the message. In essence, that -EBADMSG error
+ * code is the key bonus an AEAD cipher has over "standard" block chaining
+ * modes.
+ */
+
static inline struct crypto_aead *__crypto_aead_cast(struct crypto_tfm *tfm)
{
return (struct crypto_aead *)tfm;
}
+/**
+ * crypto_alloc_aead() - allocate AEAD cipher handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * AEAD cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Allocate a cipher handle for an AEAD. The returned struct
+ * crypto_aead is the cipher handle that is required for any subsequent
+ * API invocation for that AEAD.
+ *
+ * Return: allocated cipher handle in case of success; IS_ERR() is true in case
+ *of an error, PTR_ERR() returns the error code.
+ */
struct crypto_aead *crypto_alloc_aead(const char *alg_name, u32 type, u32
mask);
static inline struct crypto_tfm *crypto_aead_tfm(struct crypto_aead *tfm)
@@ -1186,6 +1230,10 @@ static inline struct crypto_tfm *crypto_aead_tfm(struct
crypto_aead *tfm)
return &tfm->base;
}
+/**
+ * crypto_free_aead() - zeroize and free aead handle
+ * @tfm: cipher handle to be freed
+ */
static inline void crypto_free_aead(struct crypto_aead *tfm)
{
crypto_free_tfm(crypto_aead_tfm(tfm));
@@ -1196,16 +1244,47 @@ static inline struct aead_tfm *crypto_aead_crt(struct
crypto_aead *tfm)
return &crypto_aead_tfm(tfm)->crt_aead;
}
+/**
+ * crypto_aead_ivsize() - obtain IV size
+ * @tfm: cipher handle
+ *
+ * The size of the IV for the aead referenced by the cipher handle is
+ * returned. This IV size may be zero if the cipher does not need an IV.
+ *
+ * Return: IV size in bytes
+ */
static inline unsigned int crypto_aead_ivsize(struct crypto_aead *tfm)
{
return crypto_aead_crt(tfm)->ivsize;
}
+/**
+ * crypto_aead_authsize() - obtain maximum authentication data size
+ * @tfm: cipher handle
+ *
+ * The maximum size of the authentication data for the AEAD cipher referenced
+ * by the AEAD cipher handle is returned. The authentication data size may be
+ * zero if the cipher implements a hard-coded maximum.
+ *
+ * The authentication data may also be known as "tag value".
+ *
+ * Return: authentication data size / tag size in bytes
+ */
static inline unsigned int crypto_aead_authsize(struct crypto_aead *tfm)
{
return crypto_aead_crt(tfm)->authsize;
}
+/**
+ * crypto_aead_blocksize() - obtain block size of cipher
+ * @tfm: cipher handle
+ *
+ * The block size for the AEAD referenced with the cipher handle is returned.
+ * The caller may use that information to allocate appropriate memory for the
+ * data returned by the encryption or decryption operation
+ *
+ * Return: block size of cipher
+ */
static inline unsigned int crypto_aead_blocksize(struct crypto_aead *tfm)
{
return crypto_tfm_alg_blocksize(crypto_aead_tfm(tfm));
@@ -1231,6 +1310,22 @@ static inline void crypto_aead_clear_flags(struct
crypto_aead *tfm, u32 flags)
crypto_tfm_clear_flags(cry
[PATCH v3 08/13] crypto: Documentation - cipher data structures
The data structure of struct crypto_alg together with various other
data structures needed by cipher developers is documented wit all
parameters that can be set by a developer of a transformation. All
parameters that are internal to the crypto API are marked as such.
Signed-off-by: Stephan Mueller
---
include/linux/crypto.h | 246 -
1 file changed, 243 insertions(+), 3 deletions(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index d45e949..752360e 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -127,6 +127,13 @@ struct skcipher_givcrypt_request;
typedef void (*crypto_completion_t)(struct crypto_async_request *req, int err);
+/**
+ * DOC: Block Cipher Context Data Structures
+ *
+ * These data structures define the operating context for each block cipher
+ * type.
+ */
+
struct crypto_async_request {
struct list_head list;
crypto_completion_t complete;
@@ -194,9 +201,63 @@ struct hash_desc {
u32 flags;
};
-/*
- * Algorithms: modular crypto algorithm implementations, managed
- * via crypto_register_alg() and crypto_unregister_alg().
+/**
+ * DOC: Block Cipher Algorithm Definitions
+ *
+ * These data structures define modular crypto algorithm implementations,
+ * managed via crypto_register_alg() and crypto_unregister_alg().
+ */
+
+/**
+ * struct ablkcipher_alg - asynchronous block cipher definition
+ * @min_keysize: Minimum key size supported by the transformation. This is the
+ * smallest key length supported by this transformation algorithm.
+ * This must be set to one of the pre-defined values as this is
+ * not hardware specific. Possible values for this field can be
+ * found via git grep "_MIN_KEY_SIZE" include/crypto/
+ * @max_keysize: Maximum key size supported by the transformation. This is the
+ * largest key length supported by this transformation algorithm.
+ * This must be set to one of the pre-defined values as this is
+ * not hardware specific. Possible values for this field can be
+ * found via git grep "_MAX_KEY_SIZE" include/crypto/
+ * @setkey: Set key for the transformation. This function is used to either
+ * program a supplied key into the hardware or store the key in the
+ * transformation context for programming it later. Note that this
+ * function does modify the transformation context. This function can
+ * be called multiple times during the existence of the transformation
+ * object, so one must make sure the key is properly reprogrammed into
+ * the hardware. This function is also responsible for checking the key
+ * length for validity. In case a software fallback was put in place in
+ * the @cra_init call, this function might need to use the fallback if
+ * the algorithm doesn't support all of the key sizes.
+ * @encrypt: Encrypt a scatterlist of blocks. This function is used to encrypt
+ * the supplied scatterlist containing the blocks of data. The crypto
+ * API consumer is responsible for aligning the entries of the
+ * scatterlist properly and making sure the chunks are correctly
+ * sized. In case a software fallback was put in place in the
+ * @cra_init call, this function might need to use the fallback if
+ * the algorithm doesn't support all of the key sizes. In case the
+ * key was stored in transformation context, the key might need to be
+ * re-programmed into the hardware in this function. This function
+ * shall not modify the transformation context, as this function may
+ * be called in parallel with the same transformation object.
+ * @decrypt: Decrypt a single block. This is a reverse counterpart to @encrypt
+ * and the conditions are exactly the same.
+ * @givencrypt: Update the IV for encryption. With this function, a cipher
+ * implementation may provide the function on how to update the IV
+ * for encryption.
+ * @givdecrypt: Update the IV for decryption. This is the reverse of
+ * @givencrypt .
+ * @geniv: The transformation implementation may use an "IV generator" provided
+ *by the kernel crypto API. Several use cases have a predefined
+ *approach how IVs are to be updated. For such use cases, the kernel
+ *crypto API provides ready-to-use implementations that can be
+ *referenced with this variable.
+ * @ivsize: IV size applicable for transformation. The consumer must provide an
+ * IV of exactly that size to perform the encrypt or decrypt operation.
+ *
+ * All fields except @givencrypt , @givdecrypt , @geniv and @ivsize are
+ * mandatory and must be filled.
*/
struct ablkcipher_alg {
int (*setkey)(struct crypto_ablkcipher *tfm, const u8 *key,
@@ -213,6 +274,32 @@ struct ablkc
[PATCH v3 04/13] crypto: Documentation - RNG API documentation
The API function calls exported by the kernel crypto API for RNGs to
be used by consumers are documented.
Signed-off-by: Stephan Mueller
---
include/crypto/rng.h | 80
1 file changed, 80 insertions(+)
diff --git a/include/crypto/rng.h b/include/crypto/rng.h
index c93f9b9..a16fb10 100644
--- a/include/crypto/rng.h
+++ b/include/crypto/rng.h
@@ -20,11 +20,38 @@ extern struct crypto_rng *crypto_default_rng;
int crypto_get_default_rng(void);
void crypto_put_default_rng(void);
+/**
+ * DOC: Random number generator API
+ *
+ * The random number generator API is used with the ciphers of type
+ * CRYPTO_ALG_TYPE_RNG (listed as type "rng" in /proc/crypto)
+ */
+
static inline struct crypto_rng *__crypto_rng_cast(struct crypto_tfm *tfm)
{
return (struct crypto_rng *)tfm;
}
+/**
+ * crypto_alloc_rng() -- allocate RNG handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * message digest cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Allocate a cipher handle for a random number generator. The returned struct
+ * crypto_rng is the cipher handle that is required for any subsequent
+ * API invocation for that random number generator.
+ *
+ * For all random number generators, this call creates a new private copy of
+ * the random number generator that does not share a state with other
+ * instances. The only exception is the "krng" random number generator which
+ * is a kernel crypto API use case for the get_random_bytes() function of the
+ * /dev/random driver.
+ *
+ * Return: allocated cipher handle in case of success; IS_ERR() is true in case
+ *of an error, PTR_ERR() returns the error code.
+ */
static inline struct crypto_rng *crypto_alloc_rng(const char *alg_name,
u32 type, u32 mask)
{
@@ -40,6 +67,14 @@ static inline struct crypto_tfm *crypto_rng_tfm(struct
crypto_rng *tfm)
return &tfm->base;
}
+/**
+ * crypto_rng_alg - obtain name of RNG
+ * @tfm: cipher handle
+ *
+ * Return the generic name (cra_name) of the initialized random number
generator
+ *
+ * Return: generic name string
+ */
static inline struct rng_alg *crypto_rng_alg(struct crypto_rng *tfm)
{
return &crypto_rng_tfm(tfm)->__crt_alg->cra_rng;
@@ -50,23 +85,68 @@ static inline struct rng_tfm *crypto_rng_crt(struct
crypto_rng *tfm)
return &crypto_rng_tfm(tfm)->crt_rng;
}
+/**
+ * crypto_free_rng() - zeroize and free RNG handle
+ * @tfm: cipher handle to be freed
+ */
static inline void crypto_free_rng(struct crypto_rng *tfm)
{
crypto_free_tfm(crypto_rng_tfm(tfm));
}
+/**
+ * crypto_rng_get_bytes() - get random number
+ * @tfm: cipher handle
+ * @rdata: output buffer holding the random numbers
+ * @dlen: length of the output buffer
+ *
+ * This function fills the caller-allocated buffer with random numbers using
the
+ * random number generator referenced by the cipher handle.
+ *
+ * Return: > 0 function was successful and returns the number of generated
+ *bytes; < 0 if an error occurred
+ */
static inline int crypto_rng_get_bytes(struct crypto_rng *tfm,
u8 *rdata, unsigned int dlen)
{
return crypto_rng_crt(tfm)->rng_gen_random(tfm, rdata, dlen);
}
+/**
+ * crypto_rng_reset() - re-initialize the RNG
+ * @tfm: cipher handle
+ * @seed: seed input data
+ * @slen: length of the seed input data
+ *
+ * The reset function completely re-initializes the random number generator
+ * referenced by the cipher handle by clearing the current state. The new state
+ * is initialized with the caller provided seed or automatically, depending
+ * on the random number generator type (the ANSI X9.31 RNG requires
+ * caller-provided seed, the SP800-90A DRBGs perform an automatic seeding).
+ * The seed is provided as a parameter to this function call. The provided seed
+ * should have the length of the seed size defined for the random number
+ * generator as defined by crypto_rng_seedsize.
+ *
+ * Return: 0 if the setting of the key was successful; < 0 if an error occurred
+ */
static inline int crypto_rng_reset(struct crypto_rng *tfm,
u8 *seed, unsigned int slen)
{
return crypto_rng_crt(tfm)->rng_reset(tfm, seed, slen);
}
+/**
+ * crypto_rng_seedsize() - obtain seed size of RNG
+ * @tfm: cipher handle
+ *
+ * The function returns the seed size for the random number generator
+ * referenced by the cipher handle. This value may be zero if the random
+ * number generator does not implement or require a reseeding. For example,
+ * the SP800-90A DRBGs implement an automated reseeding after reaching a
+ * pre-defined threshold.
+ *
+ * Return: seed size for the random number generator
+ */
static inline int crypto_rng_seedsize(struct crypto_rng *tfm)
{
return crypto_rng_alg(tfm)->seedsize;
[PATCH v3 13/13] crypto: Documentation - HASH API documentation
The API function calls exported by the kernel crypto API for
message digests to be used by consumers are documented.
Signed-off-by: Stephan Mueller
---
include/linux/crypto.h | 119 +
1 file changed, 119 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 0f95a07..208a632 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -2082,6 +2082,13 @@ static inline void crypto_cipher_decrypt_one(struct
crypto_cipher *tfm,
dst, src);
}
+/**
+ * DOC: Synchronous Message Digest API
+ *
+ * The synchronous message digest API is used with the ciphers of type
+ * CRYPTO_ALG_TYPE_HASH (listed as type "hash" in /proc/crypto)
+ */
+
static inline struct crypto_hash *__crypto_hash_cast(struct crypto_tfm *tfm)
{
return (struct crypto_hash *)tfm;
@@ -2094,6 +2101,20 @@ static inline struct crypto_hash
*crypto_hash_cast(struct crypto_tfm *tfm)
return __crypto_hash_cast(tfm);
}
+/**
+ * crypto_alloc_hash() - allocate synchronous message digest handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * message digest cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Allocate a cipher handle for a message digest. The returned struct
+ * crypto_hash is the cipher handle that is required for any subsequent
+ * API invocation for that message digest.
+ *
+ * Return: allocated cipher handle in case of success; IS_ERR() is true in case
+ * of an error, PTR_ERR() returns the error code.
+ */
static inline struct crypto_hash *crypto_alloc_hash(const char *alg_name,
u32 type, u32 mask)
{
@@ -2110,11 +2131,25 @@ static inline struct crypto_tfm *crypto_hash_tfm(struct
crypto_hash *tfm)
return &tfm->base;
}
+/**
+ * crypto_free_hash() - zeroize and free message digest handle
+ * @tfm: cipher handle to be freed
+ */
static inline void crypto_free_hash(struct crypto_hash *tfm)
{
crypto_free_tfm(crypto_hash_tfm(tfm));
}
+/**
+ * crypto_has_hash() - Search for the availability of a message digest
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * message digest cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Return: true when the message digest cipher is known to the kernel crypto
+ *API; false otherwise
+ */
static inline int crypto_has_hash(const char *alg_name, u32 type, u32 mask)
{
type &= ~CRYPTO_ALG_TYPE_MASK;
@@ -2130,6 +2165,15 @@ static inline struct hash_tfm *crypto_hash_crt(struct
crypto_hash *tfm)
return &crypto_hash_tfm(tfm)->crt_hash;
}
+/**
+ * crypto_hash_blocksize() - obtain block size for message digest
+ * @tfm: cipher handle
+ *
+ * The block size for the message digest cipher referenced with the cipher
+ * handle is returned.
+ *
+ * Return: block size of cipher
+ */
static inline unsigned int crypto_hash_blocksize(struct crypto_hash *tfm)
{
return crypto_tfm_alg_blocksize(crypto_hash_tfm(tfm));
@@ -2140,6 +2184,15 @@ static inline unsigned int crypto_hash_alignmask(struct
crypto_hash *tfm)
return crypto_tfm_alg_alignmask(crypto_hash_tfm(tfm));
}
+/**
+ * crypto_hash_digestsize() - obtain message digest size
+ * @tfm: cipher handle
+ *
+ * The size for the message digest created by the message digest cipher
+ * referenced with the cipher handle is returned.
+ *
+ * Return: message digest size
+ */
static inline unsigned int crypto_hash_digestsize(struct crypto_hash *tfm)
{
return crypto_hash_crt(tfm)->digestsize;
@@ -2160,11 +2213,38 @@ static inline void crypto_hash_clear_flags(struct
crypto_hash *tfm, u32 flags)
crypto_tfm_clear_flags(crypto_hash_tfm(tfm), flags);
}
+/**
+ * crypto_hash_init() - (re)initialize message digest handle
+ * @desc: cipher request handle that to be filled by caller --
+ * desc.tfm is filled with the hash cipher handle;
+ * desc.flags is filled with either CRYPTO_TFM_REQ_MAY_SLEEP or 0.
+ *
+ * The call (re-)initializes the message digest referenced by the hash cipher
+ * request handle. Any potentially existing state created by previous
+ * operations is discarded.
+ *
+ * Return: 0 if the message digest initialization was successful; < 0 if an
+ *error occurred
+ */
static inline int crypto_hash_init(struct hash_desc *desc)
{
return crypto_hash_crt(desc->tfm)->init(desc);
}
+/**
+ * crypto_hash_update() - add data to message digest for processing
+ * @desc: cipher request handle
+ * @sg: scatter / gather list pointing to the data to be added to the message
+ * digest
+ * @nbytes: number of bytes to be processed from @sg
+ *
+ * Updates the message digest state of the cipher handle pointed to by the
+ * hash cipher request handle with the input data poin
[PATCH v3 12/13] crypto: Documentation - CIPHER API documentation
The API function calls exported by the kernel crypto API for
signle block ciphers to be used by consumers are documented.
Signed-off-by: Stephan Mueller
---
include/linux/crypto.h | 89 ++
1 file changed, 89 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index c9ebe45..0f95a07 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -1900,6 +1900,23 @@ static inline void crypto_blkcipher_get_iv(struct
crypto_blkcipher *tfm,
memcpy(dst, crypto_blkcipher_crt(tfm)->iv, len);
}
+/**
+ * DOC: Single Block Cipher API
+ *
+ * The single block cipher API is used with the ciphers of type
+ * CRYPTO_ALG_TYPE_CIPHER (listed as type "cipher" in /proc/crypto).
+ *
+ * Using the single block cipher API calls, operations with the basic cipher
+ * primitive can be implemented. These cipher primitives exclude any block
+ * chaining operations including IV handling.
+ *
+ * The purpose of this single block cipher API is to support the implementation
+ * of templates or other concepts that only need to perform the cipher
operation
+ * on one block at a time. Templates invoke the underlying cipher primitive
+ * block-wise and process either the input or the output data of these cipher
+ * operations.
+ */
+
static inline struct crypto_cipher *__crypto_cipher_cast(struct crypto_tfm
*tfm)
{
return (struct crypto_cipher *)tfm;
@@ -1911,6 +1928,20 @@ static inline struct crypto_cipher
*crypto_cipher_cast(struct crypto_tfm *tfm)
return __crypto_cipher_cast(tfm);
}
+/**
+ * crypto_alloc_cipher() - allocate single block cipher handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * single block cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Allocate a cipher handle for a single block cipher. The returned struct
+ * crypto_cipher is the cipher handle that is required for any subsequent API
+ * invocation for that single block cipher.
+ *
+ * Return: allocated cipher handle in case of success; IS_ERR() is true in case
+ *of an error, PTR_ERR() returns the error code.
+ */
static inline struct crypto_cipher *crypto_alloc_cipher(const char *alg_name,
u32 type, u32 mask)
{
@@ -1926,11 +1957,25 @@ static inline struct crypto_tfm
*crypto_cipher_tfm(struct crypto_cipher *tfm)
return &tfm->base;
}
+/**
+ * crypto_free_cipher() - zeroize and free the single block cipher handle
+ * @tfm: cipher handle to be freed
+ */
static inline void crypto_free_cipher(struct crypto_cipher *tfm)
{
crypto_free_tfm(crypto_cipher_tfm(tfm));
}
+/**
+ * crypto_has_cipher() - Search for the availability of a single block cipher
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * single block cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Return: true when the single block cipher is known to the kernel crypto API;
+ *false otherwise
+ */
static inline int crypto_has_cipher(const char *alg_name, u32 type, u32 mask)
{
type &= ~CRYPTO_ALG_TYPE_MASK;
@@ -1945,6 +1990,16 @@ static inline struct cipher_tfm
*crypto_cipher_crt(struct crypto_cipher *tfm)
return &crypto_cipher_tfm(tfm)->crt_cipher;
}
+/**
+ * crypto_cipher_blocksize() - obtain block size for cipher
+ * @tfm: cipher handle
+ *
+ * The block size for the single block cipher referenced with the cipher handle
+ * tfm is returned. The caller may use that information to allocate appropriate
+ * memory for the data returned by the encryption or decryption operation
+ *
+ * Return: block size of cipher
+ */
static inline unsigned int crypto_cipher_blocksize(struct crypto_cipher *tfm)
{
return crypto_tfm_alg_blocksize(crypto_cipher_tfm(tfm));
@@ -1972,6 +2027,22 @@ static inline void crypto_cipher_clear_flags(struct
crypto_cipher *tfm,
crypto_tfm_clear_flags(crypto_cipher_tfm(tfm), flags);
}
+/**
+ * crypto_cipher_setkey() - set key for cipher
+ * @tfm: cipher handle
+ * @key: buffer holding the key
+ * @keylen: length of the key in bytes
+ *
+ * The caller provided key is set for the single block cipher referenced by the
+ * cipher handle.
+ *
+ * Note, the key length determines the cipher type. Many block ciphers
implement
+ * different cipher modes depending on the key size, such as AES-128 vs AES-192
+ * vs. AES-256. When providing a 16 byte key for an AES cipher handle, AES-128
+ * is performed.
+ *
+ * Return: 0 if the setting of the key was successful; < 0 if an error occurred
+ */
static inline int crypto_cipher_setkey(struct crypto_cipher *tfm,
const u8 *key, unsigned int keylen)
{
@@ -1979,6 +2050,15 @@ static inline int crypto_cipher_setkey(struct
crypto_cipher *tfm,
[PATCH v3 11/13] crypto: Documentation - BLKCIPHER API documentation
The API function calls exported by the kernel crypto API for
synchronous block ciphers to be used by consumers are documented.
Signed-off-by: Stephan Mueller
---
include/linux/crypto.h | 188 +
1 file changed, 188 insertions(+)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 4704e71..c9ebe45 100644
--- a/include/linux/crypto.h
+++ b/include/linux/crypto.h
@@ -1565,6 +1565,36 @@ static inline void aead_request_set_assoc(struct
aead_request *req,
req->assoclen = assoclen;
}
+/**
+ * DOC: Synchronous Block Cipher API
+ *
+ * The synchronous block cipher API is used with the ciphers of type
+ * CRYPTO_ALG_TYPE_BLKCIPHER (listed as type "blkcipher" in /proc/crypto)
+ *
+ * Synchronous calls, have a context in the tfm. But since a single tfm can be
+ * used in multiple calls and in parallel, this info should not be changeable
+ * (unless a lock is used). This applies, for example, to the symmetric key.
+ * However, the IV is changeable, so there is an iv field in blkcipher_tfm
+ * structure for synchronous blkcipher api. So, its the only state info that
can
+ * be kept for synchronous calls without using a big lock across a tfm.
+ *
+ * The block cipher API allows the use of a complete cipher, i.e. a cipher
+ * consisting of a template (a block chaining mode) and a single block cipher
+ * primitive (e.g. AES).
+ *
+ * The plaintext data buffer and the ciphertext data buffer are pointed to
+ * by using scatter/gather lists. The cipher operation is performed
+ * on all segments of the provided scatter/gather lists.
+ *
+ * The kernel crypto API supports a cipher operation "in-place" which means
that
+ * the caller may provide the same scatter/gather list for the plaintext and
+ * cipher text. After the completion of the cipher operation, the plaintext
+ * data is replaced with the ciphertext data in case of an encryption and vice
+ * versa for a decryption. The caller must ensure that the scatter/gather lists
+ * for the output data point to sufficiently large buffers, i.e. multiples of
+ * the block size of the cipher.
+ */
+
static inline struct crypto_blkcipher *__crypto_blkcipher_cast(
struct crypto_tfm *tfm)
{
@@ -1578,6 +1608,20 @@ static inline struct crypto_blkcipher
*crypto_blkcipher_cast(
return __crypto_blkcipher_cast(tfm);
}
+/**
+ * crypto_alloc_blkcipher() - allocate synchronous block cipher handle
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * blkcipher cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Allocate a cipher handle for a block cipher. The returned struct
+ * crypto_blkcipher is the cipher handle that is required for any subsequent
+ * API invocation for that block cipher.
+ *
+ * Return: allocated cipher handle in case of success; IS_ERR() is true in case
+ *of an error, PTR_ERR() returns the error code.
+ */
static inline struct crypto_blkcipher *crypto_alloc_blkcipher(
const char *alg_name, u32 type, u32 mask)
{
@@ -1594,11 +1638,25 @@ static inline struct crypto_tfm *crypto_blkcipher_tfm(
return &tfm->base;
}
+/**
+ * crypto_free_blkcipher() - zeroize and free the block cipher handle
+ * @tfm: cipher handle to be freed
+ */
static inline void crypto_free_blkcipher(struct crypto_blkcipher *tfm)
{
crypto_free_tfm(crypto_blkcipher_tfm(tfm));
}
+/**
+ * crypto_has_blkcipher() - Search for the availability of a block cipher
+ * @alg_name: is the cra_name / name or cra_driver_name / driver name of the
+ * block cipher
+ * @type: specifies the type of the cipher
+ * @mask: specifies the mask for the cipher
+ *
+ * Return: true when the block cipher is known to the kernel crypto API; false
+ *otherwise
+ */
static inline int crypto_has_blkcipher(const char *alg_name, u32 type, u32
mask)
{
type &= ~CRYPTO_ALG_TYPE_MASK;
@@ -1608,6 +1666,12 @@ static inline int crypto_has_blkcipher(const char
*alg_name, u32 type, u32 mask)
return crypto_has_alg(alg_name, type, mask);
}
+/**
+ * crypto_blkcipher_name() - return the name / cra_name from the cipher handle
+ * @tfm: cipher handle
+ *
+ * Return: The character string holding the name of the cipher
+ */
static inline const char *crypto_blkcipher_name(struct crypto_blkcipher *tfm)
{
return crypto_tfm_alg_name(crypto_blkcipher_tfm(tfm));
@@ -1625,11 +1689,30 @@ static inline struct blkcipher_alg
*crypto_blkcipher_alg(
return &crypto_blkcipher_tfm(tfm)->__crt_alg->cra_blkcipher;
}
+/**
+ * crypto_blkcipher_ivsize() - obtain IV size
+ * @tfm: cipher handle
+ *
+ * The size of the IV for the block cipher referenced by the cipher handle is
+ * returned. This IV size may be zero if the cipher does not need an IV.
+ *
+ * Return: IV size in bytes
+ */
static inline unsigned int crypto_blkcipher_ivsize(struct crypto_blkcipher
*tfm)
{
return cr
Re: [PATCH v2 2/2] mem-hotplug: Reset node present pages when hot-adding a new pgdat.
(2014/11/11 10:27), Tang Chen wrote:
> When onlining memory on node2, node2 zoneinfo and node3 meminfo corrupted:
>
> # for ((i = 2048; i < 2064; i++)); do echo online_movable >
> /sys/devices/system/node/node2/memory$i/state; done
> # cat /sys/devices/system/node/node2/meminfo
> Node 2 MemTotal: 33554432 kB
> Node 2 MemFree:33549092 kB
> Node 2 MemUsed:5340 kB
> ..
> # cat /sys/devices/system/node/node3/meminfo
> Node 3 MemTotal: 0 kB
> Node 3 MemFree: 248 kB /* corrupted, should be 0 */
> Node 3 MemUsed: 0 kB
> ..
>
> # cat /proc/zoneinfo
> ..
> Node 2, zone Movable
> ..
> spanned 8388608
> present 16777216 /* corrupted, should be 8388608 */
> managed 8388608
>
>
> When memory is hot-added, all the memory is in offline state. So
> clear all zone->present_pages because they will be updated in
> online_pages() and offline_pages().
>
> Signed-off-by: Tang Chen
> Reviewed-by: Yasuaki Ishimatsu
I has reviewed your patch. But I have one comment.
Please see below.
> ---
> mm/memory_hotplug.c | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
> index 8aba12b..26eac61 100644
> --- a/mm/memory_hotplug.c
> +++ b/mm/memory_hotplug.c
> @@ -1067,6 +1067,14 @@ out:
> }
> #endif /* CONFIG_MEMORY_HOTPLUG_SPARSE */
>
> +static void reset_node_present_pages(pg_data_t *pgdat)
> +{
> +struct zone *z;
> +
> +for (z = pgdat->node_zones; z < pgdat->node_zones + MAX_NR_ZONES;
> z++)
> +z->present_pages = 0;
> +}
You should reset pgdat->node_present_pages.
pgdat->node_present_pages is set to realtotalpages by
calculate_node_totalpages().
And it is also incremented/decremented by memroy online/offline.
So pgdat->node_present_pages is broken internally too.
Thanks,
Yasuaki Ishimatsu.
> +
> /* we are OK calling __meminit stuff here - we have CONFIG_MEMORY_HOTPLUG */
> static pg_data_t __ref *hotadd_new_pgdat(int nid, u64 start)
> {
> @@ -1105,6 +1113,13 @@ static pg_data_t __ref *hotadd_new_pgdat(int nid, u64
> start)
>*/
> reset_node_managed_pages(pgdat);
>
> + /*
> + * When memory is hot-added, all the memory is in offline state. So
> + * clear all zones' present_pages because they will be updated in
> + * online_pages() and offline_pages().
> + */
> + reset_node_present_pages(pgdat);
> +
> return pgdat;
> }
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.17 013/319] net: tso: fix unaligned access to crafted TCP header in helper API
3.17-stable review patch. If anyone has any objections, please let me know.
--
From: Karl Beldan
[ Upstream commit a63ba13eec092b70d4e5522d692eaeb2f9747387 ]
The crafted header start address is from a driver supplied buffer, which
one can reasonably expect to be aligned on a 4-bytes boundary.
However ATM the TSO helper API is only used by ethernet drivers and
the tcp header will then be aligned to a 2-bytes only boundary from the
header start address.
Signed-off-by: Karl Beldan
Cc: Ezequiel Garcia
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/core/tso.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/net/core/tso.c
+++ b/net/core/tso.c
@@ -1,6 +1,7 @@
#include
#include
#include
+#include
/* Calculate expected number of TX descriptors */
int tso_count_descs(struct sk_buff *skb)
@@ -23,7 +24,7 @@ void tso_build_hdr(struct sk_buff *skb,
iph->id = htons(tso->ip_id);
iph->tot_len = htons(size + hdr_len - mac_hdr_len);
tcph = (struct tcphdr *)(hdr + skb_transport_offset(skb));
- tcph->seq = htonl(tso->tcp_seq);
+ put_unaligned_be32(tso->tcp_seq, &tcph->seq);
tso->ip_id++;
if (!is_last) {
--
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 10/10] PCI/MSI: Remove useless bus->msi assignment
On Mon, Oct 27, 2014 at 03:48:47PM +0800, Yijing Wang wrote:
> Thierry introduced MSI chip(now renamed to MSI controller)
> framework to associate MSI chip and PCI bus in arm.
> Other platforms still use its own arch MSI functions to
> support MSI capability. Thierry introduced the bus->msi
> assignment to make child bus can inherit bus->msi from the parent.
> But in fact, drivers which used MSI chip always associate
> MSI chip and PCI bus by add .add_bus() in arm PCI host bridge
> drivers. Now we have saved MSI chip in pci_sys_data.
> We can remove this bus->msi assignment safely.
>
> Signed-off-by: Yijing Wang
> CC: Thierry Reding
> CC: Thomas Petazzoni
> ---
> drivers/pci/msi.c |5 -
> drivers/pci/probe.c |1 -
> 2 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
> index f085f7f..27b6a54 100644
> --- a/drivers/pci/msi.c
> +++ b/drivers/pci/msi.c
> @@ -37,11 +37,6 @@ struct msi_controller * __weak
> pcibios_msi_controller(struct pci_bus *bus)
>
> struct msi_controller *pci_msi_controller(struct pci_bus *bus)
> {
> - struct msi_controller *ctrl = bus->msi;
> -
> - if (ctrl)
> - return ctrl;
> -
> return pcibios_msi_controller(bus);
> }
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 5ed9930..4b18bf2 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -682,7 +682,6 @@ static struct pci_bus *pci_alloc_child_bus(struct pci_bus
> *parent,
>
> child->parent = parent;
> child->ops = parent->ops;
> - child->msi = parent->msi;
Does this mean that struct pci_bus.msi is now unused? If not, where is it
still used?
> child->sysdata = parent->sysdata;
> child->bus_flags = parent->bus_flags;
>
> --
> 1.7.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.17 012/319] netlink: Re-add locking to netlink_lookup() and seq walker
3.17-stable review patch. If anyone has any objections, please let me know.
--
From: Thomas Graf
[ Upstream commit 78fd1d0ab072d4d9b5f0b7c14a1516665170b565 ]
The synchronize_rcu() in netlink_release() introduces unacceptable
latency. Reintroduce minimal lookup so we can drop the
synchronize_rcu() until socket destruction has been RCUfied.
Cc: David S. Miller
Cc: Eric Dumazet
Reported-by: Steinar H. Gunderson
Reported-and-tested-by: Heiko Carstens
Signed-off-by: Thomas Graf
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/netlink/af_netlink.c | 37 +
1 file changed, 25 insertions(+), 12 deletions(-)
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/af_netlink.c
@@ -96,6 +96,14 @@ static DECLARE_WAIT_QUEUE_HEAD(nl_table_
static int netlink_dump(struct sock *sk);
static void netlink_skb_destructor(struct sk_buff *skb);
+/* nl_table locking explained:
+ * Lookup and traversal are protected with nl_sk_hash_lock or nl_table_lock
+ * combined with an RCU read-side lock. Insertion and removal are protected
+ * with nl_sk_hash_lock while using RCU list modification primitives and may
+ * run in parallel to nl_table_lock protected lookups. Destruction of the
+ * Netlink socket may only occur *after* nl_table_lock has been acquired
+ * either during or after the socket has been removed from the list.
+ */
DEFINE_RWLOCK(nl_table_lock);
EXPORT_SYMBOL_GPL(nl_table_lock);
static atomic_t nl_table_users = ATOMIC_INIT(0);
@@ -109,10 +117,10 @@ EXPORT_SYMBOL_GPL(nl_sk_hash_lock);
static int lockdep_nl_sk_hash_is_held(void)
{
#ifdef CONFIG_LOCKDEP
- return (debug_locks) ? lockdep_is_held(&nl_sk_hash_lock) : 1;
-#else
- return 1;
+ if (debug_locks)
+ return lockdep_is_held(&nl_sk_hash_lock) ||
lockdep_is_held(&nl_table_lock);
#endif
+ return 1;
}
static ATOMIC_NOTIFIER_HEAD(netlink_chain);
@@ -1028,11 +1036,13 @@ static struct sock *netlink_lookup(struc
struct netlink_table *table = &nl_table[protocol];
struct sock *sk;
+ read_lock(&nl_table_lock);
rcu_read_lock();
sk = __netlink_lookup(table, portid, net);
if (sk)
sock_hold(sk);
rcu_read_unlock();
+ read_unlock(&nl_table_lock);
return sk;
}
@@ -1257,9 +1267,6 @@ static int netlink_release(struct socket
}
netlink_table_ungrab();
- /* Wait for readers to complete */
- synchronize_net();
-
kfree(nlk->groups);
nlk->groups = NULL;
@@ -1281,6 +1288,7 @@ static int netlink_autobind(struct socke
retry:
cond_resched();
+ netlink_table_grab();
rcu_read_lock();
if (__netlink_lookup(table, portid, net)) {
/* Bind collision, search negative portid values. */
@@ -1288,9 +1296,11 @@ retry:
if (rover > -4097)
rover = -4097;
rcu_read_unlock();
+ netlink_table_ungrab();
goto retry;
}
rcu_read_unlock();
+ netlink_table_ungrab();
err = netlink_insert(sk, net, portid);
if (err == -EADDRINUSE)
@@ -2921,14 +2931,16 @@ static struct sock *netlink_seq_socket_i
}
static void *netlink_seq_start(struct seq_file *seq, loff_t *pos)
- __acquires(RCU)
+ __acquires(nl_table_lock) __acquires(RCU)
{
+ read_lock(&nl_table_lock);
rcu_read_lock();
return *pos ? netlink_seq_socket_idx(seq, *pos - 1) : SEQ_START_TOKEN;
}
static void *netlink_seq_next(struct seq_file *seq, void *v, loff_t *pos)
{
+ struct rhashtable *ht;
struct netlink_sock *nlk;
struct nl_seq_iter *iter;
struct net *net;
@@ -2943,19 +2955,19 @@ static void *netlink_seq_next(struct seq
iter = seq->private;
nlk = v;
- rht_for_each_entry_rcu(nlk, nlk->node.next, node)
+ i = iter->link;
+ ht = &nl_table[i].hash;
+ rht_for_each_entry(nlk, nlk->node.next, ht, node)
if (net_eq(sock_net((struct sock *)nlk), net))
return nlk;
- i = iter->link;
j = iter->hash_idx + 1;
do {
- struct rhashtable *ht = &nl_table[i].hash;
const struct bucket_table *tbl = rht_dereference_rcu(ht->tbl,
ht);
for (; j < tbl->size; j++) {
- rht_for_each_entry_rcu(nlk, tbl->buckets[j], node) {
+ rht_for_each_entry(nlk, tbl->buckets[j], ht, node) {
if (net_eq(sock_net((struct sock *)nlk), net)) {
iter->link = i;
iter->hash_idx = j;
@@ -2971,9 +2983,10 @@ static void *netlink_seq_next(struct seq
}
static void netlink_seq_stop(struct seq_file *seq, void *v)
- __releases(RCU)
+ __releases(RCU) __releases(nl_table_lock)
{
rcu_read_unloc
[PATCH 3.17 016/319] tcp: md5: do not use alloc_percpu()
3.17-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit 349ce993ac706869d553a1816426d3a4bfda02b1 ]
percpu tcp_md5sig_pool contains memory blobs that ultimately
go through sg_set_buf().
-> sg_set_page(sg, virt_to_page(buf), buflen, offset_in_page(buf));
This requires that whole area is in a physically contiguous portion
of memory. And that @buf is not backed by vmalloc().
Given that alloc_percpu() can use vmalloc() areas, this does not
fit the requirements.
Replace alloc_percpu() by a static DEFINE_PER_CPU() as tcp_md5sig_pool
is small anyway, there is no gain to dynamically allocate it.
Signed-off-by: Eric Dumazet
Fixes: 765cf9976e93 ("tcp: md5: remove one indirection level in
tcp_md5sig_pool")
Reported-by: Crestez Dan Leonard
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
net/ipv4/tcp.c | 59 +++--
1 file changed, 20 insertions(+), 39 deletions(-)
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -2985,61 +2985,42 @@ EXPORT_SYMBOL(compat_tcp_getsockopt);
#endif
#ifdef CONFIG_TCP_MD5SIG
-static struct tcp_md5sig_pool __percpu *tcp_md5sig_pool __read_mostly;
+static DEFINE_PER_CPU(struct tcp_md5sig_pool, tcp_md5sig_pool);
static DEFINE_MUTEX(tcp_md5sig_mutex);
-
-static void __tcp_free_md5sig_pool(struct tcp_md5sig_pool __percpu *pool)
-{
- int cpu;
-
- for_each_possible_cpu(cpu) {
- struct tcp_md5sig_pool *p = per_cpu_ptr(pool, cpu);
-
- if (p->md5_desc.tfm)
- crypto_free_hash(p->md5_desc.tfm);
- }
- free_percpu(pool);
-}
+static bool tcp_md5sig_pool_populated = false;
static void __tcp_alloc_md5sig_pool(void)
{
int cpu;
- struct tcp_md5sig_pool __percpu *pool;
-
- pool = alloc_percpu(struct tcp_md5sig_pool);
- if (!pool)
- return;
for_each_possible_cpu(cpu) {
- struct crypto_hash *hash;
+ if (!per_cpu(tcp_md5sig_pool, cpu).md5_desc.tfm) {
+ struct crypto_hash *hash;
- hash = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
- if (IS_ERR_OR_NULL(hash))
- goto out_free;
-
- per_cpu_ptr(pool, cpu)->md5_desc.tfm = hash;
+ hash = crypto_alloc_hash("md5", 0, CRYPTO_ALG_ASYNC);
+ if (IS_ERR_OR_NULL(hash))
+ return;
+ per_cpu(tcp_md5sig_pool, cpu).md5_desc.tfm = hash;
+ }
}
- /* before setting tcp_md5sig_pool, we must commit all writes
-* to memory. See ACCESS_ONCE() in tcp_get_md5sig_pool()
+ /* before setting tcp_md5sig_pool_populated, we must commit all writes
+* to memory. See smp_rmb() in tcp_get_md5sig_pool()
*/
smp_wmb();
- tcp_md5sig_pool = pool;
- return;
-out_free:
- __tcp_free_md5sig_pool(pool);
+ tcp_md5sig_pool_populated = true;
}
bool tcp_alloc_md5sig_pool(void)
{
- if (unlikely(!tcp_md5sig_pool)) {
+ if (unlikely(!tcp_md5sig_pool_populated)) {
mutex_lock(&tcp_md5sig_mutex);
- if (!tcp_md5sig_pool)
+ if (!tcp_md5sig_pool_populated)
__tcp_alloc_md5sig_pool();
mutex_unlock(&tcp_md5sig_mutex);
}
- return tcp_md5sig_pool != NULL;
+ return tcp_md5sig_pool_populated;
}
EXPORT_SYMBOL(tcp_alloc_md5sig_pool);
@@ -3053,13 +3034,13 @@ EXPORT_SYMBOL(tcp_alloc_md5sig_pool);
*/
struct tcp_md5sig_pool *tcp_get_md5sig_pool(void)
{
- struct tcp_md5sig_pool __percpu *p;
-
local_bh_disable();
- p = ACCESS_ONCE(tcp_md5sig_pool);
- if (p)
- return __this_cpu_ptr(p);
+ if (tcp_md5sig_pool_populated) {
+ /* coupled with smp_wmb() in __tcp_alloc_md5sig_pool() */
+ smp_rmb();
+ return this_cpu_ptr(&tcp_md5sig_pool);
+ }
local_bh_enable();
return 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 00/10] Save MSI chip in pci_sys_data
On Mon, Oct 27, 2014 at 03:48:37PM +0800, Yijing Wang wrote: > Now PCI host bridge drivers in arm associate MSI chip and > PCI bus by adding .add_bus(), and assign MSI chip pointer > to every PCI bus. Associating MSI chip and every PCI bus > is not necessary. All PCI busses under same PCI host brdige > share the same MSI chip. So saving MSI chip in pci_sys_data > is a better solution, it make PCI host bridge drivers clean. > Because we still need to provide arch spec pcibios_msi_controller() > to extract MSI controller pointer, a better solution is to > refactor PCI host bridge, make a generic pci_host_bridge, and > save common info like PCI domain number, MSI chip, resources > in it. We will do that work in another series as soon. > > To Bjorn: Because struct msi_chip defined in struct hw_pci and pci_sys_data > is under the #ifdef CONFIG_PCI_MSI, if we use if(IS_ENABLED(CONFIG_PCI_MSI)) > in PCI host bridge drivers, it will cause build errors when the CONFIG_PCI_MSI > is off. So I keep #ifdef CONFIG_PCI_MSI in this series. > > Yijing Wang (10): > MSI: Rename msi_chip to msi_controller for better readability > PCI/MSI: Introduce weak pcibios_msi_controller() > arm/MSI: Save MSI controller in pci_sys_data > PCI: tegra: Save MSI controller in pci_sys_data > PCI: designware: Save MSI controller in pci_sys_data > PCI: rcar: Save MSI controller in pci_sys_data > PCI: mvebu: Save MSI controller in pci_sys_data > PCI: xilinx: Save MSI controller in pci_sys_data > arm/PCI: Clean unused pcibios_add_bus() and pcibios_remove_bus() > PCI/MSI: Remove useless bus->msi assignment > > arch/arm/include/asm/mach/pci.h | 10 +--- > arch/arm/kernel/bios32.c| 28 ++-- > drivers/irqchip/irq-armada-370-xp.c | 22 +- > drivers/of/of_pci.c | 40 +- > drivers/pci/host/pci-keystone-dw.c |4 +- > drivers/pci/host/pci-keystone.h |2 +- > drivers/pci/host/pci-mvebu.c| 14 --- > drivers/pci/host/pci-tegra.c| 37 +--- > drivers/pci/host/pcie-designware.c | 25 +++-- > drivers/pci/host/pcie-designware.h |2 +- > drivers/pci/host/pcie-rcar.c| 37 +--- > drivers/pci/host/pcie-xilinx.c | 27 +++ > drivers/pci/msi.c | 22 ++- > drivers/pci/probe.c |1 - > include/linux/msi.h |6 ++-- > include/linux/of_pci.h | 14 ++-- > include/linux/pci.h |2 +- > 17 files changed, 132 insertions(+), 161 deletions(-) > Applied to pci/msi for v3.19, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.17 017/319] macvlan: fix a race on port dismantle and possible skb leaks
3.17-stable review patch. If anyone has any objections, please let me know.
--
From: Eric Dumazet
[ Upstream commit fe0ca7328d03d36aafecebb3af650e1bb2841c20 ]
We need to cancel the work queue after rcu grace period,
otherwise it can be rescheduled by incoming packets.
We need to purge queue if some skbs are still in it.
We can use __skb_queue_head_init() variant in
macvlan_process_broadcast()
Signed-off-by: Eric Dumazet
Fixes: 412ca1550cbec ("macvlan: Move broadcasts into a work queue")
Cc: Herbert Xu
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
---
drivers/net/macvlan.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -201,7 +201,7 @@ static void macvlan_process_broadcast(st
struct sk_buff *skb;
struct sk_buff_head list;
- skb_queue_head_init(&list);
+ __skb_queue_head_init(&list);
spin_lock_bh(&port->bc_queue.lock);
skb_queue_splice_tail_init(&port->bc_queue, &list);
@@ -941,9 +941,15 @@ static void macvlan_port_destroy(struct
{
struct macvlan_port *port = macvlan_port_get_rtnl(dev);
- cancel_work_sync(&port->bc_work);
dev->priv_flags &= ~IFF_MACVLAN_PORT;
netdev_rx_handler_unregister(dev);
+
+ /* After this point, no packet can schedule bc_work anymore,
+* but we need to cancel it and purge left skbs if any.
+*/
+ cancel_work_sync(&port->bc_work);
+ __skb_queue_purge(&port->bc_queue);
+
kfree_rcu(port, rcu);
}
--
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: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor
>I have almost verified all the micros parts for operating quad mode and the
>quad enable bit is
>volatile by default and no need to set it on software.
>Why this code is meant for - does micron has changed this bit operation on
>newly added parts?
>thanks!
>--
>Jagan.
For Micron Spi norflash,if you want to make it work Quad I/O mode,you can do it
by set
Two registers,Nonvolatile Configuration resister(NVCR) and Enhanced volatile
confuration register(EVCR),
but according to spi-nor.c,and micron spi nor,we recommend that if want to
enable Micron spi nor Quad I/O
mode,the best way is to set EVCR.
Of course,you can use Quad/Dual operation command to read/write Micron spi nor
in the spi nor Extended I/O mode.
But their command-address-data is different.
The purpose of this patch is only to enable Micron spi nor Quad I/O mode,if
want to make Micron spi nor work
Under Quad I/O mode.
Hi,Brian
How about this patch?Please give me some tips,thanks.
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
[PATCH 3.17 019/319] ipv4: Do not cache routing failures due to disabled forwarding.
3.17-stable review patch. If anyone has any objections, please let me know. -- From: Nicolas Cavallari [ Upstream commit fa19c2b050ab5254326f5fc07096dd3c6a8d5d58 ] If we cache them, the kernel will reuse them, independently of whether forwarding is enabled or not. Which means that if forwarding is disabled on the input interface where the first routing request comes from, then that unreachable result will be cached and reused for other interfaces, even if forwarding is enabled on them. The opposite is also true. This can be verified with two interfaces A and B and an output interface C, where B has forwarding enabled, but not A and trying ip route get $dst iif A from $src && ip route get $dst iif B from $src Signed-off-by: Nicolas Cavallari Reviewed-by: Julian Anastasov Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman --- net/ipv4/route.c |1 + 1 file changed, 1 insertion(+) --- a/net/ipv4/route.c +++ b/net/ipv4/route.c @@ -1798,6 +1798,7 @@ local_input: no_route: RT_CACHE_STAT_INC(in_no_route); res.type = RTN_UNREACHABLE; + res.fi = NULL; goto local_input; /* -- 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/
