Re: [PATCH 2/2] pinctrl: Introduce TI IOdelay configuration driver
* Paul Bolle [150304 14:58]:
> Nishanth Menon schreef op di 03-03-2015 om 18:00 [-0600]:
> > diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
> > index ee9f44ad7f02..8e463d75fbb2 100644
> > --- a/drivers/pinctrl/Kconfig
> > +++ b/drivers/pinctrl/Kconfig
> > @@ -160,6 +160,17 @@ config PINCTRL_TEGRA_XUSB
> > select PINCONF
> > select PINMUX
> >
> > +config PINCTRL_TI_IODELAY
> > + bool "TI IODelay Module pinconf driver"
>
> This adds a boolean Kconfig symbol.
>
> > + depends on OF
> > + select PINCONF
> > + select GENERIC_PINCONF
> > + select REGMAP_MMIO
> > + help
> > + Say Y here to support Texas Instruments' IODelay pinconf driver.
> > + IODelay module is used for the DRA7 SoC family. This driver is in
> > + addition to PINCTRL_SINGLE which controls the mux.
> > +
> > config PINCTRL_TZ1090
> > bool "Toumaz Xenif TZ1090 pin control driver"
> > depends on SOC_TZ1090
> > diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
> > index 0475206dd600..e441cd71aedf 100644
> > --- a/drivers/pinctrl/Makefile
> > +++ b/drivers/pinctrl/Makefile
> > @@ -28,6 +28,7 @@ obj-$(CONFIG_PINCTRL_TEGRA30) += pinctrl-tegra30.o
> > obj-$(CONFIG_PINCTRL_TEGRA114) += pinctrl-tegra114.o
> > obj-$(CONFIG_PINCTRL_TEGRA124) += pinctrl-tegra124.o
> > obj-$(CONFIG_PINCTRL_TEGRA_XUSB) += pinctrl-tegra-xusb.o
> > +obj-$(CONFIG_PINCTRL_TI_IODELAY) += pinctrl-ti-iodelay.o
>
> So this objectfile will either be built-in or not be built at all.
>
> > obj-$(CONFIG_PINCTRL_TZ1090) += pinctrl-tz1090.o
> > obj-$(CONFIG_PINCTRL_TZ1090_PDC) += pinctrl-tz1090-pdc.o
> > obj-$(CONFIG_PINCTRL_U300) += pinctrl-u300.o
> > diff --git a/drivers/pinctrl/pinctrl-ti-iodelay.c
> > b/drivers/pinctrl/pinctrl-ti-iodelay.c
> > new file mode 100644
> > index ..e4c6e25a781c
> > --- /dev/null
> > +++ b/drivers/pinctrl/pinctrl-ti-iodelay.c
> > @@ -0,0 +1,963 @@
> >[...]
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> This is, I think, a bit of a red flag.
>
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
>
> [...]
>
> > +static const struct of_device_id ti_iodelay_of_match[] = {
> > + {.compatible = "ti,dra7-iodelay", .data = &dra7_iodelay_data},
> > + { /* Hopefully no more.. */ },
> > +};
> > +MODULE_DEVICE_TABLE(of, ti_iodelay_of_match);
> > +
> > +static struct platform_driver ti_iodelay_driver = {
> > + .probe = ti_iodelay_probe,
> > + .remove = ti_iodelay_remove,
> > + .driver = {
> > + .owner = THIS_MODULE,
>
> So THIS_MODULE will, basically, be NULL.
>
> > + .name = DRIVER_NAME,
> > + .of_match_table = ti_iodelay_of_match,
> > + },
> > +};
> > +module_platform_driver(ti_iodelay_driver);
> > +
> > +MODULE_AUTHOR("Texas Instruments, Inc.");
> > +MODULE_DESCRIPTION("Pinconf driver for TI's IO Delay module");
> > +MODULE_LICENSE("GPL v2");
>
> And these three macros will be preprocessed away.
>
> (Perhaps there are non-modular alternatives to MODULE_DEVICE_TABLE and
> module_platform_driver, but I'm not sure how those two macros actually
> work.)
This should be just made to work as a regular loadable module.
We already have pinctrl-single for the same platforms working
as a loadable module.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] do_fork(): Rename 'stack_size' argument to reflect actual use
On Wed, 4 Mar 2015, Alex Dowad wrote:
> The 'stack_size' argument is never used to pass a stack size. It's only used
> when
> forking a kernel thread, in which case it is an argument which should be
> passed
> to the 'main' function which the kernel thread executes. Hence, rename it to
> 'kthread_arg'.
>
> Signed-off-by: Alex Dowad
> ---
>
> Hi,
>
> Please have a look at this patch. If this is accepted, I have a series of
> patches
> ready for a similar cleanup to all the arch-specific implementations of
> copy_thread()
> (as suggested by Andrew Morton in a private e-mail).
>
> Thank you,
> Alex Dowad
>
> kernel/fork.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/kernel/fork.c b/kernel/fork.c
> index cf65139..b38a2ae 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1186,10 +1186,12 @@ init_task_pid(struct task_struct *task, enum pid_type
> type, struct pid *pid)
> * It copies the registers, and all the appropriate
> * parts of the process environment (as per the clone
> * flags). The actual kick-off is left to the caller.
> + *
> + * When copying a kernel thread, 'stack_start' is the function to run.
> */
> static struct task_struct *copy_process(unsigned long clone_flags,
> unsigned long stack_start,
> - unsigned long stack_size,
> + unsigned long kthread_arg,
> int __user *child_tidptr,
> struct pid *pid,
> int trace)
> @@ -1401,7 +1403,7 @@ static struct task_struct *copy_process(unsigned long
> clone_flags,
> retval = copy_io(clone_flags, p);
> if (retval)
> goto bad_fork_cleanup_namespaces;
> - retval = copy_thread(clone_flags, stack_start, stack_size, p);
> + retval = copy_thread(clone_flags, stack_start, kthread_arg, p);
> if (retval)
> goto bad_fork_cleanup_io;
>
> @@ -1629,8 +1631,8 @@ struct task_struct *fork_idle(int cpu)
> * it and waits for it to finish using the VM if required.
> */
> long do_fork(unsigned long clone_flags,
> - unsigned long stack_start,
> - unsigned long stack_size,
> + unsigned long stack_start, /* or function for kthread to run */
> + unsigned long kthread_arg,
> int __user *parent_tidptr,
> int __user *child_tidptr)
> {
Looks fine, but I'm not sure about commenting functional formals. Since
copy_process() and do_fork() can have formals with different meanings,
then why not just rename them "arg1" and "arg2" respectively and then
define in the comment above the function what the possible combinations
are?
> @@ -1656,7 +1658,7 @@ long do_fork(unsigned long clone_flags,
> trace = 0;
> }
>
> - p = copy_process(clone_flags, stack_start, stack_size,
> + p = copy_process(clone_flags, stack_start, kthread_arg,
>child_tidptr, NULL, trace);
> /*
>* Do this prior waking up the new thread - the thread pointer
> @@ -1740,7 +1742,7 @@ SYSCALL_DEFINE5(clone, unsigned long, newsp, unsigned
> long, clone_flags,
>int, tls_val)
> #elif defined(CONFIG_CLONE_BACKWARDS3)
> SYSCALL_DEFINE6(clone, unsigned long, clone_flags, unsigned long, newsp,
> - int, stack_size,
> + int, ignored,
> int __user *, parent_tidptr,
> int __user *, child_tidptr,
> int, tls_val)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] mtd: nand: vf610_nfc: add device tree bindings
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
.../devicetree/bindings/mtd/vf610-nfc.txt | 38 ++
1 file changed, 38 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt
diff --git a/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
new file mode 100644
index 000..54207f8
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/vf610-nfc.txt
@@ -0,0 +1,38 @@
+Freescale's NAND flash controller (NFC)
+
+This variant of the Freescale NAND flash controller (NFC) is on Vybrid (vf610),
+MPC5125, MCF54418 and Kinetis K70.
+
+Required properties:
+- compatible: "fsl,vf610-nfc"
+- reg: Address range of the mtd chip
+- interrupts: Should contain the STMMAC interrupts
+- nand-bus-width: see nand.txt
+- nand-ecc-mode: see nand.txt
+- nand-on-flash-bbt: see nand.txt
+- clock-frequency : Optional clock rate to NFC in Hz
+- #address-cells, #size-cells : Must be present if the device has sub-nodes
+ representing partitions.
+
+Required properties for hardware ECC:
+- nand-ecc-strength: supported strengths are 24 and 32 (see nand.txt)
+- nand-ecc-step-size: step size equals page size, currently only 2k pages are
+ supported
+
+Example:
+
+ nfc: nand@400e {
+ compatible = "fsl,vf610-nfc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0x400e 0x4000>;
+ interrupts = ;
+ clocks = <&clks VF610_CLK_NFC>;
+ clock-names = "nfc";
+ clock-frequency = <3300>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+ nand-ecc-strength = <32>;
+ nand-ecc-step-size = <2048>;
+ };
--
2.3.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/5] ARM: dts: vf-colibri: enable NAND flash controller
Enable NAND access by adding pinmux and NAND flash controller node
to device tree. The NAND chips currently used on the Colibri VF61
requires 8-bit ECC per 512 byte page, hence specify 32-bit ECC
strength per 2k page size.
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf-colibri.dtsi | 31 +++
1 file changed, 31 insertions(+)
diff --git a/arch/arm/boot/dts/vf-colibri.dtsi
b/arch/arm/boot/dts/vf-colibri.dtsi
index 5c2b732..651d13f 100644
--- a/arch/arm/boot/dts/vf-colibri.dtsi
+++ b/arch/arm/boot/dts/vf-colibri.dtsi
@@ -46,6 +46,18 @@
pinctrl-0 = <&pinctrl_i2c0>;
};
+&nfc {
+ clock-frequency = <3300>;
+ nand-bus-width = <8>;
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+ nand-ecc-strength = <32>;
+ nand-ecc-step-size = <2048>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nfc_1>;
+ status = "okay";
+};
+
&pwm0 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_pwm0>;
@@ -141,6 +153,25 @@
>;
};
+ pinctrl_nfc_1: nfcgrp_1 {
+ fsl,pins = <
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ >;
+ };
+
pinctrl_pwm0: pwm0grp {
fsl,pins = <
VF610_PAD_PTB0__FTM0_CH00x1182
--
2.3.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 2/5] mtd: nand: vf610_nfc: add hardware BCH-ECC support
This adds hardware ECC support using the BCH encoder in the NFC IP.
The ECC encoder supports up to 32-bit correction by using 60 error
correction bytes. There is no sub-page ECC step, ECC is calculated
always accross the whole page (up to 2k pages).
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
drivers/mtd/nand/Kconfig | 6 +-
drivers/mtd/nand/vf610_nfc.c | 193 +--
2 files changed, 172 insertions(+), 27 deletions(-)
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 1be30a6..0fb97b3 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -464,8 +464,10 @@ config MTD_NAND_VF610_NFC
help
Enables support for NAND Flash Controller on some Freescale
processors like the VF610, MPC5125, MCF54418 or Kinetis K70.
- The driver supports a maximum 2k page size. The driver
- currently does not support hardware ECC.
+ The driver supports a maximum 2k page size. With 2k pages and
+ 64 bytes or more of OOB, hardware ECC with up to 32-bit error
+ correction is supported. Hardware ECC is only enabled through
+ device tree.
config MTD_NAND_MXC
tristate "MXC NAND support"
diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c
index 101fd20..c6fb379 100644
--- a/drivers/mtd/nand/vf610_nfc.c
+++ b/drivers/mtd/nand/vf610_nfc.c
@@ -19,6 +19,7 @@
* - Untested on MPC5125 and M54418.
* - DMA not used.
* - 2K pages or less.
+ * - Only 2K page w. 64+OOB and hardware ECC.
*/
#include
@@ -71,6 +72,8 @@
/* NFC ECC mode define */
#define ECC_BYPASS 0
+#define ECC_45_BYTE6
+#define ECC_60_BYTE7
/*** Register Mask and bit definitions */
@@ -103,6 +106,8 @@
#define STATUS_BYTE1_MASK 0x00FF
/* NFC_FLASH_CONFIG Field */
+#define CONFIG_ECC_SRAM_ADDR_MASK 0x7FC0
+#define CONFIG_ECC_SRAM_ADDR_SHIFT 22
#define CONFIG_ECC_SRAM_REQ_BIT(1<<21)
#define CONFIG_DMA_REQ_BIT (1<<20)
#define CONFIG_ECC_MODE_MASK 0x000E
@@ -123,13 +128,32 @@
#define NFC_TIMEOUT(HZ)
+/* ECC status placed at end of buffers. */
+#define ECC_SRAM_ADDR ((PAGE_2K+256-8) >> 3)
+#define ECC_STATUS_MASK0x80
+#define ECC_ERR_COUNT 0x3F
+
+/*
+ * ECC status is stored at NFC_CFG[ECCADD] +4 for little-endian
+ * and +7 for big-endian SoCs.
+ */
+#ifdef CONFIG_SOC_VF610
+#define ECC_OFFSET 4
+#else
+#define ECC_OFFSET 7
+#endif
+
struct vf610_nfc_config {
+ bool hardware_ecc;
+ int ecc_strength;
+ int ecc_step_size;
int width;
int flash_bbt;
u32 clkrate;
+ u32 ecc_mode;
};
-struct fsl_nfc {
+struct vf610_nfc {
struct mtd_infomtd;
struct nand_chip chip;
struct device *dev;
@@ -149,27 +173,32 @@ struct fsl_nfc {
#define mtd_to_nfc(_mtd) container_of(_mtd, struct vf610_nfc, mtd)
-static u8 bbt_pattern[] = {'B', 'b', 't', '0' };
-static u8 mirror_pattern[] = {'1', 't', 'b', 'B' };
-
-static struct nand_bbt_descr bbt_main_descr = {
- .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
- NAND_BBT_2BIT | NAND_BBT_VERSION,
- .offs = 11,
- .len = 4,
- .veroffs = 15,
- .maxblocks = 4,
- .pattern = bbt_pattern,
+static struct nand_ecclayout vf610_nfc_ecc45 = {
+ .eccbytes = 45,
+ .eccpos = {19, 20, 21, 22, 23,
+ 24, 25, 26, 27, 28, 29, 30, 31,
+ 32, 33, 34, 35, 36, 37, 38, 39,
+ 40, 41, 42, 43, 44, 45, 46, 47,
+ 48, 49, 50, 51, 52, 53, 54, 55,
+ 56, 57, 58, 59, 60, 61, 62, 63},
+ .oobfree = {
+ {.offset = 2,
+.length = 17} }
};
-static struct nand_bbt_descr bbt_mirror_descr = {
- .options = NAND_BBT_LASTBLOCK | NAND_BBT_CREATE | NAND_BBT_WRITE |
- NAND_BBT_2BIT | NAND_BBT_VERSION,
- .offs = 11,
- .len = 4,
- .veroffs = 15,
- .maxblocks = 4,
- .pattern = mirror_pattern,
+static struct nand_ecclayout vf610_nfc_ecc60 = {
+ .eccbytes = 60,
+ .eccpos = { 4, 5, 6, 7, 8, 9, 10, 11,
+ 12, 13, 14, 15, 16, 17, 18, 19,
+ 20, 21, 22, 23, 24, 25, 26, 27,
+ 28, 29, 30, 31, 32, 33, 34, 35,
+ 36, 37, 38, 39, 40, 41, 42, 43,
+ 44, 45, 46, 47, 48, 49, 50, 51,
+ 52, 53, 54, 55, 56, 57, 58, 59,
+ 60, 61, 62, 63 },
+ .oobfree = {
+ {.offset = 2,
+.length = 2} }
};
static inline u32 vf610_nfc_read(struct vf610_nfc *nfc, uint reg)
@@ -470,6 +499,60 @@ static void vf610_nfc_select_chip(struct mtd_info *mtd,
int chip)
#endif
}
+/* Count the number of 0's in
[PATCH 0/5] mtd: nand: vf610_nfc: Freescale NFC for VF610
This adds support for Freescale NAND flash controller (NFC) found on various devices such as Vybrid (VF610), MPC5125, MCF54418 (ColdFire) and Kinetis K70. The patchset is based on the patchset by Bill Pringlemeir, see: http://thread.gmane.org/gmane.linux.ports.arm.kernel/295419 A variant of this driver is in upstream U-Boot now. During this process, various points have been discussed and changed. Those changes are also incorporated in this patchset, including the change to the name "vf610_nfc" (discussion in first patchset). http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/192465 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/193142 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/193351 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/195441 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/195513 MTD tests worked, except mtd_nandecctest.ko: The test stopped already after changing the first bit. I guess this is due to not properly working raw page read/write implementation. However, implementing those functions is not feasible since ECC is always done on-the-fly. Performance keypoints (slightly less for page write/reads): [ 1782.284398] mtd_speedtest: testing eraseblock write speed [ 1963.472907] mtd_speedtest: eraseblock write speed is 2877 KiB/s [ 1963.478913] mtd_speedtest: testing eraseblock read speed [ 2004.906267] mtd_speedtest: eraseblock read speed is 12586 KiB/s The driver has only been tested on Freescale Vybrid. Tests on other platforms welcome, especially on big endian architectures... Changes since RFC (Bill Pringlemeir): - Renamed driver from fsl_nfc to vf610_nfc - Use readl/writel for all register in accessor functions - Optimized field accessor functions - Implemented PM (suspend/resume) functions - Implemented basic support for ECC strength/ECC step size from dt - Improved performance of count_written_bits by using hweight32 - Support ECC with 60-bytes to correct up to 32 bit errors - Changed to in-band BBT (NAND_BBT_NO_OOB) which also allows ECC modes which uses up to 60 bytes on 64 byte OOB - Removed custom (downstream) BBT pattern since BBT table won't be compatible anyway (due to the change above) Stefan Agner (5): mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others mtd: nand: vf610_nfc: add hardware BCH-ECC support mtd: nand: vf610_nfc: add device tree bindings ARM: dts: vf610: add NAND flash controller peripherial ARM: dts: vf-colibri: enable NAND flash controller .../devicetree/bindings/mtd/vf610-nfc.txt | 38 + arch/arm/boot/dts/vf-colibri.dtsi | 31 + arch/arm/boot/dts/vf500.dtsi | 4 + arch/arm/boot/dts/vf610-twr.dts| 43 + arch/arm/boot/dts/vfxxx.dtsi | 7 + arch/arm/mach-imx/Kconfig | 1 + drivers/mtd/nand/Kconfig | 14 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/vf610_nfc.c | 873 + 9 files changed, 1012 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/vf610-nfc.txt create mode 100644 drivers/mtd/nand/vf610_nfc.c -- 2.3.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] keyboard/tc3589x-keypad.c: set IRQF_ONESHOT flag to ensure IRQ request
On Mon, Mar 02, 2015 at 04:21:06PM +0100, Valentin Rothberg wrote:
> Since commit 1c6c69525b40eb76de8adf039409722015927dc3 ("genirq: Reject
> bogus threaded irq requests") threaded IRQs without a primary handler
> need to be requested with IRQF_ONESHOT, otherwise the request will fail.
>
> Currently, plat->irqtype is only set to IRQF_TRIGGER_FALLING. This
> patch sets the ONESHOT flag directly in request_threaded_irq() to
> enforce the flag without being affected by future changes to
> plat->irqtype.
>
> Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci
>
> Signed-off-by: Valentin Rothberg
Applied, thank you.
> ---
> drivers/input/keyboard/tc3589x-keypad.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/keyboard/tc3589x-keypad.c
> b/drivers/input/keyboard/tc3589x-keypad.c
> index 8ff612d..5639325 100644
> --- a/drivers/input/keyboard/tc3589x-keypad.c
> +++ b/drivers/input/keyboard/tc3589x-keypad.c
> @@ -411,9 +411,9 @@ static int tc3589x_keypad_probe(struct platform_device
> *pdev)
>
> input_set_drvdata(input, keypad);
>
> - error = request_threaded_irq(irq, NULL,
> - tc3589x_keypad_irq, plat->irqtype,
> - "tc3589x-keypad", keypad);
> + error = request_threaded_irq(irq, NULL, tc3589x_keypad_irq,
> + plat->irqtype | IRQF_ONESHOT,
> + "tc3589x-keypad", keypad);
> if (error < 0) {
> dev_err(&pdev->dev,
> "Could not allocate irq %d,error %d\n",
> --
> 1.9.1
>
--
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] ARM: dts: vf610: add NAND flash controller peripherial
This adds the NAND flash controller (NFC) peripherial. The driver
supports the SLC NAND chips found on Freescale's Vybrid Tower System
Module. The Micron NAND chip on the module needs 4-bit ECC per 512
byte page. Use 24-bit ECC per 2k page, which is supported by the
driver.
Signed-off-by: Bill Pringlemeir
Signed-off-by: Stefan Agner
---
arch/arm/boot/dts/vf500.dtsi| 4
arch/arm/boot/dts/vf610-twr.dts | 43 +
arch/arm/boot/dts/vfxxx.dtsi| 7 +++
3 files changed, 54 insertions(+)
diff --git a/arch/arm/boot/dts/vf500.dtsi b/arch/arm/boot/dts/vf500.dtsi
index 1dbf8d2..1aa1e47 100644
--- a/arch/arm/boot/dts/vf500.dtsi
+++ b/arch/arm/boot/dts/vf500.dtsi
@@ -118,6 +118,10 @@
interrupts = ;
};
+&nfc {
+ interrupts = ;
+};
+
&pit {
interrupts = ;
};
diff --git a/arch/arm/boot/dts/vf610-twr.dts b/arch/arm/boot/dts/vf610-twr.dts
index f64fddc..704564e 100644
--- a/arch/arm/boot/dts/vf610-twr.dts
+++ b/arch/arm/boot/dts/vf610-twr.dts
@@ -287,6 +287,49 @@
status = "okay";
};
+&iomuxc {
+ vf610-twr {
+ pinctrl_nfc_1: nfcgrp_1 {
+ fsl,pins = <
+ VF610_PAD_PTD31__NF_IO150x28df
+ VF610_PAD_PTD30__NF_IO140x28df
+ VF610_PAD_PTD29__NF_IO130x28df
+ VF610_PAD_PTD28__NF_IO120x28df
+ VF610_PAD_PTD27__NF_IO110x28df
+ VF610_PAD_PTD26__NF_IO100x28df
+ VF610_PAD_PTD25__NF_IO9 0x28df
+ VF610_PAD_PTD24__NF_IO8 0x28df
+ VF610_PAD_PTD23__NF_IO7 0x28df
+ VF610_PAD_PTD22__NF_IO6 0x28df
+ VF610_PAD_PTD21__NF_IO5 0x28df
+ VF610_PAD_PTD20__NF_IO4 0x28df
+ VF610_PAD_PTD19__NF_IO3 0x28df
+ VF610_PAD_PTD18__NF_IO2 0x28df
+ VF610_PAD_PTD17__NF_IO1 0x28df
+ VF610_PAD_PTD16__NF_IO0 0x28df
+ VF610_PAD_PTB24__NF_WE_B0x28c2
+ VF610_PAD_PTB25__NF_CE0_B 0x28c2
+ VF610_PAD_PTB27__NF_RE_B0x28c2
+ VF610_PAD_PTC26__NF_RB_B0x283d
+ VF610_PAD_PTC27__NF_ALE 0x28c2
+ VF610_PAD_PTC28__NF_CLE 0x28c2
+ >;
+ };
+ };
+};
+
+&nfc {
+ clock-frequency = <3300>;
+ nand-bus-width = <16>;
+ nand-ecc-mode = "hw";
+ nand-on-flash-bbt;
+ nand-ecc-strength = <24>;
+ nand-ecc-step-size = <2048>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_nfc_1>;
+ status = "okay";
+};
+
&uart1 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart1>;
diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index a29c7ce..03b4b55 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -458,6 +458,13 @@
status = "disabled";
};
+ nfc: nand@400e {
+ compatible = "fsl,vf610-nfc";
+ reg = <0x400e 0x4000>;
+ clocks = <&clks VF610_CLK_NFC>;
+ clock-names = "nfc";
+ status = "disabled";
+ };
};
};
};
--
2.3.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 1/5] mtd: nand: vf610_nfc: Freescale NFC for VF610, MPC5125 and others
This driver supports Freescale NFC (NAND flash controller) found on Vybrid (VF610), MPC5125, MCF54418 and Kinetis K70. Limitations: - DMA and pipelining not used - Pages larger than 2k are not supported - No hardware ECC The driver has only been tested on Vybrid (VF610). Signed-off-by: Bill Pringlemeir Signed-off-by: Stefan Agner --- arch/arm/mach-imx/Kconfig| 1 + drivers/mtd/nand/Kconfig | 12 + drivers/mtd/nand/Makefile| 1 + drivers/mtd/nand/vf610_nfc.c | 730 +++ 4 files changed, 744 insertions(+) create mode 100644 drivers/mtd/nand/vf610_nfc.c diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig index e8627e0..de4a51a 100644 --- a/arch/arm/mach-imx/Kconfig +++ b/arch/arm/mach-imx/Kconfig @@ -634,6 +634,7 @@ config SOC_VF610 select ARM_GIC select PINCTRL_VF610 select PL310_ERRATA_769419 if CACHE_L2X0 + select HAVE_NAND_VF610_NFC help This enable support for Freescale Vybrid VF610 processor. diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 5b76a17..1be30a6 100644 --- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -455,6 +455,18 @@ config MTD_NAND_MPC5121_NFC This enables the driver for the NAND flash controller on the MPC5121 SoC. +config HAVE_NAND_VF610_NFC + bool + +config MTD_NAND_VF610_NFC + tristate "Support for Freescale NFC for VF610/MPC5125" + depends on HAVE_NAND_VF610_NFC + help + Enables support for NAND Flash Controller on some Freescale + processors like the VF610, MPC5125, MCF54418 or Kinetis K70. + The driver supports a maximum 2k page size. The driver + currently does not support hardware ECC. + config MTD_NAND_MXC tristate "MXC NAND support" depends on ARCH_MXC diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index 582bbd05..e97ca7b 100644 --- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -45,6 +45,7 @@ obj-$(CONFIG_MTD_NAND_SOCRATES) += socrates_nand.o obj-$(CONFIG_MTD_NAND_TXX9NDFMC) += txx9ndfmc.o obj-$(CONFIG_MTD_NAND_NUC900) += nuc900_nand.o obj-$(CONFIG_MTD_NAND_MPC5121_NFC) += mpc5121_nfc.o +obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o obj-$(CONFIG_MTD_NAND_RICOH) += r852.o obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/ diff --git a/drivers/mtd/nand/vf610_nfc.c b/drivers/mtd/nand/vf610_nfc.c new file mode 100644 index 000..101fd20 --- /dev/null +++ b/drivers/mtd/nand/vf610_nfc.c @@ -0,0 +1,730 @@ +/* + * Copyright 2009-2015 Freescale Semiconductor, Inc. and others + * + * Description: MPC5125, VF610, MCF54418 and Kinetis K70 Nand driver. + * Jason ported to M54418TWR and MVFA5 (VF610). + * Authors: Stefan Agner + * Bill Pringlemeir + * Shaohui Xie + * Jason Jin + * + * Based on original driver mpc5121_nfc.c. + * + * This 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. + * + * Limitations: + * - Untested on MPC5125 and M54418. + * - DMA not used. + * - 2K pages or less. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#defineDRV_NAME"vf610_nfc" + +/* Register Offsets */ +#define NFC_FLASH_CMD1 0x3F00 +#define NFC_FLASH_CMD2 0x3F04 +#define NFC_COL_ADDR 0x3F08 +#define NFC_ROW_ADDR 0x3F0c +#define NFC_ROW_ADDR_INC 0x3F14 +#define NFC_FLASH_STATUS1 0x3F18 +#define NFC_FLASH_STATUS2 0x3F1c +#define NFC_CACHE_SWAP 0x3F28 +#define NFC_SECTOR_SIZE0x3F2c +#define NFC_FLASH_CONFIG 0x3F30 +#define NFC_IRQ_STATUS 0x3F38 + +/* Addresses for NFC MAIN RAM BUFFER areas */ +#define NFC_MAIN_AREA(n) ((n) * 0x1000) + +#define PAGE_2K0x0800 +#define OOB_64 0x0040 + +/* + * NFC_CMD2[CODE] values. See section: + * - 31.4.7 Flash Command Code Description, Vybrid manual + * - 23.8.6 Flash Command Sequencer, MPC5125 manual + * + * Briefly these are bitmasks of controller cycles. + */ +#define READ_PAGE_CMD_CODE 0x7EE0 +#define PROGRAM_PAGE_CMD_CODE 0x7FC0 +#define ERASE_CMD_CODE 0x4EC0 +#define READ_ID_CMD_CODE 0x4804 +#define RESET_CMD_CODE 0x4040 +#define STATUS_READ_CMD_CODE 0x4068 + +/* NFC ECC mode define */ +#define ECC_BYPASS 0 + +/*** Register Mask and bit definitions */ + +/* NFC_FLASH_CMD1 Field */ +#define
RE: [PATCH v4] x86: mce: kexec: switch MCE handler for kexec/kdump
> - fixed AR and UC order in enum severity_level because UC is severer than AR > by definition. Current code is not affected by this wrong order by chance. AR and AO are both UC errors - that happen also to be recoverable. Are you really sure about this re-order not affecting existing code? You might well be right, but as every one else has pointed out mce_severity() is full of odd subtleties that catch people out. Is the "UC" entry at the end of the severities[] table just a catch-all for things that made it past all the other entries? Does it ever really get used? What was the test case that made you promote UC above AR? This absolutely should not be buried in the middle of your other patch - it needs to be separate with a much more than two lines of commit description. -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] mmc: sdhci-iproc: add device tree bindings
Hi Florian, On 15-03-02 03:50 PM, Florian Fainelli wrote: Unless there is a re-spin, I will fix this myself while applying this patch to devicetree/next. Thanks Yes, you can patch the formatting if the driver is being integrated. But I have had no response or feedback on the sdhci driver. It has been sitting for 1 month. -- 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 9/9] change the relocations behavior for kaslr on x86_64
On Mon, Mar 2, 2015 at 6:58 AM, Baoquan He wrote:
> @@ -455,17 +455,16 @@ unsigned char *choose_kernel_location(struct
> boot_params *params,
>output_size);
you forgot to change
/* Record the various known unsafe memory ranges. */
mem_avoid_init((unsigned long)input, input_size,
(unsigned long)output, init_size);
to
/* Record the various known unsafe memory ranges. */
mem_avoid_init((unsigned long)input, input_size,
(unsigned long)*output, init_size);
>
> /* Walk e820 and find a random address. */
> - random = find_random_addr(choice, output_size);
> - if (!random) {
> + random = find_random_phy_addr((unsigned long)*output, output_size);
> + if (!random)
> debug_putstr("KASLR could not find suitable E820
> region...\n");
> - goto out;
> - }
> + else
> + *output = (unsigned char*)random;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/6] mm: Change ioremap to set up huge I/O mappings
On Wed, 2015-03-04 at 23:09 +0100, Ingo Molnar wrote: > * Toshi Kani wrote: : > Hm, so I don't see where you set the proper x86 PAT table attributes > for the pmds. > > MTRR's are basically a legacy mechanism, the proper way to set cache > attribute is PAT and I don't see where this generic code does that, > but I might be missing something? It's done by x86 code, not by this generic code. __ioremap_caller() takes page_cache_mode and converts it to pgprot_t using the PAT table attribute. It then calls this generic func, ioremap_page_range(). When creating a huge page mapping, pud_set_huge() and pmd_set_huge() handle the relocation of the PAT bit. Thanks, -Toshi -- 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 v9 00/21] Introduce ACPI for ARM64 based on ACPI 5.1
On 02/27/2015 02:50 AM, Ard Biesheuvel wrote: Are you not seeing this on v4.0-rc1 without the patchset applied? Could the crash be inside the subsequent call to SetVirtualAddressMap() instead of inside ExitBootServices()? If so, you have a firmware bug: Mark Rutland spotted a similar bug in the AMD Seattle firmware, which has been fixed in the mean time. It has to do with the firmware dereferencing the virtual mapping as it is being installed, which violates the UEFI spec. It looks like you are right. We fixed the bug in our UEFI and now this patchset works. So all 21 patches: Tested-by: Timur Tabi However, I did notice one thing. Booting the kernel displays this line: [ 69.424001] Failed to find cpu0 device node That's because CONFIG_OF is still defined (part of "config ARM64"), and therefore cache_setup_of_node() attempts to get the cache information from the device tree. Should CONFIG_OF still be defined? -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] ARM: at91: switch to multiplatform
Alexandre Belloni schreef op wo 04-03-2015 om 15:47 [+0100]: > --- a/arch/arm/mach-at91/Kconfig > +++ b/arch/arm/mach-at91/Kconfig > @@ -1,51 +1,22 @@ > -if ARCH_AT91 > - > -config HAVE_AT91_UTMI > - bool > - > -config HAVE_AT91_USB_CLK > - bool > - > -config COMMON_CLK_AT91 > - bool > - select COMMON_CLK > - > -config HAVE_AT91_SMD > - bool > - > -config HAVE_AT91_H32MX > - bool > - > -config SOC_SAMA5 > - bool > - select ATMEL_AIC5_IRQ > +config ARCH_AT91 > + select ARCH_REQUIRE_GPIOLIB > select COMMON_CLK_AT91 > - select CPU_V7 > + select CLKDEV_LOOKUP > select GENERIC_CLOCKEVENTS > - select MEMORY > - select ATMEL_SDRAMC > - select PHYLIB if NETDEVICES > - > -menu "Atmel AT91 System-on-Chip" > - > -choice > - > - prompt "Core type" > - > -config SOC_SAM_V4_V5 > - bool "ARM9 AT91SAM9/AT91RM9200" > - help > - Select this if you are using one of Atmel's AT91SAM9 or > - AT91RM9200 SoC. > + select IRQ_DOMAIN > + select NEED_MACH_IO_H if PCCARD > + select PINCTRL > + select PINCTRL_AT91 > + select SOC_BUS > + select USE_OF > + bool Utterly trivial, but anyhow. Could you please make this bool line to be the line directly following the line reading config ARCH_AT91 above? > -config SOC_SAM_V7 > - bool "Cortex A5" > +menuconfig SOC_SAM_V7 > + bool "Atmel SAMA5" if ARCH_MULTI_V7 > + select ARCH_AT91 > help > - Select this if you are using one of Atmel's SAMA5D3 SoC. > - > -endchoice > - > -comment "Atmel AT91 Processor" > + This enables support for systems based on Atmel > + SAMA5D3 or SAMA5D4 SoCs. > > if SOC_SAM_V7 > config SOC_SAMA5D3 > @@ -71,25 +42,29 @@ config SOC_SAMA5D4 > select HAVE_AT91_H32MX > help > Select this if you are using one of Atmel's SAMA5D4 family SoC. > -endif > +endif # SOC_SAM_V7 > + > + > +menuconfig SOC_SAM_V4_V5 > + bool "Atmel ARM9 AT91SAM9/AT91RM9200" if ARCH_MULTI_V4_V5 > + select ARCH_AT91 > + help > + Select this if you are using one of Atmel's AT91SAM9 or > + AT91RM9200 SoC. > > if SOC_SAM_V4_V5 > config SOC_AT91RM9200 > - bool "AT91RM9200" > + bool "AT91RM9200" if ARCH_MULTI_V4T > select ATMEL_AIC_IRQ > - select COMMON_CLK_AT91 > select CPU_ARM920T > - select GENERIC_CLOCKEVENTS > select HAVE_AT91_USB_CLK > select MIGHT_HAVE_PCI > > config SOC_AT91SAM9 > - bool "AT91SAM9" > + bool "AT91SAM9" if ARCH_MULTI_V5 > select ATMEL_AIC_IRQ > select ATMEL_SDRAMC > - select COMMON_CLK_AT91 > select CPU_ARM926T > - select GENERIC_CLOCKEVENTS > select HAVE_AT91_SMD > select HAVE_AT91_USB_CLK > select HAVE_AT91_UTMI > @@ -115,6 +90,34 @@ config SOC_AT91SAM9 > AT91SAM9XE > endif # SOC_SAM_V4_V5 > > +if ARCH_AT91 > + > +config HAVE_AT91_UTMI > + bool > + > +config HAVE_AT91_USB_CLK > + bool > + > +config COMMON_CLK_AT91 > + bool > + select COMMON_CLK > + > +config HAVE_AT91_SMD > + bool > + > +config HAVE_AT91_H32MX > + bool > + > +config SOC_SAMA5 > + bool > + select ATMEL_AIC5_IRQ > + select CPU_V7 > + select MEMORY > + select ATMEL_SDRAMC > + select PHYLIB if NETDEVICES > + > +menu "Atmel AT91 common options" > + > comment "AT91 Feature Selections" > > config AT91_SLOW_CLOCK > @@ -132,12 +135,12 @@ config AT91_SLOW_CLOCK > need to be completely re-initialized. > > config AT91_TIMER_HZ > - int "Kernel HZ (jiffies per second)" > - range 32 1024 > - depends on ARCH_AT91 > - default "128" if SOC_AT91RM9200 > - default "100" > - help > + int "Kernel HZ (jiffies per second)" > + range 32 1024 > + depends on ARCH_AT91 > + default "128" if SOC_AT91RM9200 > + default "100" > + help > On AT91rm9200 chips where you're using a system clock derived > from the 32768 Hz hardware clock, this tick rate should divide > it exactly: use a power-of-two value, such as 128 or 256, to Thanks, Paul Bolle -- 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] pinctrl: imx: do not implicitly set pin regs to -1
On 2015-03-02 16:53, Uwe Kleine-König wrote:
> Hello,
>
> On Mon, Mar 02, 2015 at 02:42:01PM +0100, Stefan Agner wrote:
>> On 2015-03-02 13:59, Uwe Kleine-König wrote:
>> > On Mon, Mar 02, 2015 at 07:45:17PM +0800, Shawn Guo wrote:
>> >> On Fri, Feb 06, 2015 at 05:30:56PM +0100, Stefan Agner wrote:
>> >> > Commit 3dac1918a491 ("pinctrl: imx: detect uninitialized pins") needs
>> >> > the values in struct imx_pin_reg to be -1. This has been done in a
>> >> > rather unorthodox way by setting the memory to 0xff using memset...
>> >> > Use a proper for loop to initialize the whole array with -1.
>> >> >
>> >> > Signed-off-by: Stefan Agner
>> >>
>> >> Acked-by: Shawn Guo
>> > too late. This patch is part of 4.0-rc1 (4ff0f034e95d).
>>
>> This is not the same patch. The patch you are mentioning is actually
>> fixing a bug introduce in the change where we set -1 for uninitialized
>> pins. This patch is solving the weird assignment of the initial value...
> ah right.
Do you generally agree to that change?
@Linus Walleij, anything holding this patch back from getting merged?
--
Stefan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] firmware_class: Add firmware filename overrides
This patch adds an additional feature to the firmware_class.c module.
To allow a unified method of specifying new firmware locations when
drivers request a firmware binary to update their devices with, we
have added the concept of a "fw override"
A fw override is a rule that matches firmware requests based on the
name of the device requesting the fw and what the filename for the
fw they are requesting is, and overrides their requests with a new
value.
Overrides are set up by piping a description of the override into
an attribute set up at /sys/class/firmware/fw_override. The string
should be a null-deliminited list of the firmware name you want to
over ride, the new name to replace it with, and the device name that
you want the override to apply to. For example you could set up
an override for a device called "my_device" so that any time it
requests a firmware called "my_fw.bin" it instead gets "new_fw.bin"
with the following command:
echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' >
/sys/class/firmware/fw_override
The device name is an optional field, and if no string is there it
will apply to ANY device requesting a firmware of that name. For
example if you want all devices looking for my_fw.bin to get
new_fw.bin instead you might use this command:
echo -e 'my_fw.bin\0new_fw.bin\0\0' > /sys/class/firmware/fw_override
Existing overrides can be viewed by cat-ing that attribute and can
be overwritten with new rules at will.
To delete an override simply put an empty string in the new firmware
field and the matching rule will be removed. eg: to remove the rule
set up in the first above example, one might run this command.
echo -e 'my_fw.bin\0\0my_device\0' > /sys/class/firmware/fw_override
Note: To make this feature usable even when CONFIG_FW_LOADER_USER_HELPER
is not set, the firmware class is brought back. However, "timeout"
and the other functionality remain disabled.
Signed-off-by: Charlie Mooney
---
drivers/base/firmware_class.c | 196 ++
1 file changed, 180 insertions(+), 16 deletions(-)
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
index 6c5c9ed..863ced5 100644
--- a/drivers/base/firmware_class.c
+++ b/drivers/base/firmware_class.c
@@ -440,6 +440,163 @@ static int fw_add_devm_name(struct device *dev, const
char *name)
}
#endif
+struct fw_override {
+ struct list_head node;
+ const char *old_name;
+ const char *new_name;
+ const char *device_name;
+};
+static LIST_HEAD(fw_override_list);
+
+/*
+ * find_fw_override -- Find the override for the fw name and device specified
+ *
+ * Given a fw filename and the devices's name, this function finds the fw
+ * override assigned to it (if one exists).
+ *
+ * Returns a pointer to the fw_override struct in question or NULL if it
+ * does not exist.
+ */
+static struct fw_override *find_fw_override(const char *fw_name,
+const char *device_name)
+{
+ struct fw_override *override;
+
+ if (!fw_name)
+ return NULL;
+
+ list_for_each_entry(override, &fw_override_list, node) {
+ if (!strcmp(override->old_name, fw_name) &&
+ (!device_name ||
+!strcmp(device_name, override->device_name))) {
+ return override;
+ }
+ }
+ return NULL;
+}
+
+/* Determine what is the actual filename that should be loaded for a given
+ * firmware and device. If there is no overrides in place for this device
+ * and firmware, then the name will be returned unchanged. Otherwise, the
+ * overridden firmware name is returned.
+ *
+ * This is called from _request_firmware() to make sure that overrides are
+ * applied to every firmware request regardless of how the request is made.
+ */
+static const char *firmware_overridden_name(const char *name,
+ struct device *device)
+{
+ struct fw_override *override;
+
+ /* Check first for device-specific overrides, before checking for more
+* generic overrides that might apply to this device.
+*/
+ override = find_fw_override(name, dev_name(device));
+ if (!override)
+ override = find_fw_override(name, NULL);
+
+ if (override)
+ dev_info(device, "firmware: '%s' overridden to '%s'.\n",
+ name, override->new_name);
+
+ return override ? override->new_name : name;
+}
+
+
+/*
+ * delete_fw_override -- Remove an override for the fw
+ *
+ * Given a firmware filename and the device name, remove any overrides that may
+ * have been set for it. If the device name is NULL, then this looks only for
+ * global overrides.
+ */
+static void delete_fw_override(const char *fw_name, const char *device_name)
+{
+ struct fw_override *to_delete;
+
+ to_delete = find_fw_override(fw_name, device_name);
+
Re: [PATCH v3 6/6 UPDATE] x86, mm: Support huge KVA mappings on x86
Toshi Kani schreef op di 03-03-2015 om 16:48 [-0700]: > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -99,6 +99,7 @@ config X86 > select IRQ_FORCED_THREADING > select HAVE_BPF_JIT if X86_64 > select HAVE_ARCH_TRANSPARENT_HUGEPAGE > + select HAVE_ARCH_HUGE_VMAP if X86_64 || (X86_32 && X86_PAE) Minor nit: X86_PAE depends on X86_32, so I think this could be just select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE > select ARCH_HAS_SG_CHAIN > select CLKEVT_I8253 > select ARCH_HAVE_NMI_SAFE_CMPXCHG Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [regression v4.0-rc1] mm: IPIs from TLB flushes causing significant performance degradation.
* Dave Chinner wrote: > > After going through the series again, I did not spot why there is > > a difference. It's functionally similar and I would hate the > > theory that this is somehow hardware related due to the use of > > bits it takes action on. > > I doubt it's hardware related - I'm testing inside a VM, [...] That might be significant, I doubt Mel considered KVM's interpretation of pte details? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] ARM: at91: switch to multiplatform
On 05/03/2015 at 00:21:47 +0100, Paul Bolle wrote : > > +config ARCH_AT91 > > + select ARCH_REQUIRE_GPIOLIB > > select COMMON_CLK_AT91 > > - select CPU_V7 > > + select CLKDEV_LOOKUP > > select GENERIC_CLOCKEVENTS > > - select MEMORY > > - select ATMEL_SDRAMC > > - select PHYLIB if NETDEVICES > > - > > -menu "Atmel AT91 System-on-Chip" > > - > > -choice > > - > > - prompt "Core type" > > - > > -config SOC_SAM_V4_V5 > > - bool "ARM9 AT91SAM9/AT91RM9200" > > - help > > - Select this if you are using one of Atmel's AT91SAM9 or > > - AT91RM9200 SoC. > > + select IRQ_DOMAIN > > + select NEED_MACH_IO_H if PCCARD > > + select PINCTRL > > + select PINCTRL_AT91 > > + select SOC_BUS > > + select USE_OF > > + bool > > Utterly trivial, but anyhow. Could you please make this > bool > > line to be the line directly following the line reading > config ARCH_AT91 > > above? > I can definitely do that, is your parser relying on it? :) -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/6 UPDATE] x86, mm: Support huge KVA mappings on x86
On Thu, 2015-03-05 at 00:31 +0100, Paul Bolle wrote: > Toshi Kani schreef op di 03-03-2015 om 16:48 [-0700]: > > --- a/arch/x86/Kconfig > > +++ b/arch/x86/Kconfig > > @@ -99,6 +99,7 @@ config X86 > > select IRQ_FORCED_THREADING > > select HAVE_BPF_JIT if X86_64 > > select HAVE_ARCH_TRANSPARENT_HUGEPAGE > > + select HAVE_ARCH_HUGE_VMAP if X86_64 || (X86_32 && X86_PAE) > > Minor nit: X86_PAE depends on X86_32, so I think this could be just > select HAVE_ARCH_HUGE_VMAP if X86_64 || X86_PAE Right. I will update in the next version. Thanks, -Toshi -- 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 00/53] 3.10.71-stable review
On 03/03/2015 11:06 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.71 release. > There are 53 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 Mar 6 05:45:30 UTC 2015. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.71-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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 00/73] 3.14.35-stable review
On 03/03/2015 11:12 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.35 release. > There are 73 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 Mar 6 05:52:50 UTC 2015. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.14.35-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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.18 000/151] 3.18.9-stable review
On 03/03/2015 11:12 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.18.9 release. > There are 151 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 Mar 6 05:53:55 UTC 2015. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.18.9-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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 9/9] change the relocations behavior for kaslr on x86_64
On 03/04/15 at 03:16pm, Yinghai Lu wrote:
> On Mon, Mar 2, 2015 at 6:58 AM, Baoquan He wrote:
>
> > @@ -455,17 +455,16 @@ unsigned char *choose_kernel_location(struct
> > boot_params *params,
> >output_size);
>
> you forgot to change
>
> /* Record the various known unsafe memory ranges. */
> mem_avoid_init((unsigned long)input, input_size,
>(unsigned long)output, init_size);
>
> to
>
> /* Record the various known unsafe memory ranges. */
> mem_avoid_init((unsigned long)input, input_size,
>(unsigned long)*output, init_size);
No, I removed output in patch 1/9 since it's not used in
mem_avoid_init(). It doesn't have this problem. But in next post it need
be done like this.
>
> >
> > /* Walk e820 and find a random address. */
> > - random = find_random_addr(choice, output_size);
> > - if (!random) {
> > + random = find_random_phy_addr((unsigned long)*output, output_size);
> > + if (!random)
> > debug_putstr("KASLR could not find suitable E820
> > region...\n");
> > - goto out;
> > - }
> > + else
> > + *output = (unsigned char*)random;
--
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.19 000/175] 3.19.1-stable review
On 03/03/2015 11:12 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.19.1 release. > There are 175 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 Mar 6 06:09:09 UTC 2015. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.1-rc1.gz > and the diffstat can be found below. > > thanks, > > greg k-h > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- 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] vgaarb: Stub vga_set_legacy_decoding()
On 25 February 2015 at 02:16, Alex Williamson
wrote:
> vga_set_legacy_decoding() is defined in drivers/gpu/vga/vgaarb.c,
> which is only compiled with CONFIG_VGA_ARB. A caller would
> therefore get an undefined symbol if the VGA arbiter is not
> enabled.
Acked-by: Dave Airlie
> Signed-off-by: Alex Williamson
> ---
>
> I'd like to use this function from vfio-pci to opt-out VGA devices
> from arbitration if vfio-pci VGA support is disabled. This helps to
> keep DRI2 enabled on the host if additional GPUs are installed for
> VMs and used without VGA support. I can pull this change in through
> my tree if someone wants to provide just an ack. Thanks!
>
> include/linux/vgaarb.h |5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
> index c37bd4d..8c3b412 100644
> --- a/include/linux/vgaarb.h
> +++ b/include/linux/vgaarb.h
> @@ -65,8 +65,13 @@ struct pci_dev;
> * out of the arbitration process (and can be safe to take
> * interrupts at any time.
> */
> +#if defined(CONFIG_VGA_ARB)
> extern void vga_set_legacy_decoding(struct pci_dev *pdev,
> unsigned int decodes);
> +#else
> +static inline void vga_set_legacy_decoding(struct pci_dev *pdev,
> + unsigned int decodes) { };
> +#endif
>
> /**
> * vga_get - acquire & locks VGA resources
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 7/9] get the random phy addr according to slot_area info
On 03/04/15 at 01:28pm, Kees Cook wrote:
> On Mon, Mar 2, 2015 at 6:58 AM, Baoquan He wrote:
> > -static unsigned long find_random_addr(unsigned long minimum,
> > +static unsigned long find_random_phy_addr(unsigned long minimum,
> > unsigned long size)
> > {
> > int i;
> > @@ -374,6 +376,8 @@ static unsigned long find_random_addr(unsigned long
> > minimum,
> > /* Verify potential e820 positions, appending to slots list. */
> > for (i = 0; i < real_mode->e820_entries; i++) {
> > process_e820_entry(&real_mode->e820_map[i], minimum, size);
> > + if ( slot_area_index == MAX_SLOT_AREA )
> > + break;
>
> I wonder if this should emit a printk warning?
Yes, good suggestion. Will add.
Thanks
Baoquan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/6] ARM: at91: switch to multiplatform
Alexandre Belloni schreef op do 05-03-2015 om 00:35 [+0100]: > On 05/03/2015 at 00:21:47 +0100, Paul Bolle wrote : > > Utterly trivial, but anyhow. Could you please make this > > bool > > > > line to be the line directly following the line reading > > config ARCH_AT91 > > > > above? > > I can definitely do that, is your parser relying on it? :) No, I don't think it is, actually. But nearly all Kconfig entries have their type as their first option (and help as their last item, I might add). So I was mainly thinking about human readers and people writing quick scripts, etc. Thanks, Paul Bolle -- 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 21/23] x86/PCI: Refine the way to release PCI IRQ resources
On Wed, 2015-03-04 at 09:06 -0700, Alex Williamson wrote: > Hi, > > I'm getting a regression from this patch when using VFIO for device > assignment to a QEMU VM. I have a device initially bound to the nouveau > driver, which is unbound from that driver and bound to vfio-pci for use > by userspace. vfio-pci calls pci_enable_device, but when userspace > attempts to setup the legacy INTx interrupt, pci_dev->irq is zero and > vfio-pci errors with -ENODEV. > > Where is pci_dev->irq supposed to be getting re-initialized in this > case? Am I missing an important initialization step in vfio-pci? I > certainly don't think I should be calling request_irq(pci_dev->irq, ... > when pci_dev->irq is zero. Thanks, It looks like the imbalance is in pci_dev->enable_cnt. Any call to pci_disable_device() will clear pci_dev->irq, but pci_enable_device() does effectively nothing unless it's called with enable_cnt == zero. So I'm at the mercy of the previous driver behaving relatively sanely in order to re-enable legacy interrupts for a device :-\ Maybe the unbound notifier needs to do some sanitizing of the device? Thanks, Alex -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] intel_idle: Add ->enter_freeze callbacks
On 2015/2/13 0:24, Rafael J. Wysocki wrote: > On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote: >> >> Why bother with enter_freeze() for any but the deepest state (C6 in this >> case)? > > User space may disable the deepest one (and any of them in general) via sysfs > and there's no good reason to ignore its choice in this particular case while > we're honoring it otherwise. > > So the logic is basically "find the deepest one which isn't disabled" and > setting the pointers costs us nothing really. > If the user has chance to disable C6 via /sys, that means c6 works? Shouldn't we ignore user space setting during freeze? Otherwise, we will lost S0ix? Thanks, -Aubrey -- 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] vgaarb: Stub vga_set_legacy_decoding()
On Thu, 2015-03-05 at 09:43 +1000, Dave Airlie wrote:
> On 25 February 2015 at 02:16, Alex Williamson
> wrote:
> > vga_set_legacy_decoding() is defined in drivers/gpu/vga/vgaarb.c,
> > which is only compiled with CONFIG_VGA_ARB. A caller would
> > therefore get an undefined symbol if the VGA arbiter is not
> > enabled.
>
> Acked-by: Dave Airlie
Thanks Dave! I'll route this through my tree with the commit that uses
it.
> > Signed-off-by: Alex Williamson
> > ---
> >
> > I'd like to use this function from vfio-pci to opt-out VGA devices
> > from arbitration if vfio-pci VGA support is disabled. This helps to
> > keep DRI2 enabled on the host if additional GPUs are installed for
> > VMs and used without VGA support. I can pull this change in through
> > my tree if someone wants to provide just an ack. Thanks!
> >
> > include/linux/vgaarb.h |5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/include/linux/vgaarb.h b/include/linux/vgaarb.h
> > index c37bd4d..8c3b412 100644
> > --- a/include/linux/vgaarb.h
> > +++ b/include/linux/vgaarb.h
> > @@ -65,8 +65,13 @@ struct pci_dev;
> > * out of the arbitration process (and can be safe to take
> > * interrupts at any time.
> > */
> > +#if defined(CONFIG_VGA_ARB)
> > extern void vga_set_legacy_decoding(struct pci_dev *pdev,
> > unsigned int decodes);
> > +#else
> > +static inline void vga_set_legacy_decoding(struct pci_dev *pdev,
> > + unsigned int decodes) { };
> > +#endif
> >
> > /**
> > * vga_get - acquire & locks VGA resources
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [regression v4.0-rc1] mm: IPIs from TLB flushes causing significant performance degradation.
On Thu, Mar 05, 2015 at 12:35:45AM +0100, Ingo Molnar wrote: > > * Dave Chinner wrote: > > > > After going through the series again, I did not spot why there is > > > a difference. It's functionally similar and I would hate the > > > theory that this is somehow hardware related due to the use of > > > bits it takes action on. > > > > I doubt it's hardware related - I'm testing inside a VM, [...] > > That might be significant, I doubt Mel considered KVM's interpretation > of pte details? I did actaully mention that before: | I am running a fake-numa=4 config on this test VM so it's got 4 | nodes of 4p/4GB RAM each. but I think it got snipped before Mel was cc'd. Perhaps size of the nodes is relevant, too, because the steady state phase 3 memory usage is 5-6GB when this problem first shows up, and then continues into phase 4 where memory usage grows again and peaks at ~10GB Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[tip:x86/asm] x86/traps: Separate set_intr_gate() and clean up early_trap_init()
Commit-ID: 5eca7453d61003bf886992388f8cb407e6f0d051
Gitweb: http://git.kernel.org/tip/5eca7453d61003bf886992388f8cb407e6f0d051
Author: Wang Nan
AuthorDate: Fri, 27 Feb 2015 12:19:49 +0800
Committer: Ingo Molnar
CommitDate: Thu, 5 Mar 2015 00:47:29 +0100
x86/traps: Separate set_intr_gate() and clean up early_trap_init()
As early_trap_init() doesn't use IST, replace
set_intr_gate_ist() and set_system_intr_gate_ist() with their
standard counterparts.
set_intr_gate() requires a trace_debug symbol which we don't
have and won't use. This patch separates set_intr_gate() into two
parts, and uses base version in early_trap_init().
Reported-by: Andy Lutomirski
Signed-off-by: Wang Nan
Acked-by: Andy Lutomirski
Cc:
Cc:
Cc:
Cc:
Cc:
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1425010789-13714-1-git-send-email-wangn...@huawei.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/desc.h | 7 ++-
arch/x86/kernel/traps.c | 20
2 files changed, 18 insertions(+), 9 deletions(-)
diff --git a/arch/x86/include/asm/desc.h b/arch/x86/include/asm/desc.h
index a94b82e..a0bf89f 100644
--- a/arch/x86/include/asm/desc.h
+++ b/arch/x86/include/asm/desc.h
@@ -376,11 +376,16 @@ static inline void _set_gate(int gate, unsigned type,
void *addr,
* Pentium F0 0F bugfix can have resulted in the mapped
* IDT being write-protected.
*/
-#define set_intr_gate(n, addr) \
+#define set_intr_gate_notrace(n, addr) \
do {\
BUG_ON((unsigned)n > 0xFF); \
_set_gate(n, GATE_INTERRUPT, (void *)addr, 0, 0,\
__KERNEL_CS); \
+ } while (0)
+
+#define set_intr_gate(n, addr) \
+ do {\
+ set_intr_gate_notrace(n, addr); \
_trace_set_gate(n, GATE_INTERRUPT, (void *)trace_##addr,\
0, 0, __KERNEL_CS); \
} while (0)
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 4281988..9965bd1 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -926,16 +926,20 @@ dotraplinkage void do_iret_error(struct pt_regs *regs,
long error_code)
void __init early_trap_init(void)
{
/*
-* Don't set ist to DEBUG_STACK as it doesn't work until TSS is
-* ready in cpu_init() <-- trap_init(). Before trap_init(), CPU
-* runs at ring 0 so it is impossible to hit an invalid stack.
-* Using the original stack works well enough at this early
-* stage. DEBUG_STACK will be equipped after cpu_init() in
+* Don't use IST to set DEBUG_STACK as it doesn't work until TSS
+* is ready in cpu_init() <-- trap_init(). Before trap_init(),
+* CPU runs at ring 0 so it is impossible to hit an invalid
+* stack. Using the original stack works well enough at this
+* early stage. DEBUG_STACK will be equipped after cpu_init() in
* trap_init().
+*
+* We don't need to set trace_idt_table like set_intr_gate(),
+* since we don't have trace_debug and it will be reset to
+* 'debug' in trap_init() by set_intr_gate_ist().
*/
- set_intr_gate_ist(X86_TRAP_DB, &debug, 0);
+ set_intr_gate_notrace(X86_TRAP_DB, debug);
/* int3 can be called from all */
- set_system_intr_gate_ist(X86_TRAP_BP, &int3, 0);
+ set_system_intr_gate(X86_TRAP_BP, &int3);
#ifdef CONFIG_X86_32
set_intr_gate(X86_TRAP_PF, page_fault);
#endif
@@ -1015,7 +1019,7 @@ void __init trap_init(void)
/*
* X86_TRAP_DB and X86_TRAP_BP have been set
-* in early_trap_init(). However, DEBUG_STACK works only after
+* in early_trap_init(). However, ITS works only after
* cpu_init() loads TSS. See comments in early_trap_init().
*/
set_intr_gate_ist(X86_TRAP_DB, &debug, DEBUG_STACK);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
On Wed 04 Mar 11:35 PST 2015, Stephen Boyd wrote:
> On 03/02/15 20:25, Bjorn Andersson wrote:
> > + match = of_match_device(rpm_of_match, &pdev->dev);
> > + for (reg = match->data; reg->name; reg++) {
> > + vreg = devm_kmalloc(&pdev->dev, sizeof(*vreg), GFP_KERNEL);
> > + if (!vreg) {
> > + dev_err(&pdev->dev, "failed to allocate vreg\n");
> > + return -ENOMEM;
> > + }
> > + memcpy(vreg, reg->template, sizeof(*vreg));
> > + mutex_init(&vreg->lock);
> > +
> > + vreg->dev = &pdev->dev;
> > + vreg->resource = reg->resource;
> > +
> > + vreg->desc.id = -1;
> > + vreg->desc.owner = THIS_MODULE;
> > + vreg->desc.type = REGULATOR_VOLTAGE;
> > + vreg->desc.name = reg->name;
> > + vreg->desc.supply_name = reg->supply;
> > + vreg->desc.of_match = reg->name;
> > + vreg->desc.of_parse_cb = rpm_reg_of_parse;
> > +
> > + vreg->rpm = dev_get_drvdata(pdev->dev.parent);
> > + if (!vreg->rpm) {
> > + dev_err(&pdev->dev, "unable to retrieve handle to
> > rpm\n");
> > + return -ENODEV;
> > + }
> >
> > - rdev = devm_regulator_register(&pdev->dev, &vreg->desc, &config);
> > - if (IS_ERR(rdev)) {
> > - dev_err(&pdev->dev, "can't register regulator\n");
> > - return PTR_ERR(rdev);
> > + config.dev = &pdev->dev;
> > + config.driver_data = vreg;
> > + rdev = devm_regulator_register(&pdev->dev, &vreg->desc,
> > &config);
> > + if (IS_ERR(rdev)) {
> > + dev_err(&pdev->dev, "can't register regulator\n");
> > + return PTR_ERR(rdev);
> > + }
> > }
> >
> > return 0;
>
> There's another problem with this of_parse_cb design. The regulator
> framework requires supplies to be registered before consumers of the
> supplies are registered.
You're right, didn't think of that.
The way I've ordered pm8921 it happens to work, but neither 8058 nor
8901 will pass probe by filling in the dependencies according to what we
have in the caf branch.
> So when we register L23 we need to make sure
> it's supply is already registered (S8 for example). If we used
> of_regulator_match() we could sort the array by hand so that we always
> register the supplies first.
Right, but that would mean that any block of regulators with internal
dependencies would miss out on the "standard" code paths through
regulator_register() and have to implement this on their own.
Just looking at the Qualcomm case, we would have to implement this
sorting mechanism in the rpm-regulator, pm8xxx-regulator, smd-regulator
and qpnp-regulator drivers.
I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator,
but as it's a mixture of internal and external dependencies (e.g.
<&pm8921_s4> vs <&pm8921_mpp 7>) this became quite messy. I started
looking at using the dt dependencies sort and iterate over the entries
in a way that adheres to their dependencies, but that's also a lot of
code.
But...
> Or we could modify the regulator framework
> to have a concept of "orphaned" supplies like the clock framework has so
> that when a regulator is registered it waits until its supply is registered.
>
...as we're grouping all regulators into one device per PMIC we create
artificial dependencies that the hardware guys does not have. Further
more the fact that we can have some parts of the pmic exposed through
the rpm driver and others through the direct driver we have yet another
level of possible just adds to this.
It's perfectly fine to route the dependencies between two of our PMICs
in a way that on a device level we have a circular dependency.
So I think you're right, we should be able to alter the supply lookup
code to defer the EPROBE_DEFER until we actually need the supply to be
there; e.g. attempt to map supplies when an external consumer request
the regulator.
Some care needs to be taken with regards to e.g. always-on regulators.
Regards,
Bjorn
--
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 v9 07/21] ACPI / sleep: Introduce arm64 specific acpi_sleep.c
On Thursday, March 05, 2015 12:25:54 AM Rafael J. Wysocki wrote:
> On Wednesday, March 04, 2015 10:49:25 PM G Gregory wrote:
> > On 4 March 2015 at 22:38, Rafael J. Wysocki wrote:
> > > On Wednesday, February 25, 2015 04:39:47 PM Hanjun Guo wrote:
> > >> From: Graeme Gregory
> > >>
> > >> ACPI 5.1 does not currently support S states for ARM64 hardware but
> > >> ACPI code will call acpi_target_system_state() for device power
> > >> management, so introduce acpi_sleep.c to allow other drivers to function
> > >> until S states are defined.
> > >>
> > >> Since it is arm64 specific stub holder, so let acpi_sleep.c to ARM64
> > >> specific.
> > >>
> > >> TODO: merge this with drivers/acpi/sleep.c once we fix the specification.
> > >>
> > >> CC: Rafael J. Wysocki
> > >> Tested-by: Suravee Suthikulpanit
> > >> Tested-by: Yijing Wang
> > >> Tested-by: Mark Langsdorf
> > >> Tested-by: Jon Masters
> > >> Tested-by: Timur Tabi
> > >> Tested-by: Robert Richter
> > >> Acked-by: Robert Richter
> > >> Signed-off-by: Graeme Gregory
> > >> Signed-off-by: Tomasz Nowicki
> > >> Signed-off-by: Hanjun Guo
> > >> ---
> > >> arch/arm64/kernel/Makefile | 2 +-
> > >> arch/arm64/kernel/acpi_sleep.c | 28
> > >> drivers/acpi/Makefile | 2 ++
> > >> 3 files changed, 31 insertions(+), 1 deletion(-)
> > >> create mode 100644 arch/arm64/kernel/acpi_sleep.c
> > >>
> > >> diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
> > >> index 218eb7e..4435943 100644
> > >> --- a/arch/arm64/kernel/Makefile
> > >> +++ b/arch/arm64/kernel/Makefile
> > >> @@ -34,7 +34,7 @@ arm64-obj-$(CONFIG_KGDB)+= kgdb.o
> > >> arm64-obj-$(CONFIG_EFI) += efi.o efi-stub.o
> > >> efi-entry.o
> > >> arm64-obj-$(CONFIG_PCI) += pci.o
> > >> arm64-obj-$(CONFIG_ARMV8_DEPRECATED) += armv8_deprecated.o
> > >> -arm64-obj-$(CONFIG_ACPI) += acpi.o
> > >> +arm64-obj-$(CONFIG_ACPI) += acpi.o acpi_sleep.o
> > >>
> > >> obj-y+= $(arm64-obj-y) vdso/
> > >> obj-m+= $(arm64-obj-m)
> > >> diff --git a/arch/arm64/kernel/acpi_sleep.c
> > >> b/arch/arm64/kernel/acpi_sleep.c
> > >> new file mode 100644
> > >> index 000..54578ef
> > >> --- /dev/null
> > >> +++ b/arch/arm64/kernel/acpi_sleep.c
> > >> @@ -0,0 +1,28 @@
> > >> +/*
> > >> + * ARM64 Specific Sleep Functionality
> > >> + *
> > >> + * Copyright (C) 2013-2014, Linaro Ltd.
> > >> + * Author: Graeme Gregory
> > >> + *
> > >> + * This program is free software; you can redistribute it and/or modify
> > >> + * it under the terms of the GNU General Public License version 2 as
> > >> + * published by the Free Software Foundation.
> > >> + */
> > >> +
> > >> +#include
> > >> +
> > >> +/*
> > >> + * Currently the ACPI 5.1 standard does not define S states in a
> > >> + * manner which is usable for ARM64. These two stubs are sufficient
> > >> + * that system initialises and device PM works.
> > >> + */
> > >> +u32 acpi_target_system_state(void)
> > >> +{
> > >> + return ACPI_STATE_S0;
> > >> +}
> > >> +EXPORT_SYMBOL_GPL(acpi_target_system_state);
> > >> +
> > >> +int __init acpi_sleep_init(void)
> > >> +{
> > >> + return -ENOSYS;
> > >> +}
> > >> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> > >> index 623b117..c32edf5 100644
> > >> --- a/drivers/acpi/Makefile
> > >> +++ b/drivers/acpi/Makefile
> > >> @@ -23,7 +23,9 @@ acpi-y += nvs.o
> > >>
> > >> # Power management related files
> > >> acpi-y += wakeup.o
> > >> +ifneq (,$(findstring $(ARCH),x86 ia64))
> > >
> > > This is super-ugly. Isn't there a better way to do that?
> > >
> > Its the standard example in the GNU Make manual,
>
> It is never used in the kernel this way, though, and I'm not going to let
> that slip through.
>
> > I would certainly love if someone had a batter suggestion.
>
> Define ACPI_GENERIC_SLEEP in drivers/acpi/Kconfig as
>
> config ACPI_GENERIC_SLEEP
> bool
> depends on IA64 || X86
>
> and build the file conditional on that.
Or define
config ACPI_GENERIC_SLEEP
bool
and then make both x86 and ia64 do
select ACPI_GENERIC_SLEEP if ACPI
which kind of will make it clear where the choice takes place.
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] intel_idle: Add ->enter_freeze callbacks
On Thursday, March 05, 2015 07:50:26 AM Li, Aubrey wrote: > On 2015/2/13 0:24, Rafael J. Wysocki wrote: > > On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote: > >> > >> Why bother with enter_freeze() for any but the deepest state (C6 in this > >> case)? > > > > User space may disable the deepest one (and any of them in general) via > > sysfs > > and there's no good reason to ignore its choice in this particular case > > while > > we're honoring it otherwise. > > > > So the logic is basically "find the deepest one which isn't disabled" and > > setting the pointers costs us nothing really. > > > > If the user has chance to disable C6 via /sys, that means c6 works? > Shouldn't we ignore user space setting during freeze? Otherwise, we will > lost S0ix? We can't ignore it, because we don't know the reason why the state was disabled. It may just not work reliably enough on the given platform. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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] spi: spidev_test: Added functionalities
On Sun, Mar 01, 2015 at 07:28:41PM +0100, AdrianRemonda wrote: > I apologize for the wrong patch format. > Should I contact the mantainer of the tool path and ask him where to add > it? Or how should I proceed? I am the relevant maintainer here. The main thing from my point of view is to split the three changes you were making out into separate commits so they can be easily reviewed. Jon is right that this should be moved into a better directory but that's a separate issue that can be tackled separately (though feel free to do it immediately if you like!). signature.asc Description: Digital signature
Re: [PATCH 4/5] mm: split ET_DYN ASLR from mmap ASLR
On Wed, 2015-03-04 at 13:13 -0800, Kees Cook wrote: > > I had a question in the powerpc-specific change that may have gone unnoticed: > > Can mmap ASLR be safely enabled in the legacy mmap case here? Other archs > use "mm->mmap_base = TASK_UNMAPPED_BASE + random_factor". > > Separate from this series, do you happen to know if this improvement > can be made, or if the legacy mmap on powerpc can't handle this? Yeah I saw that. The short answer is I'm not sure. I assume we have that distinction for some good reason, but whether we still need it I don't know. I'll dig a bit and see if anyone can remember the details. cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c
On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote: > On Tuesday, February 24, 2015 05:36:17 PM al.st...@linaro.org wrote: >> From: Al Stone >> >> In preparation for later splitting out some of the arch-dependent code from >> osl.c, clean up the errors reported by checkpatch.pl. They fell into these >> classes: >> >>-- remove the FSF address from the GPL notice >>-- "foo * bar" should be "foo *bar" (and the ** variation of same) >>-- a return is not a function, so parentheses are not required. >> >> Signed-off-by: Al Stone > > checkpatch.pl is irrelevant here. You're trying to make the coding style be > more consistent with the coding style of the rest of the kernel. > > The warnings from checkpatch.pl are meaningless for the existing code, so > it should not be used to justify changes in that code. > > Of course, the same applies to patches [2-4/9]. > > Okay, I'm puzzled. In the last version of these patches, I asked if I should clean up osl.c as long as I was creating the new osi.c file. I understood the reply to mean it would also be good to correct osl.c [0] from checkpatch's point of view. I took that to mean errors (patch [1/9]) and warnings (patches [2-4/9]) -- so that's what I did. What did I misunderstand from that reply? If these changes are objectionable, then I'll drop these from the next version of the patch set; I'm not hung up on insisting on either of the kernel's or ACPI's coding style -- I try to adapt as needed. I only did the patches because I thought it was helping out with some long-term maintenance type work. [0] https://lkml.org/lkml/2015/2/4/749 -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] firmware_class: Add firmware filename overrides
On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote: > This patch adds an additional feature to the firmware_class.c module. > To allow a unified method of specifying new firmware locations when > drivers request a firmware binary to update their devices with, we > have added the concept of a "fw override" > > A fw override is a rule that matches firmware requests based on the > name of the device requesting the fw and what the filename for the > fw they are requesting is, and overrides their requests with a new > value. > > Overrides are set up by piping a description of the override into > an attribute set up at /sys/class/firmware/fw_override. The string > should be a null-deliminited list of the firmware name you want to > over ride, the new name to replace it with, and the device name that > you want the override to apply to. For example you could set up > an override for a device called "my_device" so that any time it > requests a firmware called "my_fw.bin" it instead gets "new_fw.bin" > with the following command: > > echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' > > /sys/class/firmware/fw_override I hate to ask, but I have to, why do you need this? Also, this needs to be documented somewhere, Documentation/ABI/ please? 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 2/2] block_dev/DIO - cache one bio allocation when caching a DIO.
When performing an O_DIRECT write to a block device, a 'struct bio' is
allocated from a mempool.
There is only one mempool for all block devices so if a single block
device blocked indefinitely, the mempool could in theory be exhausted
and other block devices would be affected.
When mdmon needs to update RAID metadata (see previous patch) it needs
to perform an O_DIRECT write to some block devices while another block
device (the array) is frozen. This could conceivably lead to a
deadlock.
Rather than allocate one mempool per block device (which would be an
effective solution), this patch effects a single-bio pool for each
'struct dio' that is being used by an mlockall(MCL_FUTURE) process.
'cache_bio' is added to 'struct dio' and placed at the end so that it
isn't zeroed out regularly.
When an allocation is needed, the bio is used if it is present and
large enough. When a bio if freed, it is placed here if appropriate.
Naturally it is freed when the file is closed.
All other allocations to serve O_DIRECT writes are further down the
stack and use mempools that cannot be exhausted by a frozen md array.
Signed-off-by: NeilBrown
---
fs/direct-io.c | 45 +++--
1 file changed, 39 insertions(+), 6 deletions(-)
diff --git a/fs/direct-io.c b/fs/direct-io.c
index ece5e45933d2..554913e9cc30 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -139,12 +139,17 @@ struct dio {
struct page *pages[DIO_PAGES]; /* page buffer */
struct work_struct complete_work;/* deferred AIO completion */
};
+ struct bio *cache_bio;
} cacheline_aligned_in_smp;
static struct kmem_cache *dio_cache __read_mostly;
void dio_free(struct dio *dio)
{
+ if (dio->cache_bio) {
+ bio_put(dio->cache_bio);
+ dio->cache_bio = NULL;
+ }
kmem_cache_free(dio_cache, dio);
}
@@ -362,13 +367,24 @@ dio_bio_alloc(struct dio *dio, struct dio_submit *sdio,
struct block_device *bdev,
sector_t first_sector, int nr_vecs)
{
- struct bio *bio;
+ struct bio *bio = NULL;
+ if ((dio->flags & DIO_PERSISTENT_DIO) && dio->cache_bio) {
+ spin_lock_irq(&dio->bio_lock);
+ if (dio->cache_bio &&
+ dio->cache_bio->bi_max_vecs >= nr_vecs) {
+ bio = dio->cache_bio;
+ dio->cache_bio = NULL;
+ bio_reset(bio);
+ }
+ spin_unlock_irq(&dio->bio_lock);
+ }
/*
* bio_alloc() is guaranteed to return a bio when called with
* __GFP_WAIT and we request a valid number of vectors.
*/
- bio = bio_alloc(GFP_KERNEL, nr_vecs);
+ if (!bio)
+ bio = bio_alloc(GFP_KERNEL, nr_vecs);
bio->bi_bdev = bdev;
bio->bi_iter.bi_sector = first_sector;
@@ -480,7 +496,21 @@ static int dio_bio_complete(struct dio *dio, struct bio
*bio)
set_page_dirty_lock(page);
page_cache_release(page);
}
- bio_put(bio);
+ if (dio->flags & DIO_PERSISTENT_DIO) {
+ spin_lock_irq(&dio->bio_lock);
+ if (dio->cache_bio &&
+ dio->cache_bio->bi_max_vecs < bio->bi_max_vecs) {
+ bio_put(dio->cache_bio);
+ dio->cache_bio = NULL;
+ }
+ if (dio->cache_bio == NULL) {
+ dio->cache_bio = bio;
+ bio = NULL;
+ }
+ spin_unlock_irq(&dio->bio_lock);
+ }
+ if (bio)
+ bio_put(bio);
}
return uptodate ? 0 : -EIO;
}
@@ -1144,8 +1174,11 @@ do_blockdev_direct_IO(int rw, struct kiocb *iocb, struct
inode *inode,
if (cmpxchg(&iocb->ki_filp->private_data, dio, NULL) != dio)
dio = NULL;
}
- if (!dio)
+ if (!dio) {
dio = kmem_cache_alloc(dio_cache, GFP_KERNEL);
+ if (dio)
+ dio->cache_bio = NULL;
+ }
retval = -ENOMEM;
if (!dio)
goto out;
@@ -1169,7 +1202,7 @@ do_blockdev_direct_IO(int rw, struct kiocb *iocb, struct
inode *inode,
end - 1);
if (retval) {
mutex_unlock(&inode->i_mutex);
- kmem_cache_free(dio_cache, dio);
+ dio_free(dio);
goto out;
}
}
@@ -1205,7 +1238,7 @@ do_blockdev_direct_IO(int rw, struct kiocb *iocb, struct
inode *inode,
* We grab i_mutex only for reads so we don't
[PATCH 0/2] Avoid memory allocation for O_DIRECT IO.
Hi Al, I wonder if you would consider these two patches. They extend the functionality of mlockall(MCL_FUTURE) to apply to memory allocations when performing O_DIRECT io. i.e. The first read or write to an O_DIRECT file descriptor will, if MCL_FUTURE is in effect, cache any allocated memory so that it doesn't need to be allocated on subsequent reads or writes. This is needed for reliable handling of RAID metadata in userspace. When a device fails, it is necessary to record this failure in the metadata before further writes are allowed to complete. As a GFP_KERNEL allocation may block waiting for arbitrary writes to complete, we must not allow any GFP_KERNEL allocation while updating the metadata. The approach I have taken to avoiding GFP_KERNEL allocations in O_DIRECT handling is to cache the necessary data structures the first time they are allocated. There are two data structures, "struct dio" and "struct bio". I have seen a host in a memory deadlock where mdmon (which does the metadata management) was stuck waiting to allocate a 'struct dio', but couldn't until writeout was allowed to proceed - which it couldn't. I have not need a machine deadlocking waiting for a bio. That is a much less likely deadlock scenario. The bio is allocated from a mempool so the allocation will very often succeed. Exhausting the mempool is unlikely but I believe it is theoretically possible as the mempool is shared over multiple devices. Thanks, NeilBrown --- NeilBrown (2): block_dev/DIO: Optionally allocate single 'struct dio' per file. block_dev/DIO - cache one bio allocation when caching a DIO. fs/block_dev.c |7 +- fs/direct-io.c | 61 ++-- include/linux/fs.h |6 + 3 files changed, 66 insertions(+), 8 deletions(-) -- Signature -- 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.19 000/175] 3.19.1-stable review
On Wed, Mar 04, 2015 at 04:41:51PM -0700, Shuah Khan wrote: > On 03/03/2015 11:12 PM, Greg Kroah-Hartman wrote: > > This is the start of the stable review cycle for the 3.19.1 release. > > There are 175 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 Mar 6 06:09:09 UTC 2015. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.1-rc1.gz > > and the diffstat can be found below. > > > > thanks, > > > > greg k-h > > > > Compiled and booted on my test system. No dmesg regressions. Thanks for testing all 4 of these and 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/
[PATCH 1/2] block_dev/DIO: Optionally allocate single 'struct dio' per file.
To be able to support RAID metadata operations in user-space, mdmon
(part of mdadm) sometimes needs to update the metadata on an array
before any future writes to the array are permitted. This is
particularly needed for recording a device failure.
If that array is being used for swap (and even to some extent when
just used for a filesystem) then any memory allocation performed by
mdmon can cause a deadlock if the allocation waits for data to be
written out to the array.
mdmon uses mlockall(MCL_FUTURE|MCL_CURRENT) and is careful not to
allocate any memory at the wrong time. However the kernel sometimes
allocates memory on its behalf and this can deadlock.
Updating the metadata requires an O_DIRECT write to each of a number
of files (which were previously opened). Each write requires
allocating a 'struct dio'.
To avoid this deadlock risk, this patch caches the 'struct dio' the
first time it is allocated so that future writes on the file do not
require the allocation. It is cached in '->private_data' for the
struct file. Only a single struct is cached so only sequential
accesses are allocation-free.
The caching is only performed if mlockall(MCL_FUTURE) is in effect,
thus limiting the change to only those cases where it will bring a
benefit.
Effectively, the memory allocated for O_DIRECT access is 'locked' in
place for future use.
Signed-off-by: NeilBrown
---
fs/block_dev.c |7 ++-
fs/direct-io.c | 18 --
include/linux/fs.h |6 ++
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 975266be67d3..ed55e5329563 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -155,7 +155,10 @@ blkdev_direct_IO(int rw, struct kiocb *iocb, struct
iov_iter *iter,
return __blockdev_direct_IO(rw, iocb, inode, I_BDEV(inode), iter,
offset, blkdev_get_block,
- NULL, NULL, 0);
+ NULL, NULL,
+ current->mm &&
+ (current->mm->def_flags & VM_LOCKED)
+ ? DIO_PERSISTENT_DIO : 0);
}
int __sync_blockdev(struct block_device *bdev, int wait)
@@ -1567,6 +1570,8 @@ EXPORT_SYMBOL(blkdev_put);
static int blkdev_close(struct inode * inode, struct file * filp)
{
struct block_device *bdev = I_BDEV(filp->f_mapping->host);
+ if (filp->private_data)
+ dio_free(filp->private_data);
blkdev_put(bdev, filp->f_mode);
return 0;
}
diff --git a/fs/direct-io.c b/fs/direct-io.c
index e181b6b2e297..ece5e45933d2 100644
--- a/fs/direct-io.c
+++ b/fs/direct-io.c
@@ -143,6 +143,11 @@ struct dio {
static struct kmem_cache *dio_cache __read_mostly;
+void dio_free(struct dio *dio)
+{
+ kmem_cache_free(dio_cache, dio);
+}
+
/*
* How many pages are in the queue?
*/
@@ -268,7 +273,9 @@ static ssize_t dio_complete(struct dio *dio, loff_t offset,
ssize_t ret,
aio_complete(dio->iocb, ret, 0);
}
- kmem_cache_free(dio_cache, dio);
+ if (!(dio->flags & DIO_PERSISTENT_DIO) ||
+ cmpxchg(&dio->iocb->ki_filp->private_data, NULL, dio) != NULL)
+ dio_free(dio);
return ret;
}
@@ -1131,7 +1138,14 @@ do_blockdev_direct_IO(int rw, struct kiocb *iocb, struct
inode *inode,
if (rw == READ && !iov_iter_count(iter))
return 0;
- dio = kmem_cache_alloc(dio_cache, GFP_KERNEL);
+ dio = NULL;
+ if ((flags & DIO_PERSISTENT_DIO) &&
+ (dio = iocb->ki_filp->private_data) != NULL) {
+ if (cmpxchg(&iocb->ki_filp->private_data, dio, NULL) != dio)
+ dio = NULL;
+ }
+ if (!dio)
+ dio = kmem_cache_alloc(dio_cache, GFP_KERNEL);
retval = -ENOMEM;
if (!dio)
goto out;
diff --git a/include/linux/fs.h b/include/linux/fs.h
index b4d71b5e1ff2..b821fa32ba3f 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -52,6 +52,7 @@ struct seq_file;
struct workqueue_struct;
struct iov_iter;
struct vm_fault;
+struct dio;
extern void __init inode_init(void);
extern void __init inode_init_early(void);
@@ -2612,9 +2613,14 @@ enum {
/* filesystem can handle aio writes beyond i_size */
DIO_ASYNC_EXTEND = 0x04,
+
+ /* file->private_data is used to store a 'struct dio'
+* between calls */
+ DIO_PERSISTENT_DIO = 0x08,
};
void dio_end_io(struct bio *bio, int error);
+void dio_free(struct dio *dio);
ssize_t __blockdev_direct_IO(int rw, struct kiocb *iocb, struct inode *inode,
struct block_device *bdev, struct iov_iter *iter, loff_t offset,
--
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
[PATCH] MIPS: Provide fallback reboot/poweroff/halt implementations
If a machine-specific hook is not implemented for restart, poweroff,
or halt, fall back to halting secondary CPUs, disabling interrupts,
and spinning. In the case of restart, attempt to restart the system
via do_kernel_restart() (which will call any registered restart
handlers) before halting.
Signed-off-by: Andrew Bresticker
---
arch/mips/kernel/reset.c | 20
1 file changed, 20 insertions(+)
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc524..87b1f08 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -29,16 +29,36 @@ void machine_restart(char *command)
{
if (_machine_restart)
_machine_restart(command);
+
+#ifdef CONFIG_SMP
+ smp_send_stop();
+#endif
+ do_kernel_restart(command);
+ pr_emerg("Reboot failed -- System halted\n");
+ local_irq_disable();
+ while (1);
}
void machine_halt(void)
{
if (_machine_halt)
_machine_halt();
+
+#ifdef CONFIG_SMP
+ smp_send_stop();
+#endif
+ local_irq_disable();
+ while (1);
}
void machine_power_off(void)
{
if (pm_power_off)
pm_power_off();
+
+#ifdef CONFIG_SMP
+ smp_send_stop();
+#endif
+ local_irq_disable();
+ while (1);
}
--
2.2.0.rc0.207.ga3a616c
--
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] pinctrl: at91: move lock/unlock_as_irq calls into request/release resources methods
On 19:23 Sun 08 Feb , Boris Brezillon wrote:
> The gpiochip_lock_as_irq call can fail and return an error, while the
> irq_startup is not expected to fail (returns an unsigned int which is not
> checked by irq core code).
>
> irq_request/release_resources functions have been created to address this
> problem.
>
> Move gpiochip_lock/unlock_as_irq calls into
> irq_request/release_resources functions to prevent using a gpio as an irq
> if the gpiochip_lock_as_irq call failed.
>
> Signed-off-by: Boris Brezillon
Linus
Acked-by: Jean-Christophe PLAGNIOL-VILLARD
Best Regards,
J.
> ---
> drivers/pinctrl/pinctrl-at91.c | 17 +++--
> 1 file changed, 7 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-at91.c b/drivers/pinctrl/pinctrl-at91.c
> index f4cd0b9..a481406 100644
> --- a/drivers/pinctrl/pinctrl-at91.c
> +++ b/drivers/pinctrl/pinctrl-at91.c
> @@ -1477,28 +1477,25 @@ static void gpio_irq_ack(struct irq_data *d)
> /* the interrupt is already cleared before by reading ISR */
> }
>
> -static unsigned int gpio_irq_startup(struct irq_data *d)
> +static int gpio_irq_request_res(struct irq_data *d)
> {
> struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> unsignedpin = d->hwirq;
> int ret;
>
> ret = gpiochip_lock_as_irq(&at91_gpio->chip, pin);
> - if (ret) {
> + if (ret)
> dev_err(at91_gpio->chip.dev, "unable to lock pind %lu IRQ\n",
> d->hwirq);
> - return ret;
> - }
> - gpio_irq_unmask(d);
> - return 0;
> +
> + return ret;
> }
>
> -static void gpio_irq_shutdown(struct irq_data *d)
> +static void gpio_irq_release_res(struct irq_data *d)
> {
> struct at91_gpio_chip *at91_gpio = irq_data_get_irq_chip_data(d);
> unsignedpin = d->hwirq;
>
> - gpio_irq_mask(d);
> gpiochip_unlock_as_irq(&at91_gpio->chip, pin);
> }
>
> @@ -1577,8 +1574,8 @@ void at91_pinctrl_gpio_resume(void)
> static struct irq_chip gpio_irqchip = {
> .name = "GPIO",
> .irq_ack= gpio_irq_ack,
> - .irq_startup= gpio_irq_startup,
> - .irq_shutdown = gpio_irq_shutdown,
> + .irq_request_resources = gpio_irq_request_res,
> + .irq_release_resources = gpio_irq_release_res,
> .irq_disable= gpio_irq_mask,
> .irq_mask = gpio_irq_mask,
> .irq_unmask = gpio_irq_unmask,
> --
> 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 v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c
On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote: > On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote: > > On Tuesday, February 24, 2015 05:36:17 PM al.st...@linaro.org wrote: > >> From: Al Stone > >> > >> In preparation for later splitting out some of the arch-dependent code from > >> osl.c, clean up the errors reported by checkpatch.pl. They fell into these > >> classes: > >> > >>-- remove the FSF address from the GPL notice > >>-- "foo * bar" should be "foo *bar" (and the ** variation of same) > >>-- a return is not a function, so parentheses are not required. > >> > >> Signed-off-by: Al Stone > > > > checkpatch.pl is irrelevant here. You're trying to make the coding style be > > more consistent with the coding style of the rest of the kernel. > > > > The warnings from checkpatch.pl are meaningless for the existing code, so > > it should not be used to justify changes in that code. > > > > Of course, the same applies to patches [2-4/9]. > > > > > > Okay, I'm puzzled. In the last version of these patches, I asked if I > should clean up osl.c as long as I was creating the new osi.c file. I > understood the reply to mean it would also be good to correct osl.c [0] > from checkpatch's point of view. I took that to mean errors (patch [1/9]) > and warnings (patches [2-4/9]) -- so that's what I did. What did I > misunderstand from that reply? > > If these changes are objectionable, then I'll drop these from the next > version of the patch set; I'm not hung up on insisting on either of the > kernel's or ACPI's coding style -- I try to adapt as needed. I only did > the patches because I thought it was helping out with some long-term > maintenance type work. The changes are basically OK, but the justification is bogus to me. "I'm making the chagne, because checkpatch.pl told me so" is a pretty bad explanation in my view. It is much better to say "This file does not adhere to the general kernel coding style and since I'm going to split it into pieces and I want those pieces to follow the coding style more closely, make changes as follows." So this is more about the changelogs (and subjects) than the code changes themselves. -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 0/3] epoll: introduce round robin wakeup mode
* Andrew Morton wrote: > On Fri, 27 Feb 2015 17:01:32 -0500 Jason Baron wrote: > > > > > > > > > I don't really understand the need for rotation/round-robin. We can > > > solve the thundering herd via exclusive wakeups, but what is the point > > > in choosing to wake the task which has been sleeping for the longest > > > time? Why is that better than waking the task which has been sleeping > > > for the *least* time? That's probably faster as that task's data is > > > more likely to still be in cache. > > > > > > The changelogs talks about "starvation" but they don't really say what > > > this term means in this context, nor why it is a bad thing. > > > > > I'm still not getting it. > > > So the idea with the 'rotation' is to try and distribute the > > workload more evenly across the worker threads. > > Why? > > > We currently > > tend to wake up the 'head' of the queue over and over and > > thus the workload for us is not evenly distributed. > > What's wrong with that? > > > In fact, we > > have a workload where we have to remove all the epoll sets > > and then re-add them in a different order to improve the situation. > > Why? So my guess would be (but Jason would know this more precisely) that spreading the workload to more tasks in a FIFO manner, the individual tasks can move between CPUs better, and fill in available CPU bandwidth better, increasing concurrency. With the current LIFO distribution of wakeups, the 'busiest' threads will get many wakeups (potentially from different CPUs), making them cache-hot, which may interfere with them easily migrating across CPUs. So while technically both approaches have similar concurrency, the more 'spread out' task hierarchy schedules in a more consistent manner. But ... this is just a wild guess and even if my description is accurate then it should still be backed by robust measurements and observations, before we extend the ABI. This hypothesis could be tested by the patch below: with the patch applied if the performance difference between FIFO and LIFO epoll wakeups disappears, then the root cause is the cache-hotness code in the scheduler. Thanks, Ingo --- diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index ee595ef30470..89af04e946d2 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5354,7 +5354,7 @@ static int task_hot(struct task_struct *p, struct lb_env *env) lockdep_assert_held(&env->src_rq->lock); - if (p->sched_class != &fair_sched_class) + if (1 || p->sched_class != &fair_sched_class) return 0; if (unlikely(p->policy == SCHED_IDLE)) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] toshiba_acpi: Add Satellite P50W-B to alternative keymap and create new mappings.
Hi there,
2015-03-04 14:52 GMT-07:00 Joseph Salisbury :
...
> + { KE_KEY, 0x140, { KEY_BRIGHTNESSDOWN } },
> + { KE_KEY, 0x141, { KEY_BRIGHTNESSUP } },
...
These two are not neccesary, as they may collide with "previous song"
and "playpause" in case Toshiba (or its manufacturers) decide to use
those keys.
If you can, please test the first two patches from the gmane archive [1],
they eliminate the need of the DMI matching list. And it would be great
to have more laptops tested.
[1] http://comments.gmane.org/gmane.linux.drivers.platform.x86.devel/6602
Cheers
Azael
--
-- El mundo apesta y vosotros apestais tambien --
--
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] regulator: core: Silence EPROBE_DEFER error on bulk_get
On Thu, Feb 26, 2015 at 03:40:20PM -0800, Bjorn Andersson wrote: > As this is already being logged elsewhere we shouldn't spam the log > unnecessarily upon EPROBE_DEFER. Where exactly is this "elsewhere" you're thinking of? I suspect you mean the core -EPROBE_DEFER logging but you don't say... > Maybe we should have a dev_dbg() for EPROBE_DEFER to aid finding which > regulator it actually was that it deferred? No, that's the wrong way around: > ret = PTR_ERR(consumers[i].consumer); > - dev_err(dev, "Failed to get supply '%s': %d\n", > - consumers[i].supply, ret); > + if (ret != -EPROBE_DEFER) > + dev_err(dev, "Failed to get supply '%s': %d\n", > + consumers[i].supply, ret); What you're saying here is that essentially everything in the probe path has to special case -EPROBE_DEFER to remove error logging which in turn means that any useful information gets elided from the logs. Having a debug level log that people can enable or dig out helps somewhat but it's not really helping users to make it harder to discover information. If you think probe deferral is too noisy then fix it, don't go and add lots of special casing code to the error handling. If other things aren't reporting errors well then fix that. signature.asc Description: Digital signature
[PATCH] locks: fix fasync_struct memory leak in lease upgrade/downgrade handling
Commit 8634b51f6ca2 (locks: convert lease handling to file_lock_context)
introduced a regression in the handling of lease upgrade/downgrades.
In the event that we already have a lease on a file and are going to
either upgrade or downgrade it, we skip doing any list insertion or
deletion and skip to re-calling lm_setup on the existing lease.
As of commit 8634b51f6ca2 however, we end up calling lm_setup on the
lease that was passed in, instead of on the existing lease. This causes
us to leak the fasync_struct that was allocated in the event that there
was not already an existing one (as it always appeared that there
wasn't one).
Fixes: 8634b51f6ca2 (locks: convert lease handling to file_lock_context)
Reported-by: Daniel Wagner
Signed-off-by: Jeff Layton
---
fs/locks.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/fs/locks.c b/fs/locks.c
index 365c82e1b3a9..f1bad681fc1c 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1665,7 +1665,8 @@ generic_add_lease(struct file *filp, long arg, struct
file_lock **flp, void **pr
}
if (my_fl != NULL) {
- error = lease->fl_lmops->lm_change(my_fl, arg, &dispose);
+ lease = my_fl;
+ error = lease->fl_lmops->lm_change(lease, arg, &dispose);
if (error)
goto out;
goto out_setup;
--
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 v3 1/9] ACPI: fix all errors reported by cleanpatch.pl in osl.c
On 03/04/2015 05:25 PM, Rafael J. Wysocki wrote: > On Wednesday, March 04, 2015 04:56:12 PM Al Stone wrote: >> On 03/04/2015 04:04 PM, Rafael J. Wysocki wrote: >>> On Tuesday, February 24, 2015 05:36:17 PM al.st...@linaro.org wrote: From: Al Stone In preparation for later splitting out some of the arch-dependent code from osl.c, clean up the errors reported by checkpatch.pl. They fell into these classes: -- remove the FSF address from the GPL notice -- "foo * bar" should be "foo *bar" (and the ** variation of same) -- a return is not a function, so parentheses are not required. Signed-off-by: Al Stone >>> >>> checkpatch.pl is irrelevant here. You're trying to make the coding style be >>> more consistent with the coding style of the rest of the kernel. >>> >>> The warnings from checkpatch.pl are meaningless for the existing code, so >>> it should not be used to justify changes in that code. >>> >>> Of course, the same applies to patches [2-4/9]. >>> >>> >> >> Okay, I'm puzzled. In the last version of these patches, I asked if I >> should clean up osl.c as long as I was creating the new osi.c file. I >> understood the reply to mean it would also be good to correct osl.c [0] >> from checkpatch's point of view. I took that to mean errors (patch [1/9]) >> and warnings (patches [2-4/9]) -- so that's what I did. What did I >> misunderstand from that reply? >> >> If these changes are objectionable, then I'll drop these from the next >> version of the patch set; I'm not hung up on insisting on either of the >> kernel's or ACPI's coding style -- I try to adapt as needed. I only did >> the patches because I thought it was helping out with some long-term >> maintenance type work. > > The changes are basically OK, but the justification is bogus to me. > "I'm making the chagne, because checkpatch.pl told me so" is a pretty bad > explanation in my view. It is much better to say "This file does not > adhere to the general kernel coding style and since I'm going to split it > into pieces and I want those pieces to follow the coding style more closely, > make changes as follows." > > So this is more about the changelogs (and subjects) than the code changes > themselves. Aha. That makes much more sense to me. Sorry if I was being a bit dense; I'll rev these for the next version so it's far clearer. Thanks for being patient :). -- ciao, al --- Al Stone Software Engineer Red Hat, Inc. a...@redhat.com --- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/6] intel_idle: Add ->enter_freeze callbacks
On 2015/3/5 8:18, Rafael J. Wysocki wrote: > On Thursday, March 05, 2015 07:50:26 AM Li, Aubrey wrote: >> On 2015/2/13 0:24, Rafael J. Wysocki wrote: >>> On Thursday, February 12, 2015 02:26:43 PM Peter Zijlstra wrote: Why bother with enter_freeze() for any but the deepest state (C6 in this case)? >>> >>> User space may disable the deepest one (and any of them in general) via >>> sysfs >>> and there's no good reason to ignore its choice in this particular case >>> while >>> we're honoring it otherwise. >>> >>> So the logic is basically "find the deepest one which isn't disabled" and >>> setting the pointers costs us nothing really. >>> >> >> If the user has chance to disable C6 via /sys, that means c6 works? >> Shouldn't we ignore user space setting during freeze? Otherwise, we will >> lost S0ix? > > We can't ignore it, because we don't know the reason why the state was > disabled. > > It may just not work reliably enough on the given platform. > okay, make sense to me. Thanks, -Aubrey -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] zram: introduce automatic device_id generation
On (03/04/15 14:13), Andrew Morton wrote:
> > +static ssize_t zram_add_show(struct class *class,
> > + struct class_attribute *attr,
> > + char *buf)
> > +{
> > + int ret;
> > +
> > + mutex_lock(&zram_index_mutex);
> > + /* read operation on zram_add is - pick up device_id
> > +* automatically, add corresponding device and return
> > +* that device_id back to user */
> > + ret = zram_add(-1);
> > + mutex_unlock(&zram_index_mutex);
> > +
> > + if (ret < 0)
> > + return ret;
> > + return scnprintf(buf, PAGE_SIZE, "%d\n", ret);
> > +}
>
> Please don't invent new commenting styles. Because doing so inevitably
> creates a mixed-up mess, which is what we now have.
>
sorry. sure, will take care of that next time. thanks for pointing that
out.
-ss
> ---
> a/drivers/block/zram/zram_drv.c~zram-introduce-automatic-device_id-generation-fix
> +++ a/drivers/block/zram/zram_drv.c
> @@ -1281,9 +1281,10 @@ static ssize_t zram_add_show(struct clas
> int ret;
>
> mutex_lock(&zram_index_mutex);
> - /* read operation on zram_add is - pick up device_id
> - * automatically, add corresponding device and return
> - * that device_id back to user */
> + /*
> + * read operation on zram_add is - pick up device_id automatically, add
> + * corresponding device and return that device_id back to user
> + */
> ret = zram_add(-1);
> mutex_unlock(&zram_index_mutex);
>
> _
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 7/9] get the random phy addr according to slot_area info
On Wed, Mar 4, 2015 at 1:35 PM, Yinghai Lu wrote: > On Wed, Mar 4, 2015 at 7:39 AM, Baoquan He wrote: >> >> I got the reason and made a debug patch to fix it. Could you please >> apply it on top of this patchset and try again? Then it will behave well >> and just return 0x13c00 since no random is got. > > random_base can not be move down? > Modify the min_addr will allow move down, and it is safe as we put all related into mem_avoid now. kernel: read done [ linux 9.55MiB 100% 7.26MiB/s ] params: [13fffc000,13fff] cmdline: [13fffb000,13fffb7fe] kernel: [13c00,13f394fff] initrd: [139d7c000,13bfff7e3] initrd: read 1 file done [ initrd.img 34.51MiB 100% 11.39MiB/s ] early console in decompress_kernel decompress_kernel: input: [0x13e9ee3b4-0x13f36b9df], output: [0x13c00-0x13f394fff], heap: [0x13f376ac0-0x13f37eabf] boot via startup_64 KASLR using RDTSC... KASLR using RDTSC... new output: [0x6f00-0x72394fff] Decompressing Linux... xz... Parsing ELF... Performing relocations... done. Booting the kernel. [0.00] bootconsole [uart0] enabled [0.00] Kernel Layout: [0.00] .text: [0x6f00-0x70096a9c] [0.00] .rodata: [0x7020-0x70a4efff] [0.00] .data: [0x70c0-0x70e4e9bf] [0.00] .init: [0x70e5-0x7120bfff] [0.00].bss: [0x71219000-0x7234efff] [0.00].brk: [0x7234f000-0x72374fff] Please check https://git.kernel.org/cgit/linux/kernel/git/yinghai/linux-yinghai.git/log/?h=for-x86-4.0-rc2-aslr for updated patches. Your patches still have some format warning, Please use ./scripts/checkpatch.pl to find them and fix them before next post. Also patch should have "x86,kasl" in the title. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the clk tree
Quoting Geert Uytterhoeven (2015-03-04 01:56:42)
> On Fri, Feb 27, 2015 at 6:42 PM, Stephen Boyd wrote:
> > The problem is the patch was written before struct clk_core moved into
> > the clk.c file and then applied after it moved. So before the move the
> > order of includes would cause the struct definition to be before the
> > place where the tracepoint macros were expanded. The fix is to move the
> > tracepoint include after the struct clk_core definition:
> >
> > -8<
> >
> > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> > index 9aee501b8284..392477033990 100644
> > --- a/drivers/clk/clk.c
> > +++ b/drivers/clk/clk.c
> > @@ -22,9 +22,6 @@
> > #include
> > #include
> >
> > -#define CREATE_TRACE_POINTS
> > -#include
> > -
> > #include "clk.h"
> >
> > static DEFINE_SPINLOCK(enable_lock);
> > @@ -80,6 +77,9 @@ struct clk_core {
> > struct kref ref;
> > };
> >
> > +#define CREATE_TRACE_POINTS
> > +#include
> > +
> > struct clk {
> > struct clk_core *core;
> > const char *dev_id;
>
> Acked-by: Geert Uytterhoeven
Thanks, I've rolled this into the offending commit.
Regards,
Mike
>
> Gr{oetje,eeting}s,
>
> Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> ge...@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like
> that.
> -- Linus Torvalds
--
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: + zram-support-compaction.patch added to -mm tree
Hello,
On (03/04/15 14:02), a...@linux-foundation.org wrote:
[..]
> +++ a/drivers/block/zram/zram_drv.c
> @@ -70,6 +70,27 @@ static inline struct zram *dev_to_zram(s
> return (struct zram *)dev_to_disk(dev)->private_data;
> }
>
> +static ssize_t compact_store(struct device *dev,
> + struct device_attribute *attr, const char *buf, size_t len)
> +{
> + unsigned long nr_migrated;
> + struct zram *zram = dev_to_zram(dev);
> + struct zram_meta *meta;
> +
> + down_read(&zram->init_lock);
> + if (!init_done(zram)) {
> + up_read(&zram->init_lock);
> + return -EINVAL;
> + }
> +
> + meta = zram->meta;
> + nr_migrated = zs_compact(meta->mem_pool);
> + atomic64_add(nr_migrated, &zram->stats.num_migrated);
> + up_read(&zram->init_lock);
> +
> + return len;
> +}
> +
> /* flag operations require table entry bit_spin_lock() being held */
> static int zram_test_flag(struct zram_meta *meta, u32 index,
> enum zram_pageflags flag)
let's stick to "helpers, attrs show/store, mm (meta, page), IO, zram control"
function layout.
so can we please put compact_store() after, say,
354 static ssize_t comp_algorithm_store(...)
function?
-ss
> @@ -374,6 +395,7 @@ ZRAM_ATTR_RO(invalid_io);
> ZRAM_ATTR_RO(notify_free);
> ZRAM_ATTR_RO(zero_pages);
> ZRAM_ATTR_RO(compr_data_size);
> +ZRAM_ATTR_RO(num_migrated);
>
> static inline bool zram_meta_get(struct zram *zram)
> {
> @@ -1031,6 +1053,7 @@ static const struct block_device_operati
> .owner = THIS_MODULE
> };
>
> +static DEVICE_ATTR_WO(compact);
> static DEVICE_ATTR_RW(disksize);
> static DEVICE_ATTR_RO(initstate);
> static DEVICE_ATTR_WO(reset);
> @@ -1049,6 +1072,8 @@ static struct attribute *zram_disk_attrs
> &dev_attr_num_writes.attr,
> &dev_attr_failed_reads.attr,
> &dev_attr_failed_writes.attr,
> + &dev_attr_num_migrated.attr,
> + &dev_attr_compact.attr,
> &dev_attr_invalid_io.attr,
> &dev_attr_notify_free.attr,
> &dev_attr_zero_pages.attr,
> diff -puN drivers/block/zram/zram_drv.h~zram-support-compaction
> drivers/block/zram/zram_drv.h
> --- a/drivers/block/zram/zram_drv.h~zram-support-compaction
> +++ a/drivers/block/zram/zram_drv.h
> @@ -78,6 +78,7 @@ struct zram_stats {
> atomic64_t compr_data_size; /* compressed size of pages stored */
> atomic64_t num_reads; /* failed + successful */
> atomic64_t num_writes; /* --do-- */
> + atomic64_t num_migrated;/* no. of migrated object */
> atomic64_t failed_reads;/* can happen when memory is too low */
> atomic64_t failed_writes; /* can happen when memory is too low */
> atomic64_t invalid_io; /* non-page-aligned I/O requests */
> _
>
> Patches currently in -mm which might be from minc...@kernel.org are
>
> mm-vmscan-fix-the-page-state-calculation-in-too_many_isolated.patch
> mm-page_isolation-check-pfn-validity-before-access.patch
> mm-support-madvisemadv_free.patch
> mm-support-madvisemadv_free-fix.patch
> x86-add-pmd_-for-thp.patch
> x86-add-pmd_-for-thp-fix.patch
> sparc-add-pmd_-for-thp.patch
> sparc-add-pmd_-for-thp-fix.patch
> powerpc-add-pmd_-for-thp.patch
> arm-add-pmd_mkclean-for-thp.patch
> arm64-add-pmd_-for-thp.patch
> mm-dont-split-thp-page-when-syscall-is-called.patch
> mm-dont-split-thp-page-when-syscall-is-called-fix.patch
> mm-dont-split-thp-page-when-syscall-is-called-fix-2.patch
> zram-cosmetic-zram_attr_ro-code-formatting-tweak.patch
> zram-use-idr-instead-of-zram_devices-array.patch
> zram-factor-out-device-reset-from-reset_store.patch
> zram-reorganize-code-layout.patch
> zram-add-dynamic-device-add-remove-functionality.patch
> zram-remove-max_num_devices-limitation.patch
> zram-report-every-added-and-removed-device.patch
> zram-trivial-correct-flag-operations-comment.patch
> zsmalloc-decouple-handle-and-object.patch
> zsmalloc-factor-out-obj_.patch
> zsmalloc-support-compaction.patch
> zsmalloc-adjust-zs_almost_full.patch
> zram-support-compaction.patch
> zsmalloc-record-handle-in-page-private-for-huge-object.patch
> zsmalloc-add-fullness-into-stat.patch
>
> --
> To unsubscribe from this list: send the line "unsubscribe mm-commits" 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 0/2] make automatic device_id generation possible
Hello Sergey, On Wed, Mar 04, 2015 at 11:16:39PM +0900, Sergey Senozhatsky wrote: > Hello, > > Make zram-contol/zram_add interface easier to use. Extend it to support > read and write operations. > > Write operation remains the same: > > echo X > /sys/class/zram-control/zram_add > > will add /dev/zramX (or return error). > > > Read operation is treated as 'pick up available device_id, add new > device and return device_id'. > > Example: >cat /sys/class/zram-control/zram_add > 2 >cat /sys/class/zram-control/zram_add > 3 Thanks for handling my concern quickly and sorry for not sending active feedback in realtime. Maybe I should turn on CONFIG_PREEMPT in my brain. I'm not against but I want to know why we should support user-defined device id. What usecase do you have in mind? Could we support automatic id support only at this moment? Then, if some user complains about that in future, we could turn on user-defined device id easily and we could know the usecase. In summary, I want to support only "cat /sys/class/zram-control/zram_add" unless you have feasible usecase. What do you think about it? > > Sergey Senozhatsky (2): > zram: return zram device_id value from zram_add() > zram: introduce automatic device_id generation > > Documentation/ABI/testing/sysfs-class-zram | 7 -- > Documentation/blockdev/zram.txt| 10 > drivers/block/zram/zram_drv.c | 37 > ++ > 3 files changed, 47 insertions(+), 7 deletions(-) > > -- > 2.3.1.167.g7f4ba4b > -- Kind regards, Minchan Kim -- 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 15/15] x86/lib/memcpy_64.S: Convert memcpy to ALTERNATIVE_2 macro
* Borislav Petkov wrote: > On Wed, Mar 04, 2015 at 08:26:33AM +0100, Ingo Molnar wrote: > > Since most CPUs we care about have ERMS, wouldn't it be better to > > patch in the actual memcpy_erms sequence into the primary memcpy() > > function? It's just about 9 bytes AFAICT. > > Actually, most set REP_GOOD - all Intel family 6 and all relevant > AMDs. > > And only the newer Intels have ERMS. My SNB, for example doesn't > while IVB has it. So I'd guess everything >= IVB would have it. Well, my point equally applies to all variants: it's better to avoid the NOP or JMP overhead (however small it may be), by simply copying the ideal memcpy routine into memcpy()? I.e. while I'd not want to patch in memcpy_orig (it's legacy really), but the other two variants, ERMS and REP MOVSQ could be patched in directly via ALTERNATIVE_2()? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
On Wed, Mar 04, 2015 at 11:35:43AM -0800, Stephen Boyd wrote: > There's another problem with this of_parse_cb design. The regulator > framework requires supplies to be registered before consumers of the > supplies are registered. So when we register L23 we need to make sure > it's supply is already registered (S8 for example). If we used > of_regulator_match() we could sort the array by hand so that we always > register the supplies first. Or we could modify the regulator framework > to have a concept of "orphaned" supplies like the clock framework has so > that when a regulator is registered it waits until its supply is registered. Dependency resolution isn't anything new, I'm not sure why you think this is related to of_parse_cb()? Open coding does exactly the same thing and the ability to have device specific properties on is not obviously related to dependency resolution so perhaps I'm misunderstanding what you're talking about... If you *are* talking about dependency resolution then just bulk registering the regulators (which we should be doing anyway) and then iterating the array until we stop making progress should do the trick for most cases, normally there's only one PMIC in play, or have people who care do a single struct device per regulator and then let the probe deferral stuff sort it out. I'm a bit nervous of the idea of having orphaning without core support, it's not just inter regulator dependencies we need to worry about (they use GPIOs and so on) and there's concerns about debuggability but it is the kind of thing probe deferral was meant to be a cheap implementation of. There was a proposal quite recently from someone at Samsung Poland to do something more coreish and basically split registrations in two, one half registering the things needed for each resource and then a second half which runs once the required resources are registered. Pushing that along might be best, it's a more general approach. The component stuff Russell did has some similarities here. signature.asc Description: Digital signature
Re: [PATCH v2 7/9] get the random phy addr according to slot_area info
On Wed, Mar 4, 2015 at 7:39 AM, Baoquan He wrote: > Hi Yinghai, > > I got the reason and made a debug patch to fix it. Could you please > apply it on top of this patchset and try again? Then it will behave well > and just return 0x13c00 since no random is got. > the fix should be fold into your patch 6. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 0/3] X-Power AXP288 PMIC Fuel Gauge Driver
Hi, On Wed, Feb 04, 2015 at 04:24:35PM -0800, Todd Brandt wrote: > New power_supply driver at driver/power which interfaces with the > axp20x mfd driver as a cell. Provides battery info, monitors for > changes, and generates alerts on temperature and capacity issues > > Sebestian, please review the patch set and consider it for 3.20 rc1. > I've applied it over git.infradead.org/battery-2.6.git/master and > verified that it works. Thanks. Lee, are you ok with patches 1+2 going through power supply subsystem? -- Sebastian signature.asc Description: Digital signature
Re: + zram-support-compaction.patch added to -mm tree
Hello Sergey,
On Thu, Mar 05, 2015 at 09:18:45AM +0900, Sergey Senozhatsky wrote:
> Hello,
>
> On (03/04/15 14:02), a...@linux-foundation.org wrote:
> [..]
> > +++ a/drivers/block/zram/zram_drv.c
> > @@ -70,6 +70,27 @@ static inline struct zram *dev_to_zram(s
> > return (struct zram *)dev_to_disk(dev)->private_data;
> > }
> >
> > +static ssize_t compact_store(struct device *dev,
> > + struct device_attribute *attr, const char *buf, size_t len)
> > +{
> > + unsigned long nr_migrated;
> > + struct zram *zram = dev_to_zram(dev);
> > + struct zram_meta *meta;
> > +
> > + down_read(&zram->init_lock);
> > + if (!init_done(zram)) {
> > + up_read(&zram->init_lock);
> > + return -EINVAL;
> > + }
> > +
> > + meta = zram->meta;
> > + nr_migrated = zs_compact(meta->mem_pool);
> > + atomic64_add(nr_migrated, &zram->stats.num_migrated);
> > + up_read(&zram->init_lock);
> > +
> > + return len;
> > +}
> > +
> > /* flag operations require table entry bit_spin_lock() being held */
> > static int zram_test_flag(struct zram_meta *meta, u32 index,
> > enum zram_pageflags flag)
>
>
> let's stick to "helpers, attrs show/store, mm (meta, page), IO, zram control"
> function layout.
>
> so can we please put compact_store() after, say,
> 354 static ssize_t comp_algorithm_store(...)
>
> function?
I will clean it up after Andrew releases new mmotm. :)
Thanks for the review!
--
Kind regards,
Minchan Kim
--
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 07/15] x86/lib/copy_user_64.S: Convert to ALTERNATIVE_2
* Borislav Petkov wrote: > > 2) in the future: we could actually do a (limited) re-link of the > > kernel during bootup, and patch up the original copy_to_user call > > sites directly to one of the three variants. Alternatives patching > > done at the symbol level. Does current tooling allow something > > like this already? > > Well, I have a patchset which uses relocs to patch vmlinux at build > time. And that was the initial approach to this but you cannot know > which features a CPU supports until boot time so you have to boot. > > BUT(!), you can replace stuff like X86_FEATURE_ALWAYS at build time > already (this is the static_cpu_has_safe() stuff). I'll look into > that later and dust off my relocs pile. We could also do a (limited) relink during early bootup, as part of the alternatives patching pass in essence: for that we need to stick the relocation info into a section and put that into the vmlinux. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/8] pinctrl: bcm: consolidate Broadcom pinctrl drivers
Consolidate Broadcom pinctrl drivers into drivers/pinctrl/bcm/*
Signed-off-by: Ray Jui
---
drivers/pinctrl/Kconfig | 19 +--
drivers/pinctrl/Makefile |3 +--
drivers/pinctrl/bcm/Kconfig | 21 +
drivers/pinctrl/bcm/Makefile |4
drivers/pinctrl/{ => bcm}/pinctrl-bcm281xx.c |4 ++--
drivers/pinctrl/{ => bcm}/pinctrl-bcm2835.c |0
6 files changed, 29 insertions(+), 22 deletions(-)
create mode 100644 drivers/pinctrl/bcm/Kconfig
create mode 100644 drivers/pinctrl/bcm/Makefile
rename drivers/pinctrl/{ => bcm}/pinctrl-bcm281xx.c (99%)
rename drivers/pinctrl/{ => bcm}/pinctrl-bcm2835.c (100%)
diff --git a/drivers/pinctrl/Kconfig b/drivers/pinctrl/Kconfig
index ee9f44a..1a9143d 100644
--- a/drivers/pinctrl/Kconfig
+++ b/drivers/pinctrl/Kconfig
@@ -67,24 +67,6 @@ config PINCTRL_AT91
help
Say Y here to enable the at91 pinctrl driver
-config PINCTRL_BCM2835
- bool
- select PINMUX
- select PINCONF
-
-config PINCTRL_BCM281XX
- bool "Broadcom BCM281xx pinctrl driver"
- depends on OF && (ARCH_BCM_MOBILE || COMPILE_TEST)
- select PINMUX
- select PINCONF
- select GENERIC_PINCONF
- select REGMAP_MMIO
- help
- Say Y here to support Broadcom BCM281xx pinctrl driver, which is used
- for the BCM281xx SoC family, including BCM11130, BCM11140, BCM11351,
- BCM28145, and BCM28155 SoCs. This driver requires the pinctrl
- framework. GPIO is provided by a separate GPIO driver.
-
config PINCTRL_LANTIQ
bool
depends on LANTIQ
@@ -207,6 +189,7 @@ config PINCTRL_ZYNQ
help
This selectes the pinctrl driver for Xilinx Zynq.
+source "drivers/pinctrl/bcm/Kconfig"
source "drivers/pinctrl/berlin/Kconfig"
source "drivers/pinctrl/freescale/Kconfig"
source "drivers/pinctrl/intel/Kconfig"
diff --git a/drivers/pinctrl/Makefile b/drivers/pinctrl/Makefile
index 0475206..c14ce05 100644
--- a/drivers/pinctrl/Makefile
+++ b/drivers/pinctrl/Makefile
@@ -14,8 +14,6 @@ obj-$(CONFIG_PINCTRL_AS3722) += pinctrl-as3722.o
obj-$(CONFIG_PINCTRL_BF54x)+= pinctrl-adi2-bf54x.o
obj-$(CONFIG_PINCTRL_BF60x)+= pinctrl-adi2-bf60x.o
obj-$(CONFIG_PINCTRL_AT91) += pinctrl-at91.o
-obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
-obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
obj-$(CONFIG_PINCTRL_FALCON) += pinctrl-falcon.o
obj-$(CONFIG_PINCTRL_MESON)+= meson/
obj-$(CONFIG_PINCTRL_PALMAS) += pinctrl-palmas.o
@@ -38,6 +36,7 @@ obj-$(CONFIG_PINCTRL_TB10X) += pinctrl-tb10x.o
obj-$(CONFIG_PINCTRL_ST) += pinctrl-st.o
obj-$(CONFIG_PINCTRL_ZYNQ) += pinctrl-zynq.o
+obj-$(CONFIG_ARCH_BCM) += bcm/
obj-$(CONFIG_ARCH_BERLIN) += berlin/
obj-y += freescale/
obj-$(CONFIG_X86) += intel/
diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
new file mode 100644
index 000..bc6d048
--- /dev/null
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -0,0 +1,21 @@
+#
+# Broadcom pinctrl drivers
+#
+
+config PINCTRL_BCM281XX
+ bool "Broadcom BCM281xx pinctrl driver"
+ depends on OF && (ARCH_BCM_MOBILE || COMPILE_TEST)
+ select PINMUX
+ select PINCONF
+ select GENERIC_PINCONF
+ select REGMAP_MMIO
+ help
+ Say Y here to support Broadcom BCM281xx pinctrl driver, which is used
+ for the BCM281xx SoC family, including BCM11130, BCM11140, BCM11351,
+ BCM28145, and BCM28155 SoCs. This driver requires the pinctrl
+ framework. GPIO is provided by a separate GPIO driver.
+
+config PINCTRL_BCM2835
+ bool
+ select PINMUX
+ select PINCONF
diff --git a/drivers/pinctrl/bcm/Makefile b/drivers/pinctrl/bcm/Makefile
new file mode 100644
index 000..7ba80a3
--- /dev/null
+++ b/drivers/pinctrl/bcm/Makefile
@@ -0,0 +1,4 @@
+# Broadcom pinctrl support
+
+obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
+obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
diff --git a/drivers/pinctrl/pinctrl-bcm281xx.c
b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
similarity index 99%
rename from drivers/pinctrl/pinctrl-bcm281xx.c
rename to drivers/pinctrl/bcm/pinctrl-bcm281xx.c
index b88cfe5..9641f1c 100644
--- a/drivers/pinctrl/pinctrl-bcm281xx.c
+++ b/drivers/pinctrl/bcm/pinctrl-bcm281xx.c
@@ -21,8 +21,8 @@
#include
#include
#include
-#include "core.h"
-#include "pinctrl-utils.h"
+#include "../core.h"
+#include "../pinctrl-utils.h"
/* BCM281XX Pin Control Registers Definitions */
diff --git a/drivers/pinctrl/pinctrl-bcm2835.c
b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
similarity index 100%
rename from drivers/pinctrl/pinctrl-bcm2835.c
rename to drivers/pinctrl/bcm/pinctrl-bcm2835.c
--
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 majordom
Re: [PATCH 1/4] mfd: devicetree: bindings: Add Qualcomm RPM regulator subnodes
On Tue, Mar 03, 2015 at 08:02:51AM -0800, Bjorn Andersson wrote:
> rpm {
> compatible = "qcom,rpm-apq8960";
>
> regulators {
> compatible = "qcom,rpm-pm8921-regulators";
Oh, so what you're saying is that the pm8921 is not actually a MFD at
all? Why name it like a MFD component then?
signature.asc
Description: Digital signature
[PATCH v5 8/8] ARM: dts: cygnus: enable GPIO based hook detection
This enables GPIO based phone hook detection for Broadcom BCM911360
phone factor board (bcm911360_entphn)
Signed-off-by: Ray Jui
---
arch/arm/boot/dts/bcm911360_entphn.dts | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/boot/dts/bcm911360_entphn.dts
b/arch/arm/boot/dts/bcm911360_entphn.dts
index d2ee952..7db4843 100644
--- a/arch/arm/boot/dts/bcm911360_entphn.dts
+++ b/arch/arm/boot/dts/bcm911360_entphn.dts
@@ -33,6 +33,7 @@
/dts-v1/;
#include "bcm-cygnus.dtsi"
+#include "dt-bindings/input/input.h"
/ {
model = "Cygnus Enterprise Phone (BCM911360_ENTPHN)";
@@ -50,4 +51,16 @@
uart3: serial@18023000 {
status = "okay";
};
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ hook {
+ label = "HOOK";
+ linux,code = ;
+ gpios = <&gpio_asiu 48 0>;
+ };
+ };
};
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 6/8] pinctrl: cygnus: add gpio/pinconf driver
This adds the initial support of the Broadcom Cygnus GPIO/PINCONF driver that supports all 3 GPIO controllers on Cygnus including the ASIU GPIO controller, the chipCommonG GPIO controller, and the always-on GPIO controller. Basic PINCONF configurations such as bias pull up/down, and drive strength are also supported in this driver. Pins from the ASIU GPIO controller can be individually muxed to GPIO function, through interaction with the Cygnus IOMUX controller Signed-off-by: Ray Jui Reviewed-by: Scott Branden Tested-by: Dmitry Torokhov --- drivers/pinctrl/bcm/Kconfig | 22 + drivers/pinctrl/bcm/Makefile |1 + drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 884 + 3 files changed, 907 insertions(+) create mode 100644 drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig index eb13201..cd11d4d 100644 --- a/drivers/pinctrl/bcm/Kconfig +++ b/drivers/pinctrl/bcm/Kconfig @@ -20,6 +20,28 @@ config PINCTRL_BCM2835 select PINMUX select PINCONF +config PINCTRL_CYGNUS_GPIO + bool "Broadcom Cygnus GPIO (with PINCONF) driver" + depends on OF_GPIO && ARCH_BCM_CYGNUS + select GPIOLIB_IRQCHIP + select PINCONF + select GENERIC_PINCONF + default ARCH_BCM_CYGNUS + help + Say yes here to enable the Broadcom Cygnus GPIO driver. + + The Broadcom Cygnus SoC has 3 GPIO controllers including the ASIU + GPIO controller (ASIU), the chipCommonG GPIO controller (CCM), and + the always-ON GPIO controller (CRMU/AON). All 3 GPIO controllers are + supported by this driver. + + All 3 Cygnus GPIO controllers support basic PINCONF functions such + as bias pull up, pull down, and drive strength configurations, when + these pins are muxed to GPIO. + + Pins from the ASIU GPIO can be individually muxed to GPIO function, + through interaction with the Cygnus IOMUX controller. + config PINCTRL_CYGNUS_MUX bool "Broadcom Cygnus IOMUX driver" depends on (ARCH_BCM_CYGNUS || COMPILE_TEST) diff --git a/drivers/pinctrl/bcm/Makefile b/drivers/pinctrl/bcm/Makefile index bb6beb6..2b2f70e 100644 --- a/drivers/pinctrl/bcm/Makefile +++ b/drivers/pinctrl/bcm/Makefile @@ -2,4 +2,5 @@ obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o +obj-$(CONFIG_PINCTRL_CYGNUS_GPIO) += pinctrl-cygnus-gpio.o obj-$(CONFIG_PINCTRL_CYGNUS_MUX) += pinctrl-cygnus-mux.o diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c new file mode 100644 index 000..4687284 --- /dev/null +++ b/drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c @@ -0,0 +1,884 @@ +/* + * Copyright (C) 2014-2015 Broadcom Corporation + * + * 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 version 2. + * + * This program is distributed "as is" WITHOUT ANY WARRANTY of any + * kind, whether express or implied; without even the implied warranty + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * This file contains the Broadcom Cygnus GPIO driver that supports 3 + * GPIO controllers on Cygnus including the ASIU GPIO controller, the + * chipCommonG GPIO controller, and the always-on GPIO controller. Basic + * PINCONF such as bias pull up/down, and drive strength are also supported + * in this driver. + * + * Pins from the ASIU GPIO can be individually muxed to GPIO function, + * through the interaction with the Cygnus IOMUX controller + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../pinctrl-utils.h" + +#define CYGNUS_GPIO_DATA_IN_OFFSET 0x00 +#define CYGNUS_GPIO_DATA_OUT_OFFSET 0x04 +#define CYGNUS_GPIO_OUT_EN_OFFSET0x08 +#define CYGNUS_GPIO_IN_TYPE_OFFSET 0x0c +#define CYGNUS_GPIO_INT_DE_OFFSET0x10 +#define CYGNUS_GPIO_INT_EDGE_OFFSET 0x14 +#define CYGNUS_GPIO_INT_MSK_OFFSET 0x18 +#define CYGNUS_GPIO_INT_STAT_OFFSET 0x1c +#define CYGNUS_GPIO_INT_MSTAT_OFFSET 0x20 +#define CYGNUS_GPIO_INT_CLR_OFFSET 0x24 +#define CYGNUS_GPIO_PAD_RES_OFFSET 0x34 +#define CYGNUS_GPIO_RES_EN_OFFSET0x38 + +/* drive strength control for ASIU GPIO */ +#define CYGNUS_GPIO_ASIU_DRV0_CTRL_OFFSET 0x58 + +/* drive strength control for CCM/CRMU (AON) GPIO */ +#define CYGNUS_GPIO_DRV0_CTRL_OFFSET 0x00 + +#define GPIO_BANK_SIZE 0x200 +#define NGPIOS_PER_BANK 32 +#define GPIO_BANK(pin) ((pin) / NGPIOS_PER_BANK) + +#define CYGNUS_GPIO_REG(pin, reg) (GPIO_BANK(pin) * GPIO_BANK_SIZE + (reg)) +#define CYGNUS_GPIO_SHIFT(pin) ((pin) % NGPIOS_PER_BANK) + +#define GPIO_DRV_STRENGTH_BIT_SHIFT 20 +#define GPIO_DRV_STRENGTH
Re: [PATCH v2 07/15] x86/lib/copy_user_64.S: Convert to ALTERNATIVE_2
* Borislav Petkov wrote: > On Wed, Mar 04, 2015 at 08:13:24AM +0100, Ingo Molnar wrote: > > Btw., the x86 memset() variants are using this today, and I think this > > is the most optimal jump-patching variant, even if it means a small > > amount of code duplication between the copy_user variants. > > Yeah, the problem with that one was that we patch a huge amount of code, > see the dump below. > > The X86_FEATURE_REP_GOOD thing replaces a 172 bytes memset with the > 42 byte REP;STOSQ version and the X86_FEATURE_ERMS does the same > with REP;STOSB. So I'd not patch in the large _orig variant, it's legacy mostly - but the two fast variants? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 5/8] pinctrl: Cygnus: define Broadcom Cygnus GPIO/PINCONF binding
Document the GPIO/PINCONF device tree binding for Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../bindings/pinctrl/brcm,cygnus-gpio.txt | 102
1 file changed, 102 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
new file mode 100644
index 000..9b9196c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
@@ -0,0 +1,102 @@
+Broadcom Cygnus GPIO/PINCONF Controller
+
+Required properties:
+
+- compatible:
+Must be "brcm,cygnus-gpio"
+
+- reg:
+Define the base and range of the I/O address space that contains the Cygnus
+GPIO/PINCONF controller registers
+
+- ngpios:
+Total number of GPIOs the controller provides
+
+- #gpio-cells:
+Must be two. The first cell is the GPIO pin number (within the
+controller's pin space) and the second cell is used for the following:
+bit[0]: polarity (0 for active high and 1 for active low)
+
+- gpio-controller:
+Specifies that the node is a GPIO controller
+
+Optional properties:
+
+- interrupts:
+Interrupt ID
+
+- interrupt-controller:
+Specifies that the node is an interrupt controller
+
+- pinmux:
+Specifies the phandle to the IOMUX device, where pins can be individually
+muxed to GPIO
+
+Supported generic PINCONF properties in child nodes:
+
+- pins:
+The list of pins (within the controller's own pin space) that properties
+in the node apply to. Pin names are "gpio-"
+
+- bias-disable:
+Disable pin bias
+
+- bias-pull-up:
+Enable internal pull up resistor
+
+- bias-pull-down:
+Enable internal pull down resistor
+
+- drive-strength:
+Valid drive strength values include 2, 4, 6, 8, 10, 12, 14, 16 (mA)
+
+Example:
+ gpio_ccm: gpio@1800a000 {
+ compatible = "brcm,cygnus-gpio";
+ reg = <0x1800a000 0x50>,
+ <0x0301d164 0x20>;
+ ngpios = <24>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupts = ;
+ interrupt-controller;
+
+ touch_pins: touch_pins {
+ pwr: pwr {
+ pins = "gpio-0";
+ drive-strength = <16>;
+ };
+
+ event: event {
+ pins = "gpio-1";
+ bias-pull-up;
+ };
+ };
+ };
+
+ gpio_asiu: gpio@180a5000 {
+ compatible = "brcm,cygnus-gpio";
+ reg = <0x180a5000 0x668>;
+ ngpios = <146>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupts = ;
+ interrupt-controller;
+ };
+
+ /*
+* Touchscreen that uses the CCM GPIO 0 and 1
+*/
+ tsc {
+ ...
+ ...
+ gpio-pwr = <&gpio_ccm 0 0>;
+ gpio-event = <&gpio_ccm 1 0>;
+ };
+
+ /* Bluetooth that uses the ASIU GPIO 5, with polarity inverted */
+ bluetooth {
+ ...
+ ...
+ bcm,rfkill-bank-sel = <&gpio_asiu 5 1>
+ }
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 4/8] ARM: dts: enable IOMUX for Broadcom Cygnus
This enables the IOMUX support for Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Tested-by: Dmitry Torokhov
---
arch/arm/boot/dts/bcm-cygnus.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index ff5fb6a..1cbae6a 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -54,6 +54,12 @@
/include/ "bcm-cygnus-clock.dtsi"
+ pinctrl: pinctrl@0x0301d0c8 {
+ compatible = "brcm,cygnus-pinmux";
+ reg = <0x0301d0c8 0x30>,
+ <0x0301d24c 0x2c>;
+ };
+
amba {
#address-cells = <1>;
#size-cells = <1>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 7/8] ARM: dts: enable GPIO for Broadcom Cygnus
This enables all 3 GPIO controllers including the ASIU GPIO, the
chipcommonG GPIO, and the ALWAYS-ON GPIO, for Broadcom Cygnus SoC
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Tested-by: Dmitry Torokhov
---
arch/arm/boot/dts/bcm-cygnus.dtsi | 33 +
1 file changed, 33 insertions(+)
diff --git a/arch/arm/boot/dts/bcm-cygnus.dtsi
b/arch/arm/boot/dts/bcm-cygnus.dtsi
index 1cbae6a..8d247d2 100644
--- a/arch/arm/boot/dts/bcm-cygnus.dtsi
+++ b/arch/arm/boot/dts/bcm-cygnus.dtsi
@@ -60,6 +60,39 @@
<0x0301d24c 0x2c>;
};
+ gpio_crmu: gpio@03024800 {
+ compatible = "brcm,cygnus-gpio";
+ reg = <0x03024800 0x50>,
+ <0x03024008 0x18>;
+ ngpios = <6>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ };
+
+ gpio_ccm: gpio@1800a000 {
+ compatible = "brcm,cygnus-gpio";
+ reg = <0x1800a000 0x50>,
+ <0x0301d164 0x20>;
+ ngpios = <24>;
+ #gpio-cells = <2>;
+ gpio-controller;
+ interrupts = ;
+ interrupt-controller;
+ };
+
+ gpio_asiu: gpio@180a5000 {
+ compatible = "brcm,cygnus-gpio";
+ reg = <0x180a5000 0x668>;
+ ngpios = <146>;
+ #gpio-cells = <2>;
+ gpio-controller;
+
+ pinmux = <&pinctrl>;
+
+ interrupt-controller;
+ interrupts = ;
+ };
+
amba {
#address-cells = <1>;
#size-cells = <1>;
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 3/8] pinctrl: cygnus: add initial IOMUX driver support
This adds the initial driver support for the Broadcom Cygnus IOMUX
controller. The Cygnus IOMUX controller supports group based mux
configuration but allows certain pins to be muxed to GPIO individually
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
Tested-by: Dmitry Torokhov
---
drivers/pinctrl/bcm/Kconfig | 13 +
drivers/pinctrl/bcm/Makefile |5 +-
drivers/pinctrl/bcm/pinctrl-cygnus-mux.c | 1022 ++
3 files changed, 1038 insertions(+), 2 deletions(-)
create mode 100644 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
diff --git a/drivers/pinctrl/bcm/Kconfig b/drivers/pinctrl/bcm/Kconfig
index bc6d048..eb13201 100644
--- a/drivers/pinctrl/bcm/Kconfig
+++ b/drivers/pinctrl/bcm/Kconfig
@@ -19,3 +19,16 @@ config PINCTRL_BCM2835
bool
select PINMUX
select PINCONF
+
+config PINCTRL_CYGNUS_MUX
+ bool "Broadcom Cygnus IOMUX driver"
+ depends on (ARCH_BCM_CYGNUS || COMPILE_TEST)
+ select PINMUX
+ select GENERIC_PINCONF
+ default ARCH_BCM_CYGNUS
+ help
+ Say yes here to enable the Broadcom Cygnus IOMUX driver.
+
+ The Broadcom Cygnus IOMUX driver supports group based IOMUX
+ configuration, with the exception that certain individual pins
+ can be overrided to GPIO function
diff --git a/drivers/pinctrl/bcm/Makefile b/drivers/pinctrl/bcm/Makefile
index 7ba80a3..bb6beb6 100644
--- a/drivers/pinctrl/bcm/Makefile
+++ b/drivers/pinctrl/bcm/Makefile
@@ -1,4 +1,5 @@
# Broadcom pinctrl support
-obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
-obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
+obj-$(CONFIG_PINCTRL_BCM281XX) += pinctrl-bcm281xx.o
+obj-$(CONFIG_PINCTRL_BCM2835) += pinctrl-bcm2835.o
+obj-$(CONFIG_PINCTRL_CYGNUS_MUX) += pinctrl-cygnus-mux.o
diff --git a/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
new file mode 100644
index 000..f9a9283
--- /dev/null
+++ b/drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
@@ -0,0 +1,1022 @@
+/* Copyright (C) 2014-2015 Broadcom Corporation
+ *
+ * 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 version 2.
+ *
+ * This program is distributed "as is" WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * This file contains the Cygnus IOMUX driver that supports group based PINMUX
+ * configuration. Although PINMUX configuration is mainly group based, the
+ * Cygnus IOMUX controller allows certain pins to be individually muxed to GPIO
+ * function, and therefore be controlled by the Cygnus ASIU GPIO controller
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include "../core.h"
+#include "../pinctrl-utils.h"
+
+#define CYGNUS_NUM_IOMUX_REGS 8
+#define CYGNUS_NUM_MUX_PER_REG8
+#define CYGNUS_NUM_IOMUX (CYGNUS_NUM_IOMUX_REGS * \
+ CYGNUS_NUM_MUX_PER_REG)
+
+/*
+ * Cygnus IOMUX register description
+ *
+ * @offset: register offset for mux configuration of a group
+ * @shift: bit shift for mux configuration of a group
+ * @alt: alternate function to set to
+ */
+struct cygnus_mux {
+ unsigned int offset;
+ unsigned int shift;
+ unsigned int alt;
+};
+
+/*
+ * Keep track of Cygnus IOMUX configuration and prevent double configuration
+ *
+ * @cygnus_mux: Cygnus IOMUX register description
+ * @is_configured: flag to indicate whether a mux setting has already been
+ * configured
+ */
+struct cygnus_mux_log {
+ struct cygnus_mux mux;
+ bool is_configured;
+};
+
+/*
+ * Group based IOMUX configuration
+ *
+ * @name: name of the group
+ * @pins: array of pins used by this group
+ * @num_pins: total number of pins used by this group
+ * @mux: Cygnus group based IOMUX configuration
+ */
+struct cygnus_pin_group {
+ const char *name;
+ const unsigned *pins;
+ unsigned num_pins;
+ struct cygnus_mux mux;
+};
+
+/*
+ * Cygnus mux function and supported pin groups
+ *
+ * @name: name of the function
+ * @groups: array of groups that can be supported by this function
+ * @num_groups: total number of groups that can be supported by this function
+ */
+struct cygnus_pin_function {
+ const char *name;
+ const char * const *groups;
+ unsigned num_groups;
+};
+
+/*
+ * Cygnus IOMUX pinctrl core
+ *
+ * @pctl: pointer to pinctrl_dev
+ * @dev: pointer to device
+ * @base0: first I/O register base of the Cygnus IOMUX controller
+ * @base1: second I/O register base
+ * @groups: pointer to array of groups
+ * @num_groups: total number of groups
+ * @functions: pointer to array of functions
+ * @num_functions: total
[PATCH v5 2/8] pinctrl: Broadcom Cygnus pinctrl device tree binding
Device tree binding documentation for Broadcom Cygnus IOMUX driver
Signed-off-by: Ray Jui
Reviewed-by: Scott Branden
---
.../bindings/pinctrl/brcm,cygnus-pinmux.txt| 132
1 file changed, 132 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt
b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt
new file mode 100644
index 000..3600d5c
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt
@@ -0,0 +1,132 @@
+Broadcom Cygnus IOMUX Controller
+
+The Cygnus IOMUX controller supports group based mux configuration. In
+addition, certain pins can be muxed to GPIO function individually.
+
+Required properties:
+
+- compatible:
+Must be "brcm,cygnus-pinmux"
+
+- reg:
+Define the base and range of the I/O address space that contains the Cygnus
+IOMUX registers
+
+Properties in subnodes:
+
+- function:
+The mux function to select
+
+- groups:
+The list of groups to select with a given function
+
+For more details, refer to
+Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+
+For example:
+
+ pinmux: pinmux@0x0301d0c8 {
+ compatible = "brcm,cygnus-pinmux";
+ reg = <0x0301d0c8 0x1b0>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s0_default>;
+
+ i2s0_default: i2s0_default {
+ mux {
+ function = "i2s0";
+ groups = "i2s0_0_grp", "i2s0_1_grp";
+ };
+ };
+ };
+
+List of supported functions and groups in Cygnus:
+
+"i2s0": "i2s0_0_grp", "i2s0_1_grp"
+
+"i2s1": "i2s1_0_grp", "i2s1_1_grp"
+
+"i2s2": "i2s2_0_grp", "i2s2_1_grp", "i2s2_2_grp", "i2s2_3_grp", "i2s2_4_grp"
+
+"spdif": "spdif_grp"
+
+"pwm0": "pwm0_grp"
+
+"pwm1": "pwm1_grp"
+
+"pwm2": "pwm2_grp"
+
+"pwm3": "pwm3_grp"
+
+"pwm4": "pwm4_grp"
+
+"pwm5": "pwm5_grp"
+
+"key": "key0_grp", "key1_grp", "key2_grp", "key3_grp", "key4_grp", "key5_grp",
+"key6_grp", "key7_grp", "key8_grp", "key9_grp", "key10_grp", "key11_grp",
+"key12_grp", "key13_grp", "key14_grp", "key15_grp"
+
+"audio_dte": "audio_dte0_grp", "audio_dte1_grp", "audio_dte2_grp",
"audio_dte3_grp"
+
+"smart_card0": "smart_card0_grp", "smart_card0_fcb_grp"
+
+"smart_card1": "smart_card1_grp", "smart_card1_fcb_grp"
+
+"spi0": "spi0_grp"
+
+"spi1": "spi1_grp"
+
+"spi2": "spi2_grp"
+
+"spi3": "spi3_grp"
+
+"spi4": "spi4_0_grp", "spi4_1_grp"
+
+"spi5": "spi5_grp"
+
+"sw_led0": "sw_led0_0_grp", "sw_led0_1_grp"
+
+"sw_led1": "sw_led1_grp"
+
+"sw_led2": "sw_led2_0_grp", "sw_led2_1_grp"
+
+"d1w": "d1w_grp"
+
+"lcd": "lcd_grp"
+
+"sram": "sram_0_grp", "sram_1_grp"
+
+"uart0": "uart0_grp"
+
+"uart1": "uart1_grp", "uart1_dte_grp"
+
+"uart2": "uart2_grp"
+
+"uart3": "uart3_grp"
+
+"uart4": "uart4_grp"
+
+"qspi": "qspi_0_grp", "qspi_1_grp"
+
+"nand": "nand_grp"
+
+"sdio0": "sdio0_grp", "sdio0_cd_grp", "sdio0_mmc_grp"
+
+"sdio1": "sdio1_data_0_grp", "sdio1_data_1_grp", "sdio1_cd_grp",
+"sdio1_led_grp", "sdio1_mmc_grp"
+
+"can0": "can0_grp"
+
+"can1": "can1_grp"
+
+"cam": "cam_led_grp", "cam_0_grp", "cam_1_grp"
+
+"bsc1": "bsc1_grp"
+
+"pcie_clkreq": "pcie_clkreq_grp"
+
+"usb0_oc": "usb0_oc_grp"
+
+"usb1_oc": "usb1_oc_grp"
+
+"usb2_oc": "usb2_oc_grp"
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/8] Add pinctrl support to Broadcom Cygnus SoC
This patchset contains the pinmux (IOMUX) and GPIO/PINCONF support for
Broadcom Cygnus SoC.
The Cygnus IOMUX controller supports group based mux
configuration and allows certain pins to be muxed to GPIO function
individually. The IOMUX controller is supported by the pinctrl-cygnus-mux.c
driver.
Cygnus has 3 GPIO controllers: 1) the ASIU GPIO; 2) the chipCommonG GPIO;
and 3) the ALWAYS-ON GPIO. All 3 Cygnus GPIO controllers support basic PINCONF
functions such as bias pull up, pull down, and drive strength configuration,
when pins are muxed to GPIO. GPIO/PINCONF support is in the
pinctrl-cygnus-gpio.c driver.
Note pins from the ASIU GPIO can be individually muxed to GPIO function,
through interaction with the Cygnus IOMUX controller.
Changes from v4:
- Rebased to Linux 4.0-rc2
- Switched to use the newly available pinconf_generic_dt_node_to_map_group
function for mapping DT mux properties in the IOMUX driver. This helps
to get rid of customized device tree parsing code in the driver
- Consolidated the other Cygnus GPIO/PINCONF patchset into one single patchset
- Tuned up the GPIO/PINCONF driver a bit more, based on code review comments
from Linus Walleij
Changes from v3:
- Fix the driver to have more proper use of "const" in various places
- Other minor improvements
Changes from v2:
- Consolidate all Broadcom pinctrl drivers into drivers/pinctrl/bcm/*
- Change the Cygnus IOMUX driver to use standard Linux pinctrl subnode
properties such as "function" and "groups" for pinmux configuration, instead
of non-standard properties such as "brcm,function" and "brcm,group"
- Use real function names like "spi0", "lcd", "key", and etc. instead of HW
specific mux names like "alt1", "alt2", "alt3", and etc.
- Add suffix "grp" to all group names
- Add support to allow individual pins to be muxed to GPIO function through
subsystem callbacks "gpio_request_enable" and "gpio_disable_free", and get rid
of all GPIO groups
- Other minor improvements in the driver
Changes from v1:
- Fix a typo in device tree binding document
Ray Jui (8):
pinctrl: bcm: consolidate Broadcom pinctrl drivers
pinctrl: Broadcom Cygnus pinctrl device tree binding
pinctrl: cygnus: add initial IOMUX driver support
ARM: dts: enable IOMUX for Broadcom Cygnus
pinctrl: Cygnus: define Broadcom Cygnus GPIO/PINCONF binding
pinctrl: cygnus: add gpio/pinconf driver
ARM: dts: enable GPIO for Broadcom Cygnus
ARM: dts: cygnus: enable GPIO based hook detection
.../bindings/pinctrl/brcm,cygnus-gpio.txt | 102 ++
.../bindings/pinctrl/brcm,cygnus-pinmux.txt| 132 +++
arch/arm/boot/dts/bcm-cygnus.dtsi | 39 +
arch/arm/boot/dts/bcm911360_entphn.dts | 13 +
drivers/pinctrl/Kconfig| 19 +-
drivers/pinctrl/Makefile |3 +-
drivers/pinctrl/bcm/Kconfig| 56 ++
drivers/pinctrl/bcm/Makefile |6 +
drivers/pinctrl/{ => bcm}/pinctrl-bcm281xx.c |4 +-
drivers/pinctrl/{ => bcm}/pinctrl-bcm2835.c|0
drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c | 884 +
drivers/pinctrl/bcm/pinctrl-cygnus-mux.c | 1022
12 files changed, 2258 insertions(+), 22 deletions(-)
create mode 100644
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-gpio.txt
create mode 100644
Documentation/devicetree/bindings/pinctrl/brcm,cygnus-pinmux.txt
create mode 100644 drivers/pinctrl/bcm/Kconfig
create mode 100644 drivers/pinctrl/bcm/Makefile
rename drivers/pinctrl/{ => bcm}/pinctrl-bcm281xx.c (99%)
rename drivers/pinctrl/{ => bcm}/pinctrl-bcm2835.c (100%)
create mode 100644 drivers/pinctrl/bcm/pinctrl-cygnus-gpio.c
create mode 100644 drivers/pinctrl/bcm/pinctrl-cygnus-mux.c
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 4/6] ARM: dts: omap3-gta04: Add battery support
Hi, On Wed, Feb 04, 2015 at 11:14:33PM +0100, Marek Belisko wrote: > Signed-off-by: Marek Belisko > --- > arch/arm/boot/dts/omap3-gta04.dtsi | 30 ++ > 1 file changed, 30 insertions(+) DTS changes must go via omap-dt tree once the driver changes have been merged. -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 2/4] regulator: core: Expose init_data to of_parse_cb
On Tue, Mar 03, 2015 at 08:15:41AM -0800, Bjorn Andersson wrote: > On Tue 03 Mar 04:50 PST 2015, Mark Brown wrote: > > Why would the driver need to do that? I guess I'll see later on in the > > series but the changelog should make that clear. Drivers aren't > > supposed to ever need to look at their init data, modifying the init > > data from what the machine provied is usually a red flag. > I think what you're getting at is that the init_data should come from a > board file or device tree. With the reworkings done in patch 4 this Yes, that's the entire purpose of the init data. > As this matches a regulator, there is no way for the driver (or anyone > else to affect the init_data). That's a goal not a problem. There is an interface for the machine description to configure the system integration which neither the regulator driver nor the consumer driver should be a part of. > The problem at hand is that there is nothing in this code path telling > the core that we can do DRMS - something we can figure out in the driver > by basically looking at the ops for the registering regulator. No, that way lies people doing all the crap they usually do with putting the default constraints for their reference design or the maximum limits for their PMIC into the constraints and then getting upset when drivers then go and use this to make their CPU catch fire or whatever. You need to provide a way for the machine description to say DRMS (or really setting the load which is what's actually happening here now we have that op) is safe on a given system. I think that means adding a new permission to DT and then using that; it's more sensible to want to use this feature in the context where we're working with an external processor which also has a chance to have system tuning than when we're working with the PMIC directly so a permission that enable load setting seems good. We could even kill the existing DRMS permission, there's one user in a legacy STE platform. signature.asc Description: Digital signature
Re: [PATCH v2 7/7] zsmalloc: add fullness into stat
Hello Andrew,
On Wed, Mar 04, 2015 at 02:02:02PM -0800, Andrew Morton wrote:
> On Wed, 4 Mar 2015 14:01:32 +0900 Minchan Kim wrote:
>
> > +static int zs_stats_size_show(struct seq_file *s, void *v)
> > +{
> > + int i;
> > + struct zs_pool *pool = s->private;
> > + struct size_class *class;
> > + int objs_per_zspage;
> > + unsigned long class_almost_full, class_almost_empty;
> > + unsigned long obj_allocated, obj_used, pages_used;
> > + unsigned long total_class_almost_full = 0, total_class_almost_empty = 0;
> > + unsigned long total_objs = 0, total_used_objs = 0, total_pages = 0;
> > +
> > + seq_printf(s, " %5s %5s %11s %12s %13s %10s %10s %16s\n",
> > + "class", "size", "almost_full", "almost_empty",
> > + "obj_allocated", "obj_used", "pages_used",
> > + "pages_per_zspage");
>
> Documentation?
It should been since [0f050d9, mm/zsmalloc: add statistics support].
Anyway, I will try it.
Where is right place to put only this statistics in Documentation?
Documentation/zsmalloc.txt?
Documentation/vm/zsmalloc.txt?
Documentation/blockdev/zram.txt?
Documentation/ABI/testing/sysfs-block-zram?
I hope you suggest.
--
Kind regards,
Minchan Kim
--
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 04/10] xen/blkfront: separate ring information to an new struct
On 03/05/2015 05:21 AM, Konrad Rzeszutek Wilk wrote: >>> David assertion that better performance and scalbility can be gained >>> with grant table locking and TLB flush avoidance is interesting - as >>> 1). The grant locking is going in Xen 4.6 but not earlier - so when running >>> on older hypervisors this gives an performance benefit. >>> >>> 2). I have not seen any prototype TLB flush avoidance code so not know >>> when that would be available. >>> >>> Perhaps a better choice is to do the removal of the persistence support >>> when the changes in Xen hypervisor are known? >>> >> >> With patch: [PATCH v5 0/2] gnttab: Improve scaleability, I can get >> nearly the same performance as without persistence support. >> >> But I'm not sure about the benchmark described here: >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/block/xen-blkfront.c?id=0a8704a51f386cab7394e38ff1d66eef924d8ab8 > > Meaning you weren't able to do the same test? > I can if there are more details about how to set up this 5 and 10 guests environment and test pattern have been used. Just think it might be save time if somebody still have the similar environment by hand. Roger and Felipe, if you still have the environment could you please have a quick compare about feature-persistent performance with patch [PATCH v5 0/2] gnttab: Improve scaleability? Thanks, -Bob -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 3/6] Documentation: DT: Document twl4030-madc-battery bindings
Hi, On Wed, Feb 04, 2015 at 11:14:32PM +0100, Marek Belisko wrote: > + - volt-to-capacity-charging-map : list of voltage(mV):level(%) values > + for charging calibration (see example) > + - volt-to-capacity-discharging-map : list of voltage(mV):level(%) values > + for discharging calibration (see example) Please prefix these properties with "ti," -- Sebastian signature.asc Description: Digital signature
Re: [PATCH] firmware_class: Add firmware filename overrides
On Wed, Mar 04, 2015 at 03:57:09PM -0800, Greg KH wrote: > On Wed, Mar 04, 2015 at 03:25:10PM -0800, Charlie Mooney wrote: > > This patch adds an additional feature to the firmware_class.c module. > > To allow a unified method of specifying new firmware locations when > > drivers request a firmware binary to update their devices with, we > > have added the concept of a "fw override" > > > > A fw override is a rule that matches firmware requests based on the > > name of the device requesting the fw and what the filename for the > > fw they are requesting is, and overrides their requests with a new > > value. > > > > Overrides are set up by piping a description of the override into > > an attribute set up at /sys/class/firmware/fw_override. The string > > should be a null-deliminited list of the firmware name you want to > > over ride, the new name to replace it with, and the device name that > > you want the override to apply to. For example you could set up > > an override for a device called "my_device" so that any time it > > requests a firmware called "my_fw.bin" it instead gets "new_fw.bin" > > with the following command: > > > > echo -e 'my_fw.bin\0new_fw.bin\0my_device\0' > > > /sys/class/firmware/fw_override > > I hate to ask, but I have to, why do you need this? We may have single driver serve several devices (a touchscreen and a touchpad) that require different firmware/config file to function. We have several options: - modify the driver to allow changing firmware name from userspace - gets old when there are several drivers that need that; - encode part numbers in the driver and request different firmware - not easily maintainable, still has an issue that same part might be used for different devices; - replace the firmware file on disk before initiating firmware load - does not work well with read-only file systems; - have udev supply different data - udev went out of fashion; - have one central place (firmware loader) that users can control to override the names - this solution. Thanks. -- Dmitry -- 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: live kernel upgrades (was: live kernel patching design)
* Jiri Slaby wrote: > On 02/24/2015, 10:16 AM, Ingo Molnar wrote: > > > > and we don't design the Linux kernel for weird, extreme cases, we > > design for the common, sane case that has the broadest appeal, and > > we hope that the feature garners enough interest to be > > maintainable. > > Hello, > > oh, so why do we have NR_CPUS up to 8192, then? [...] Because: - More CPUs is not some weird dead end, but a natural direction of hardware development. - Furthermore, we've gained a lot of scalability and other improvements all around the kernel just by virtue of big iron running into those problems first. - In the typical case there's no friction between 8192 CPUs and the kernel's design. Where there was friction (and it happened), we pushed back. Such benefits add up and 8K CPUs support is a success story today. That positive, symbiotic, multi-discipline relationship between 8K CPUs support design goals and 'regular Linux' design goals stands in stark contrast with the single-issue approach that live kernel patching is designing itself into a dead end so early on ... Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] livepatch: fix patched module loading race
(2015/03/04 22:17), Petr Mladek wrote: > On Tue 2015-03-03 17:02:22, Josh Poimboeuf wrote: >> It's possible for klp_register_patch() to see a module before the COMING >> notifier is called, or after the GOING notifier is called. >> >> That can cause all kinds of ugly races. As Pter Mladek reported: >> >> "The problem is that we do not keep the klp_mutex lock all the time when >> the module is being added or removed. >> >> First, the module is visible even before ftrace is ready. If we enable a >> patch >> in this time frame, adding ftrace ops will fail and the patch will get >> rejected >> just because bad timing. > > Ah, this is not true after all. I did not properly check when > MODULE_STATE_COMING was set. I though that it was before ftrace was > initialized but it was not true. > > >> Second, if we are "lucky" and enable the patch for the coming module when >> the >> ftrace is ready but before the module notifier has been called. The >> notifier >> will try to enable the patch as well. It will detect that it is already >> patched, >> return error, and the module will get rejected just because bad >> timing. The more serious problem is that it will not call the notifier for >> going module, so that the mess will stay there and we wont be able to load >> the module later. > > Ah, the race is there but the effect is not that serious in the > end. It seems that errors from module notifiers are ignored. In fact, > we do not propagate the error from klp_module_notify_coming(). It means > that WARN() from klp_enable_object() will be printed but the module > will be loaded and patched. > > I am sorry, I was confused by kGraft where kgr_module_init() was > called directly from module_load(). The errors were propagated. It > means that kGraft rejects module when the patch cannot be applied. > > Note that the current solution is perfectly fine for the simple > consistency model. > > >> Third, similar problems are there for going module. If a patch is enabled >> after >> the notifier finishes but before the module is removed from the list of >> modules, >> the new patch will be applied to the module. The module might disappear at >> anytime when the patch enabling is in progress, so there might be an >> access out >> of memory. Or the whole patch might be applied and some mess will be left, >> so it will not be possible to load/patch the module again." > > This is true. No, that's not true if you try_get_module() before patching. After the module state goes GOING (more correctly say, after try_release_module_ref() succeeded), all try_get_module() must fail :) So, please make sure to get module when applying patches. Thank you, -- Masami HIRAMATSU Software Platform Research Dept. Linux Technology Research Center Hitachi, Ltd., Yokohama Research Laboratory E-mail: masami.hiramatsu...@hitachi.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.0-rc1 v17 5/6] x86/nmi: Use common printk functions
* Daniel Thompson wrote: > Much of the code sitting in arch/x86/kernel/apic/hw_nmi.c to support > safe all-cpu backtracing from NMI has been copied to printk.c to > make it accessible to other architectures. > > Port the x86 NMI backtrace to the generic code. Is there any difference between the generic and the x86 code as they stand today? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [tip:perf/x86] perf/x86/intel: Support task events with Intel CQM
* Vince Weaver wrote:
> On Wed, 25 Feb 2015, tip-bot for Matt Fleming wrote:
>
> > diff --git a/include/uapi/linux/perf_event.h
> > b/include/uapi/linux/perf_event.h
> > index 1e3cd07..3c8b45d 100644
> > --- a/include/uapi/linux/perf_event.h
> > +++ b/include/uapi/linux/perf_event.h
> > @@ -32,6 +32,7 @@ enum perf_type_id {
> > PERF_TYPE_HW_CACHE = 3,
> > PERF_TYPE_RAW = 4,
> > PERF_TYPE_BREAKPOINT= 5,
> > + PERF_TYPE_INTEL_CQM = 6,
> >
> > PERF_TYPE_MAX, /* non-ABI */
> > };
>
> I thought the rule was no adding support for things in perf_event unless
> they were sufficiently generic as to be cross-architecture.
>
> Having a high-level event type with "intel" in the name seems awfully
> specific.
That's a fair point. Peter?
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/2] add dts for PopMetal board
Hi Heiko: Thanks very much. On 2015年03月05日 03:57, Heiko Stuebner wrote: Hi Andy, Am Sonntag, 1. März 2015, 17:25:14 schrieb Andy Yan: PopMetal is a rockchip rk3288 based board made by ChipSpark, which has many interface such as VGA,HDMI,usb,ir,sdcad and lots of sensors such as gyroscope(L3G4200D),accelerometer(mma8452),compass(AK8963C). http://wiki.chipspark.com/en/index.php?title=PopMetal This patch add basic support for it, which can boot the board into a shell with linux boot logo on hdmi, sdcard and many sensors enabled. More feather will be enabled later. I've added both patches to my dts branch Heiko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 7/7] zsmalloc: add fullness into stat
On Thu, 5 Mar 2015 09:43:31 +0900 Minchan Kim wrote:
> Hello Andrew,
>
> On Wed, Mar 04, 2015 at 02:02:02PM -0800, Andrew Morton wrote:
> > On Wed, 4 Mar 2015 14:01:32 +0900 Minchan Kim wrote:
> >
> > > +static int zs_stats_size_show(struct seq_file *s, void *v)
> > > +{
> > > + int i;
> > > + struct zs_pool *pool = s->private;
> > > + struct size_class *class;
> > > + int objs_per_zspage;
> > > + unsigned long class_almost_full, class_almost_empty;
> > > + unsigned long obj_allocated, obj_used, pages_used;
> > > + unsigned long total_class_almost_full = 0, total_class_almost_empty = 0;
> > > + unsigned long total_objs = 0, total_used_objs = 0, total_pages = 0;
> > > +
> > > + seq_printf(s, " %5s %5s %11s %12s %13s %10s %10s %16s\n",
> > > + "class", "size", "almost_full", "almost_empty",
> > > + "obj_allocated", "obj_used", "pages_used",
> > > + "pages_per_zspage");
> >
> > Documentation?
>
> It should been since [0f050d9, mm/zsmalloc: add statistics support].
> Anyway, I will try it.
> Where is right place to put only this statistics in Documentation?
>
> Documentation/zsmalloc.txt?
> Documentation/vm/zsmalloc.txt?
> Documentation/blockdev/zram.txt?
> Documentation/ABI/testing/sysfs-block-zram?
hm, this is debugfs so Documentation/ABI/testing/sysfs-block-zram isn't
the right place.
akpm3:/usr/src/25> grep -rli zsmalloc Documentation
akpm3:/usr/src/25>
lol.
Documentation/vm/zsmalloc.txt looks good.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] regulator: qcom: Rework to single platform device
On Wed, Mar 04, 2015 at 03:51:46PM -0800, Bjorn Andersson wrote: > I took a stab at implementing EPROBE_DEFER within qcom_rpm-regulator, > but as it's a mixture of internal and external dependencies (e.g. > <&pm8921_s4> vs <&pm8921_mpp 7>) this became quite messy. I started > looking at using the dt dependencies sort and iterate over the entries > in a way that adheres to their dependencies, but that's also a lot of > code. This is why I don't like trying to open code in subsystems, it's too much work. > So I think you're right, we should be able to alter the supply lookup > code to defer the EPROBE_DEFER until we actually need the supply to be > there; e.g. attempt to map supplies when an external consumer request > the regulator. > Some care needs to be taken with regards to e.g. always-on regulators. I'm not sure why always on regulators would need special casing here? Enabling is orthogonal to supply mapping. Like I said in reply to Stephen's mail I'm more worried about discoverability of problems with this approach and with interactions with dependencies on other subsystems (mainly GPIOs). Thinking about it some more the other subsystems will probably sort themselves out but the diagnosics are an issue. I do like the idea of a general mechanism for registering dependency resources and deferring completion until they're ready more - I'm not sure it's even that much more work, especially if the first cut only handles regulators as a dependency... that feels like attacking the right problem, there's other things people are raising with deferred probe like your complaint about logging. signature.asc Description: Digital signature
Re: [PATCH 0/2] make automatic device_id generation possible
Hello, On (03/05/15 09:20), Minchan Kim wrote: > I'm not against but I want to know why we should support > user-defined device id. What usecase do you have in mind? > hm, you never know what people can come up with. that's probably the strongest support argument I can provide. I wish there was something like - my friend Mike has a "device /dev/zram1 is always swap device, device /dev/zram$(id -u) is a per-user zram device (he finds it useful, because just looking at device id he can easily tell who owns that device)" policy. but nothing like that. I just think that it can be useful. no real use cases (well, partly because we don't support device add/remove). /* yet "/dev/zram$(id -u)" thing looks interesting */ user defined id support comes at a price of ~10 lines of code, or even less. we waste much more code to show ->stats, and not all of them are of any real use, to be fair. that just said, that dropping user defined id is not a great deal. ok, let's see if we can come up with anything by the end of this day and I'll send out a removal patch if nothing pop up. -ss > Could we support automatic id support only at this moment? > Then, if some user complains about that in future, we could turn > on user-defined device id easily and we could know the usecase. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/8] zram: use idr instead of `zram_devices' array
On Wed, Mar 04, 2015 at 04:49:13PM +0900, Sergey Senozhatsky wrote:
> On (03/04/15 16:06), Minchan Kim wrote:
> > So are you claiming using of idr is smaller memory footprint than zram
> > included
> > list_head?
> > I hope why you want to use idr for dynamic device management.
> >
>
> and idr handles auto device_id generation for us, all we need to do in zram
> code
> is to pass '0, 0' to idr_alloc(), instead of 'device_id, device_id + 1'.
> hoping that automatic id generation will be there one day.
About memory footprint, sizeof(list_head) might be win if we create zram
dyamically
and there is few zram device in the system because IDR uses own metadata and
bitmap
and so. But I don't think it's not too much if there is few device, either.
However, automatic id generation appeals more rather than memory footprint so I
hope
you add it in description for someone to know why we decided idr in future.
Thanks.
>
> -ss
>
> > > still provides ability to match the device_id with the device pointer.
> > > No user-space visible changes.
> > >
> > > Signed-off-by: Sergey Senozhatsky
> > > ---
> > > drivers/block/zram/zram_drv.c | 81
> > > ---
> > > 1 file changed, 46 insertions(+), 35 deletions(-)
> > >
> > > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
> > > index 8fc2566..6707b7b 100644
> > > --- a/drivers/block/zram/zram_drv.c
> > > +++ b/drivers/block/zram/zram_drv.c
> > > @@ -32,12 +32,12 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include "zram_drv.h"
> > >
> > > -/* Globals */
> > > +static DEFINE_IDR(zram_index_idr);
> > > static int zram_major;
> > > -static struct zram *zram_devices;
> > > static const char *default_compressor = "lzo";
> > >
> > > /* Module params (documentation at end) */
> > > @@ -1061,18 +1061,28 @@ static struct attribute_group
> > > zram_disk_attr_group = {
> > > .attrs = zram_disk_attrs,
> > > };
> > >
> > > -static int create_device(struct zram *zram, int device_id)
> > > +static int zram_add(int device_id)
> > > {
> > > + struct zram *zram;
> > > struct request_queue *queue;
> > > int ret = -ENOMEM;
> > >
> > > + zram = kzalloc(sizeof(struct zram), GFP_KERNEL);
> > > + if (!zram)
> > > + return ret;
> > > +
> > > + ret = idr_alloc(&zram_index_idr, zram, device_id,
> > > + device_id + 1, GFP_KERNEL);
> > > + if (ret < 0)
> > > + goto out_free_dev;
> > > +
> > > init_rwsem(&zram->init_lock);
> > >
> > > queue = blk_alloc_queue(GFP_KERNEL);
> > > if (!queue) {
> > > pr_err("Error allocating disk queue for device %d\n",
> > > device_id);
> > > - goto out;
> > > + goto out_free_idr;
> > > }
> > >
> > > blk_queue_make_request(queue, zram_make_request);
> > > @@ -1141,34 +1151,42 @@ out_free_disk:
> > > put_disk(zram->disk);
> > > out_free_queue:
> > > blk_cleanup_queue(queue);
> > > -out:
> > > +out_free_idr:
> > > + idr_remove(&zram_index_idr, device_id);
> > > +out_free_dev:
> > > + kfree(zram);
> > > return ret;
> > > }
> > >
> > > -static void destroy_devices(unsigned int nr)
> > > +static void zram_remove(struct zram *zram)
> > > {
> > > - struct zram *zram;
> > > - unsigned int i;
> > > -
> > > - for (i = 0; i < nr; i++) {
> > > - zram = &zram_devices[i];
> > > - /*
> > > - * Remove sysfs first, so no one will perform a disksize
> > > - * store while we destroy the devices
> > > - */
> > > - sysfs_remove_group(&disk_to_dev(zram->disk)->kobj,
> > > - &zram_disk_attr_group);
> > > + /*
> > > + * Remove sysfs first, so no one will perform a disksize
> > > + * store while we destroy the devices
> > > + */
> > > + sysfs_remove_group(&disk_to_dev(zram->disk)->kobj,
> > > + &zram_disk_attr_group);
> > >
> > > - zram_reset_device(zram);
> > > + zram_reset_device(zram);
> > > + idr_remove(&zram_index_idr, zram->disk->first_minor);
> > > + blk_cleanup_queue(zram->disk->queue);
> > > + del_gendisk(zram->disk);
> > > + put_disk(zram->disk);
> > > + kfree(zram);
> > > +}
> > >
> > > - blk_cleanup_queue(zram->disk->queue);
> > > - del_gendisk(zram->disk);
> > > - put_disk(zram->disk);
> > > - }
> > > +static int zram_exit_cb(int id, void *ptr, void *data)
> > > +{
> > > + zram_remove(ptr);
> > > + return 0;
> > > +}
> > >
> > > - kfree(zram_devices);
> > > +static void destroy_devices(void)
> > > +{
> > > + idr_for_each(&zram_index_idr, &zram_exit_cb, NULL);
> > > + idr_destroy(&zram_index_idr);
> > > unregister_blkdev(zram_major, "zram");
> > > - pr_info("Destroyed %u device(s)\n", nr);
> > > + pr_info("Destroyed device(s)\n");
> > > }
> > >
> > > static int __init zram_init(void)
> > > @@ -1187,16 +1205,9 @@ static int __init zram_init(void)
> > > return -EBUSY;
> > > }
> > >
> > > - /* Alloc
mmotm 2015-03-04-16-59 uploaded
The mm-of-the-moment snapshot 2015-03-04-16-59 has been uploaded to http://www.ozlabs.org/~akpm/mmotm/ mmotm-readme.txt says README for mm-of-the-moment: http://www.ozlabs.org/~akpm/mmotm/ This is a snapshot of my -mm patch queue. Uploaded at random hopefully more than once a week. You will need quilt to apply these patches to the latest Linus release (3.x or 3.x-rcY). The series file is in broken-out.tar.gz and is duplicated in http://ozlabs.org/~akpm/mmotm/series The file broken-out.tar.gz contains two datestamp files: .DATE and .DATE--mm-dd-hh-mm-ss. Both contain the string -mm-dd-hh-mm-ss, followed by the base kernel version against which this patch series is to be applied. This tree is partially included in linux-next. To see which patches are included in linux-next, consult the `series' file. Only the patches within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in linux-next. A git tree which contains the memory management portion of this tree is maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git by Michal Hocko. It contains the patches which are between the "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series file, http://www.ozlabs.org/~akpm/mmotm/series. A full copy of the full kernel tree with the linux-next and mmotm patches already applied is available through git within an hour of the mmotm release. Individual mmotm releases are tagged. The master branch always points to the latest release, so it's constantly rebasing. http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary To develop on top of mmotm git: $ git remote add mmotm git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git $ git remote update mmotm $ git checkout -b topic mmotm/master $ git send-email mmotm/master.. [...] To rebase a branch with older patches to a new mmotm release: $ git remote update mmotm $ git rebase --onto mmotm/master topic The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second) contains daily snapshots of the -mm tree. It is updated more frequently than mmotm, and is untested. A git copy of this tree is available at http://git.cmpxchg.org/?p=linux-mmots.git;a=summary and use of this tree is similar to http://git.cmpxchg.org/?p=linux-mmotm.git, described above. This mmotm tree contains the following patches against 4.0-rc2: (patches marked "*" will be included in linux-next) origin.patch arch-alpha-kernel-systblss-remove-debug-check.patch i-need-old-gcc.patch * ocfs2-make-append_dio-an-incompat-feature.patch * drivers-rtc-rtc-s3cc-add-needs_src_clk-to-s3c6410-rtc-data.patch * mm-oom-do-not-fail-__gfp_nofail-allocation-if-oom-killer-is-disbaled.patch * mm-hugetlb-close-race-when-setting-pagetail-for-gigantic-pages.patch * mm-cma-fix-cma-aligned-offset-calculation.patch * nilfs2-fix-deadlock-of-segment-constructor-during-recovery.patch * c6x-asm-pgtable-define-dummy-pgprot_writecombine-for-mmu.patch * mm-nommu-export-symbol-max_mapnr.patch * fanotify-fix-event-filtering-with-fan_ondir-set.patch * kasan-module-vmalloc-rework-shadow-allocation-for-modules.patch * kasan-module-move-module_align-macro-into-linux-moduleloaderh.patch * console-fix-console-name-size-mismatch.patch * mm-reorder-can_do_mlock-to-fix-audit-denial.patch * memcg-disable-hierarchy-support-if-bound-to-the-legacy-cgroup-hierarchy.patch * mm-fix-anon_vma-degree-underflow-in-anon_vma-endless-growing-prevention.patch * mm-fix-anon_vma-degree-underflow-in-anon_vma-endless-growing-prevention-v2.patch * ptrace-x86-fix-the-tif_forced_tf-logic-in-handle_signal.patch * cxgb4-drop-__gfp_nofail-allocation.patch * cxgb4-drop-__gfp_nofail-allocation-fix.patch * fs-ext4-fsyncc-generic_file_fsync-call-based-on-barrier-flag.patch * jbd2-revert-must-not-fail-allocation-loops-back-to-gfp_nofail.patch * ocfs2-deletion-of-unnecessary-checks-before-three-function-calls.patch * ocfs2-less-function-calls-in-ocfs2_convert_inline_data_to_extents-after-error-detection.patch * ocfs2-less-function-calls-in-ocfs2_figure_merge_contig_type-after-error-detection.patch * ocfs2-one-function-call-less-in-ocfs2_merge_rec_left-after-error-detection.patch * ocfs2-one-function-call-less-in-ocfs2_merge_rec_right-after-error-detection.patch * ocfs2-one-function-call-less-in-ocfs2_init_slot_info-after-error-detection.patch * ocfs2-one-function-call-less-in-user_cluster_connect-after-error-detection.patch * ocfs2-avoid-a-pointless-delay-in-o2cb_cluster_check.patch * ocfs2-fix-a-typing-error-in-ocfs2_direct_io_write.patch * ocfs2-no-need-get-dinode-bh-when-zeroing-extend.patch * ocfs2-take-inode-lock-when-get-clusters.patch * ocfs2-do-not-use-ocfs2_zero_extend-during-direct-io.patch * add-errors=continue.patch * acknowledge-return-value-of-ocfs2_error.patch * clear-the-rest-of-the-buffers-on-error.patch * ocfs2-fix-a-tiny-case-that-inode-can-not-removed.patch * ocfs2-use-64bit-variables-to-track-heartbeat-time.patch * ocfs2-call-ocfs
Re: [PATCH][ASoC]fsl_ssi: fix of_property_read_u32_array return value check
On Wed, Mar 04, 2015 at 10:48:30PM +0100, Maciej S. Szmigiero wrote: > of_property_read_u32_array returns 0 on success, > so the return value shouldn't be inverted twice, > first on assignment then in condition expression. > > Signed-off-by: Maciej Szmigiero Applied, thanks. signature.asc Description: Digital signature
Re: [patch -rt 1/2] KVM: use simple waitqueue for vcpu->wq
On Thu, Feb 26, 2015 at 09:23:57PM -0300, Marcelo Tosatti wrote: > On Tue, Feb 17, 2015 at 06:44:19PM +0100, Sebastian Andrzej Siewior wrote: > > * Peter Zijlstra | 2015-01-21 16:07:16 [+0100]: > > > > >On Tue, Jan 20, 2015 at 01:16:13PM -0500, Steven Rostedt wrote: > > >> I'm actually wondering if we should just nuke the _interruptible() > > >> version of swait. As it should only be all interruptible or all not > > >> interruptible, that the swait_wake() should just do the wake up > > >> regardless. In which case, swait_wake() is good enough. No need to have > > >> different versions where people may think do something special. > > >> > > >> Peter? > > > > > >Yeah, I think the lastest thing I have sitting here on my disk only has > > >the swake_up() which does TASK_NORMAL, no choice there. > > > > what is the swait status in terms of mainline? This sounds like it > > beeing worked on. > > I could take the series but then I would drop it again if the mainline > > implementation changes… > > Hi Sebastian, > > No, you would just adjust it to the upstream kernel interfaces, as the rest of > the -rt users of the swait interfaces. > > Can you please include the series? > > Thanks Sebastian? -- 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/2] make automatic device_id generation possible
On Thu, Mar 05, 2015 at 09:58:29AM +0900, Sergey Senozhatsky wrote: > Hello, > > On (03/05/15 09:20), Minchan Kim wrote: > > I'm not against but I want to know why we should support > > user-defined device id. What usecase do you have in mind? > > > > hm, you never know what people can come up with. that's probably the > strongest support argument I can provide. I wish there was something > like - my friend Mike has a "device /dev/zram1 is always swap device, > device /dev/zram$(id -u) is a per-user zram device (he finds it useful, > because just looking at device id he can easily tell who owns that > device)" policy. but nothing like that. I just think that it can be > useful. no real use cases (well, partly because we don't support device > add/remove). > > /* yet "/dev/zram$(id -u)" thing looks interesting */ Fair enough. > > > user defined id support comes at a price of ~10 lines of code, or even > less. we waste much more code to show ->stats, and not all of them are > of any real use, to be fair. that just said, that dropping user defined > id is not a great deal. ok, let's see if we can come up with anything by > the end of this day and I'll send out a removal patch if nothing pop up. As I told you, I'm never against. I just want to know usecase. If we don't support it from the beginnig, someday, someone will complain and we can catch up the usecase and support it easily with adding 10 line code. This dyanmic add/revmove feature proves the idea. :) Main reason I finally decided dynamic device management feature was someone complained he should do rmmod/insmod zram.ko to increase the number of zram device in runtime but one of zram device was used for swap, which was hard to swapoff due to small memory so there was no way to increase the number of zram device. It appeals a lot to support dynamic zram creating and finally I catch up the usecase. ;-) > > -ss > > > Could we support automatic id support only at this moment? > > Then, if some user complains about that in future, we could turn > > on user-defined device id easily and we could know the usecase. > -- Kind regards, Minchan Kim -- 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] Remove redhat'ism from ftrace selftests.
On Wed, 2015-03-04 at 21:44 +0900, Namhyung Kim wrote: > > I think that there's no need to even call true or echo.. > > From 0549544e8e982df6478f11e2b4fe419f94c22434 Mon Sep 17 00:00:00 2001 > From: Namhyung Kim > Date: Wed, 4 Mar 2015 21:26:38 +0900 > Subject: [PATCH] ftracetest: Do not use usleep > > The usleep is only provided on distros from Redhat so running ftracetest > on other distro resulted in failures due to the missing usleep. > > The reason of using [u]sleep in the test was to generate (scheduler) > events. But as we use 'cat trace | grep | wc -l' to read the events, > the command themselves already generate some events before reading the > trace file so no need to call [u]sleep explicitly. > > Reported-by: Michael Ellerman > Reported-by: Dave Jones > Signed-off-by: Namhyung Kim Thanks, this is working for me. Tested-by: Michael Ellerman $ cat /etc/issue Ubuntu 14.10 \n \l $ git log -2 --pretty=oneline 385a914624fc9fb6d0ccc3d2fd3a12ebd1ece7dd ftracetest: Do not use usleep a6c5170d1edea97c538c81e377e56c7b5c5b7e63 Merge branch 'for-4.0' of git://linux-nfs.org/~bfields/linux $ sudo ./ftracetest === Ftrace unit tests === [1] Basic trace file check [PASS] [2] Basic test for tracers [PASS] [3] Basic trace clock test [PASS] [4] Basic event tracing check [PASS] [5] event tracing - enable/disable with event level files [PASS] [6] event tracing - enable/disable with subsystem level files [PASS] [7] event tracing - enable/disable with top level files [PASS] [8] ftrace - function graph filters with stack tracer [PASS] [9] ftrace - function graph filters [PASS] [10] ftrace - function profiler with function tracing [PASS] [11] Kprobe dynamic event - adding and removing [PASS] [12] Kprobe dynamic event - busy event check[PASS] [13] Kprobe dynamic event with arguments[PASS] [14] Kprobe dynamic event with function tracer [PASS] [15] Kretprobe dynamic event with arguments [PASS] # of passed: 15 # of failed: 0 # of unresolved: 0 # of untested: 0 # of unsupported: 0 # of xfailed: 0 # of undefined(test bug): 0 cheers -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] make automatic device_id generation possible
On (03/05/15 09:58), Sergey Senozhatsky wrote: > /* yet "/dev/zram$(id -u)" thing looks interesting */ > hm, I can think of a huge build server with tons of users. /dev/zram$(id -u) created during user login and destroyed during logout. so users use theirs own zram devices with predictable device ids (which also makes it simpler for admin) for compilation/etc., and don't pressure hdds that much. -ss -- 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] x86: mce: kexec: switch MCE handler for kexec/kdump
On Wed, Mar 04, 2015 at 11:12:33PM +, Luck, Tony wrote:
> > - fixed AR and UC order in enum severity_level because UC is severer than AR
> > by definition. Current code is not affected by this wrong order by chance.
>
> AR and AO are both UC errors - that happen also to be recoverable.
Maybe just saying "UC" might be confusing, meaning "UC bit is set" or "type of
error (defined in Table SDM's Table 15-6 in vol.3B) is 'Uncorrected Error'
(clearly separate from SRAR/SRAO)". You seem to mean the former, and I meant
the latter. So I should write the description more accurately like "UC=1,PCC=0"
error and "UC=1,PCC=1" error.
> Are you really sure
> about this re-order not affecting existing code?
Sorry, I thought I checked that but I missed one, so let me check again now.
I checked all referencing site of MCE_*_SEVERITY. Most of them are using '=='
to compare the severity, where the re-order doesn't affect them.
Some are using inequalities:
- around ./arch/x86/kernel/cpu/mcheck/mce.c:720,
if (mce_severity(m, mca_cfg.tolerant, msg, true) >=
MCE_PANIC_SEVERITY)
, the re-order doesn't affect.
- ./arch/x86/kernel/cpu/mcheck/mce.c:819:
if (m && global_worst >= MCE_PANIC_SEVERITY && mca_cfg.tolerant < 3)
, the re-order doesn't affect.
- ./arch/x86/kernel/cpu/mcheck/mce.c:832:
if (global_worst <= MCE_KEEP_SEVERITY && mca_cfg.tolerant < 3)
, ditto.
- ./arch/x86/kernel/cpu/mcheck/mce.c:1196:
no_way_out = worst >= MCE_PANIC_SEVERITY;
, ditto.
- ./arch/x86/kernel/cpu/mcheck/mce-severity.c:211:
if (s->sev >= MCE_UC_SEVERITY && ctx == IN_KERNEL) {
, the re-order should change to s->sev >= MCE_AR_SEVERITY to keep the
kernel behavior.
So I fixed the last part to be included in the re-order patch.
> You might well be right, but as every one
> else has pointed out mce_severity() is full of odd subtleties that catch
> people out.
I agree that this one big table is hard to maintain and bug-prone. One problem
is that it has too many fields to check so the parameter space is huge. I think
some field are checked only once, so separating it out makes table more simple
and readable.
> Is the "UC" entry at the end of the severities[] table just a catch-all for
> things that made it
> past all the other entries? Does it ever really get used?
I read through the severity check table and it seems that all UC=1 case
are already considered by the above entries, so it seems not used.
> What was the test case that made you promote UC above AR?
I thought of "Action required but unaffected thread is continuable" case
on kexec kernel, but I'm not sure that such a case really happens.
My motivation on the promotion was mainly from what SDM says rather than
the real testcase.
> This absolutely should not be buried in the middle of your other patch - it
> needs to
> be separate with a much more than two lines of commit description.
OK, I might not include this part in this series in later post, but if I do,
I'll separete it out.
Thanks,
Naoya Horiguchi--
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 v1 0/4] x86: simpify direct_gbpages setting, add early_param_on_off()
From: "Luis R. Rodriguez" While reviewing DIRECT_GBPAGES I noticed some inconsistancies on when its cached "enable" variable is set and when in reality its full feature is enabled. There's also some code simplification possible by simply using Kconfig, so decided to take advantage of that and then generalize this a bit under a new early_param_on_off() which makes it easier to associate featureas with respective cached values and their own feature related Kconfig entries. In this case in order to use early_param_on_off() given that init.o is shared with both 32-bit and 64-bit and before the early parameters were only exposed on 64-bit it does mean we're exposing this kernel parameter to 32-bit as well now but its not possible to enable it on 32-bit as its real setting is guarded by ENABLE_DIRECT_GBPAGES. I was tempted to grep around for this sort of grammar use but couldn't easily find all uses with Coccinelle / grep due to the #ifder'y and the code being outside of routines. If the generalization is not desired we can drop the last two, but would ask that the first two patches to be considered and reviewed. Luis R. Rodriguez (4): x86: mm: use IS_ENABLED() for direct_gbpages x86: mm: simplify enabling direct_gbpages init.h: add early_param_on_off() x86: mm: use early_param_on_off() for direct_gbpages arch/x86/Kconfig | 18 +- arch/x86/mm/init.c | 24 +++- arch/x86/mm/init_64.c | 14 -- arch/x86/mm/pageattr.c | 2 -- include/linux/init.h | 15 +++ 5 files changed, 39 insertions(+), 34 deletions(-) -- 2.2.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC v1 1/4] x86: mm: use IS_ENABLED() for direct_gbpages
From: "Luis R. Rodriguez"
Replace #ifdef eyesore with IS_ENABLED() use.
Cc: Greg Kroah-Hartman
Cc: Tony Lindgren
Cc: linux-kernel@vger.kernel.org
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: x...@kernel.org
Cc: Juergen Gross
Cc: Andy Lutomirski
Cc: Toshi Kani
Cc: Dave Hansen
Cc: Jan Beulich
Cc: Pavel Machek
Cc: Xishi Qiu
Cc: Andrew Morton
Cc: David Vrabel
Cc: Borislav Petkov
Cc: Vlastimil Babka
Cc: Joonsoo Kim
Cc: Dexuan Cui
Signed-off-by: Luis R. Rodriguez
---
arch/x86/mm/init.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 52417e7..b880d06 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -131,11 +131,7 @@ void __init early_alloc_pgt_buf(void)
int after_bootmem;
-int direct_gbpages
-#ifdef CONFIG_DIRECT_GBPAGES
- = 1
-#endif
-;
+int direct_gbpages = IS_ENABLED(CONFIG_DIRECT_GBPAGES);
static void __init init_gbpages(void)
{
--
2.2.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
