Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB based AXP223 PMIC
On Fri, Oct 16, 2015 at 2:41 PM, Maxime Ripard
wrote:
> On Thu, Oct 15, 2015 at 12:32:19AM +0800, Chen-Yu Tsai wrote:
>> The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
>> It is functionally identical to AXP221; only the regulator default
>> voltage/status and the external host interface are different.
>>
>> Signed-off-by: Chen-Yu Tsai
>> ---
>> drivers/mfd/Kconfig| 12 ++
>> drivers/mfd/Makefile | 1 +
>> drivers/mfd/axp20x-core.c | 2 +
>> drivers/mfd/axp20x-rsb.c | 93
>> ++
>> include/linux/mfd/axp20x.h | 1 +
>> 5 files changed, 109 insertions(+)
>> create mode 100644 drivers/mfd/axp20x-rsb.c
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 9ba3feb3f2fc..6e5edb61d42e 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -84,6 +84,7 @@ config MFD_BCM590XX
>> config MFD_AXP20X
>> bool "X-Powers AXP series PMICs"
>> select MFD_AXP20X_I2C
>> + select MFD_AXP20X_RSB
>>
>> config MFD_AXP20X_CORE
>> bool
>> @@ -102,6 +103,17 @@ config MFD_AXP20X_I2C
>> components like regulators or the PEK (Power Enable Key) under the
>> corresponding menus.
>>
>> +config MFD_AXP20X_RSB
>> + bool "X-Powers AXP series RSB PMICs"
>> + select MFD_AXP20X_CORE
>> + depends on SUNXI_RSB=y
>
> Do we need that? Even if the bus is compiled as a module, the driver
> will not be probed before that, will it?
There's a compile/link dependency on the __devm_regmap_init_sunxi_rsb().
And both drivers are bool, i.e. can't be compiled as a module. What we
don't want is enabling MFD_AXP20X_RSB without SUNXI_RSB.
AFAIK the same goes for the I2C version.
>> + help
>> + If you say Y here you get support for the X-Powers AXP series RSB
>> + based power management ICs (PMICs).
>> + This driver include only the core APIs. You have to select individual
>> + components like regulators or the PEK (Power Enable Key) under the
>> + corresponding menus.
>> +
>> config MFD_CROS_EC
>> tristate "ChromeOS Embedded Controller"
>> select MFD_CORE
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index ce3ad5fd4e2f..1eb278619dd6 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -108,6 +108,7 @@ obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
>> obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
>> obj-$(CONFIG_MFD_AXP20X_CORE)+= axp20x-core.o
>> obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
>> +obj-$(CONFIG_MFD_AXP20X_RSB) += axp20x-rsb.o
>>
>> obj-$(CONFIG_MFD_LP3943) += lp3943.o
>> obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
>> diff --git a/drivers/mfd/axp20x-core.c b/drivers/mfd/axp20x-core.c
>> index dd33548d93c4..baecccb6d400 100644
>> --- a/drivers/mfd/axp20x-core.c
>> +++ b/drivers/mfd/axp20x-core.c
>> @@ -32,6 +32,7 @@ static const char * const axp20x_model_names[] = {
>> "AXP202",
>> "AXP209",
>> "AXP221",
>> + "AXP223",
>> "AXP288",
>> };
>>
>> @@ -575,6 +576,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x,
>> struct device *dev)
>> axp20x->regmap_irq_chip = &axp20x_regmap_irq_chip;
>> break;
>> case AXP221_ID:
>> + case AXP223_ID:
>> axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
>> axp20x->cells = axp22x_cells;
>> axp20x->regmap_cfg = &axp22x_regmap_config;
>> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
>> new file mode 100644
>> index ..5d053d177717
>> --- /dev/null
>> +++ b/drivers/mfd/axp20x-rsb.c
>> @@ -0,0 +1,93 @@
>> +/*
>> + * axp20x-rsb.c - RSB driver for the X-Powers' Power Management ICs
>> + *
>> + * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK
>> DC-DC
>> + * converters, LDOs, multiple 12-bit ADCs of voltage, current and
>> temperature
>> + * as well as configurable GPIOs.
>> + *
>> + * This driver supports the RSB variants.
>> + *
>> + * Author: Chen-Yu Tsai
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static const struct of_device_id axp20x_sunxi_rsb_of_match[] = {
>> + { .compatible = "x-powers,axp223", .data = (void *) AXP223_ID },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, axp20x_sunxi_rsb_of_match);
>> +
>> +static int axp20x_sunxi_rsb_match_device(struct axp20x_dev *axp20x,
>> + struct device *dev)
>> +{
>> + const struct of_device_id *of_id;
>> +
>> + of_id = of_match_device(axp20x_sunxi_rsb_of_match, dev);
>> + if (!of_id) {
>> + dev_err(dev, "Unable to match OF ID\n");
>> + return -ENODEV;
>> +
RE: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller
Hi Brian, > -Original Message- > From: Brian Norris [mailto:computersforpe...@gmail.com] > Sent: 13 October 2015 02:58 > To: Anup Patel > Cc: Florian Fainelli; Scott Branden; linux-arm-ker...@lists.infradead.org; Rob > Herring; Pawel Moll; Mark Rutland; Ian Campbell; Kumar Gala; Catalin Marinas; > Will Deacon; David Woodhouse; Ray Jui; Pramod Kumar; Vikram Prakash; > Sandeep Tripathy; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org; > linux-...@lists.infradead.org; bcm-kernel-feedback-list; Rafal Milecki > Subject: Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND > controller > > Hi Anup, > > On Wed, Oct 07, 2015 at 03:33:50AM +, Anup Patel wrote: > > > -Original Message- > > > From: Florian Fainelli [mailto:f.faine...@gmail.com] > > > > > > On 06/10/15 15:25, Scott Branden wrote: > > > > > > Then instead of adding a "reset flag" to Device Tree, another > > > approach could be to put the desired or currently configured > > > exhaustive list of NAND timings in Device Tree, and based on that you > > > could > have this: > > > > > > - the NAND controller driver finds that these timings match the > > > current configuration, you are good to go > > > > > > - the NAND controller drivers finds a difference in how current > > > timings are configured vs. desired timings, and issues a controller > > > reset, prior to applying new timing configuration > > > > To add to this ... > > > > The mechanism to reset is BRCM NAND controller is SOC specific so the > > SoC independent BRCM NAND driver (i.e. brcmnand.c) does not know how > > to reset the NAND controller. > > > > For iProc SoC family, the NAND controller reset is through IDM > > register space which is only iomap'ed by iproc_nand.c. > > > > We might end-up having one more SoC specific callback which will be > > Provided by iproc_nand.c to brcmnand.c. > > > > > > > > - no timings are configured, reset the controller and use existing > > > auto-detection capabilities like ONFI modes > > > > > > Typically you would put the desired timings instead of the currently > > > configured timings though.. > > > > Overall, it would good to support timing parameters through DT or ONFI > > but for now have we can rely on reset and auto-devid configuration. > > I don't want to support a DT property that is only used as a workaround for > the > right solution. That means the property may quickly become obsolete, yet we > have to support it forever. > > > > > >> compatible = "brcm,iproc-nand-ns2", ...; > > > >> > > > > As described above - the option is not SoC specific. It is system > > > > specific. In some systems we may wish to reset the NAND > > > > controller in linux. In some we may wish to rely on > > > > initialization that has already been done to speed up boot times. > > > > > > It seems to me like having this property is fine as long as you are > > > describing that the controller *needs* a reset to operate properly, > > > it does not strike me as a particularly well suited property if its > > > side effect and main usage is to keep or wipe-out existing NAND timings. > > > > IMHO, having SoC specific compatible string for NS2 is like saying > > NAND controller on NS2 is different from other iProc SoCs whereas > > Having optional DT flags for quirks/work-arounds (e.g. NAND controller > > reset) is like saying NAND controller on NS2 same as other iProc SoCs > > but some additional programming is required. > > OK... so what is the reason that you have to reset the controller on NS2 and > not > Cygnus? Is it a SoC difference (i.e., compatible string)? > Firmware/bootloader difference? So far, all statements have been non-specific, > AFAICT. > On NS2 SVK, we have 16bit NAND chip whereas on all Cygnus SVKs we mostly have 8bit NAND chip. The bootloader on NS2 touches NAND controller and configures it to 16bit mode. When we reach BRCMNAND driver probing on NS2, the BRCMNAND controller is already in 16bit mode so NAND READID command does not work. On Cygnus, we mostly have 8bit NAND chip so BRCMNAND controller is always in 8bit mode so we don't see any issue with NAND READID command. We really don't require to reset BRCNNAND controller on NS2 to get NAND READID command working. Instead, we can simply force 8bit mode before we do nand_scan_ident() for each CS. This will be a much simpler fix for all versions of BRCMNAND because NAND READID command will only work in 8bit mode irrespective to BRCMNAND version (NAND controllers from other vendors might also have similar issue with NAND READID command). I will send a revised patchset which will fix brcmnand_init_cs() as-per above. Best Regards, Anup -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ARM: dts: sun8i: Add NMI interrupt controller node
On Thu, Oct 15, 2015 at 12:32:21AM +0800, Chen-Yu Tsai wrote: > The NMI interrupt controller is in charge of the NMI pin exposed by > the SoC to the PMIC. The PMIC signals interrupts through this. > > Signed-off-by: Chen-Yu Tsai Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH 3/3] ARM: at91/defconfig: update sama5 defconfig
On Thu, Oct 15, 2015 at 05:42:53PM +0200, Nicolas Ferre wrote: > Le 15/10/2015 17:31, Ludovic Desroches a écrit : > > On Thu, Oct 15, 2015 at 03:24:51PM +0200, Alexandre Belloni wrote: > >> Hi, > >> > >> On 14/10/2015 at 14:11:24 +0200, Ludovic Desroches wrote : > >>> Add SAMA5D2 SoC plus Atmel flexcom and Atmel sdhci devices. > >>> > >>> Signed-off-by: Ludovic Desroches > >>> --- > >>> arch/arm/configs/sama5_defconfig | 6 +- > >>> 1 file changed, 5 insertions(+), 1 deletion(-) > >>> > >> It is probably worth updating the multi_v7_defconfig too (in a separate > >> patch). > >> > > > > Maybe I have to send a whole defconfig update . I mean when you do > > savedefconfig, you have more changes. I won't send each one separately. I > > have kept changes which were in relation with the stuff I had. > > > > Or I can send a defconfig update from the savedefconfig and then add > > sama5d2, flexcom and sdhci. > > Actually you can do this for our own AT91 defconfigs. > > For the multi_v7_defconfig I would recommend to simply make a patch with > our updates and let the arm-soc maintainer merge it with their current > one: I mean, they will manage the conflicts on this file anyway and the > changes to this file will not be part of one or our pull-requests but a > patch that they will handle separately: so no need to add more update > than the strictly needed ones on our end. > In fact, I realize that I have read too quickly Alexandre's answer. I have understood that I should put CONFIG_SOC_SAM_V7=y in a separate patch. So yes I would do a whole update for our defconfigs and only the addition needed for the multi_v7 one Ludovic -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/6] mfd: axp20x: Add support for RSB based AXP223 PMIC
On Thu, Oct 15, 2015 at 12:32:19AM +0800, Chen-Yu Tsai wrote:
> The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
> It is functionally identical to AXP221; only the regulator default
> voltage/status and the external host interface are different.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> drivers/mfd/Kconfig| 12 ++
> drivers/mfd/Makefile | 1 +
> drivers/mfd/axp20x-core.c | 2 +
> drivers/mfd/axp20x-rsb.c | 93
> ++
> include/linux/mfd/axp20x.h | 1 +
> 5 files changed, 109 insertions(+)
> create mode 100644 drivers/mfd/axp20x-rsb.c
>
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 9ba3feb3f2fc..6e5edb61d42e 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -84,6 +84,7 @@ config MFD_BCM590XX
> config MFD_AXP20X
> bool "X-Powers AXP series PMICs"
> select MFD_AXP20X_I2C
> + select MFD_AXP20X_RSB
>
> config MFD_AXP20X_CORE
> bool
> @@ -102,6 +103,17 @@ config MFD_AXP20X_I2C
> components like regulators or the PEK (Power Enable Key) under the
> corresponding menus.
>
> +config MFD_AXP20X_RSB
> + bool "X-Powers AXP series RSB PMICs"
> + select MFD_AXP20X_CORE
> + depends on SUNXI_RSB=y
Do we need that? Even if the bus is compiled as a module, the driver
will not be probed before that, will it?
> + help
> + If you say Y here you get support for the X-Powers AXP series RSB
> + based power management ICs (PMICs).
> + This driver include only the core APIs. You have to select individual
> + components like regulators or the PEK (Power Enable Key) under the
> + corresponding menus.
> +
> config MFD_CROS_EC
> tristate "ChromeOS Embedded Controller"
> select MFD_CORE
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index ce3ad5fd4e2f..1eb278619dd6 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -108,6 +108,7 @@ obj-$(CONFIG_MFD_DA9052_SPI) += da9052-spi.o
> obj-$(CONFIG_MFD_DA9052_I2C) += da9052-i2c.o
> obj-$(CONFIG_MFD_AXP20X_CORE)+= axp20x-core.o
> obj-$(CONFIG_MFD_AXP20X_I2C) += axp20x-i2c.o
> +obj-$(CONFIG_MFD_AXP20X_RSB) += axp20x-rsb.o
>
> obj-$(CONFIG_MFD_LP3943) += lp3943.o
> obj-$(CONFIG_MFD_LP8788) += lp8788.o lp8788-irq.o
> diff --git a/drivers/mfd/axp20x-core.c b/drivers/mfd/axp20x-core.c
> index dd33548d93c4..baecccb6d400 100644
> --- a/drivers/mfd/axp20x-core.c
> +++ b/drivers/mfd/axp20x-core.c
> @@ -32,6 +32,7 @@ static const char * const axp20x_model_names[] = {
> "AXP202",
> "AXP209",
> "AXP221",
> + "AXP223",
> "AXP288",
> };
>
> @@ -575,6 +576,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x, struct
> device *dev)
> axp20x->regmap_irq_chip = &axp20x_regmap_irq_chip;
> break;
> case AXP221_ID:
> + case AXP223_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
> axp20x->cells = axp22x_cells;
> axp20x->regmap_cfg = &axp22x_regmap_config;
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> new file mode 100644
> index ..5d053d177717
> --- /dev/null
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -0,0 +1,93 @@
> +/*
> + * axp20x-rsb.c - RSB driver for the X-Powers' Power Management ICs
> + *
> + * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK
> DC-DC
> + * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
> + * as well as configurable GPIOs.
> + *
> + * This driver supports the RSB variants.
> + *
> + * Author: Chen-Yu Tsai
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +static const struct of_device_id axp20x_sunxi_rsb_of_match[] = {
> + { .compatible = "x-powers,axp223", .data = (void *) AXP223_ID },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, axp20x_sunxi_rsb_of_match);
> +
> +static int axp20x_sunxi_rsb_match_device(struct axp20x_dev *axp20x,
> + struct device *dev)
> +{
> + const struct of_device_id *of_id;
> +
> + of_id = of_match_device(axp20x_sunxi_rsb_of_match, dev);
> + if (!of_id) {
> + dev_err(dev, "Unable to match OF ID\n");
> + return -ENODEV;
> + }
> + axp20x->variant = (long) of_id->data;
> +
> + return axp20x_match_device(axp20x, dev);
> +}
> +
> +static int axp20x_sunxi_rsb_probe(struct sunxi_rsb_device *rdev)
> +{
> + struct axp20x_dev *axp20x;
> + int ret;
> +
> + axp20x = devm_kzalloc(&rdev->dev, sizeof(*axp20x), GFP_KERNEL);
> + if (!axp20x)
> + return -ENOMEM;
> +
> + ret = axp20x_sunxi_rsb_match_device(axp20x, &rd
Re: [PATCH 4/5] pinctrl: berlin: Kconfig clean up
Sebastian, On Thu, Oct 15, 2015 at 11:46:15PM +0200, Sebastian Hesselbarth wrote: > On 13.10.2015 23:31, Antoine Tenart wrote: > >Reorder the statements under the PINCTRL_BERLIN_BG4CT config > >option to be consistent with the existing. > > > >Signed-off-by: Antoine Tenart > > If this is the only patch that requires the dependency with > Jisheng's pending patches, can you two agree on squashing it > into Jisheng's patch set? Yes, this is the only one. Squashing them would be great! Antoine -- Antoine Ténart, 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 0/4] mtd: pxa3xx_nand: rework the timing setup
Hi Ezequiel, On Thu, Oct 15, 2015 at 03:30:50PM -0300, Ezequiel Garcia wrote: > Ccing Robert as he can provide valuable test on PXA boards. Sorry for this, I tried to cc Robert but forgot when sending my series... Antoine -- Antoine Ténart, 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/
[PATCH v4] ARM: fix vdsomunge not to depend on glibc specific byteswap.h
If the host toolchain is not glibc based then the arm kernel build
fails with
HOSTCC arch/arm/vdso/vdsomunge
arch/arm/vdso/vdsomunge.c:48:22: fatal error: byteswap.h: No such file or
directory
Observed: with omap2plus_defconfig and compile on Mac OS X with arm ELF
cross-compiler.
Reason: byteswap.h is a glibc only header.
Solution: replace by private byte-swapping macros (taken from
arch/mips/boot/elf2ecoff.c and kindly improved by Russell King)
Tested to compile on Mac OS X 10.9.5 host.
Signed-off-by: H. Nikolaus Schaller
---
arch/arm/vdso/vdsomunge.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/arch/arm/vdso/vdsomunge.c b/arch/arm/vdso/vdsomunge.c
index aedec81..0cebd98 100644
--- a/arch/arm/vdso/vdsomunge.c
+++ b/arch/arm/vdso/vdsomunge.c
@@ -45,7 +45,6 @@
* it does.
*/
-#include
#include
#include
#include
@@ -59,6 +58,16 @@
#include
#include
+#define swab16(x) \
+ x) & 0x00ff) << 8) | \
+(((x) & 0xff00) >> 8))
+
+#define swab32(x) \
+ x) & 0x00ff) << 24) | \
+(((x) & 0xff00) << 8) | \
+(((x) & 0x00ff) >> 8) | \
+(((x) & 0xff00) << 24))
+
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
#define HOST_ORDER ELFDATA2LSB
#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
@@ -104,17 +113,17 @@ static void cleanup(void)
static Elf32_Word read_elf_word(Elf32_Word word, bool swap)
{
- return swap ? bswap_32(word) : word;
+ return swap ? swab32(word) : word;
}
static Elf32_Half read_elf_half(Elf32_Half half, bool swap)
{
- return swap ? bswap_16(half) : half;
+ return swap ? swab16(half) : half;
}
static void write_elf_word(Elf32_Word val, Elf32_Word *dst, bool swap)
{
- *dst = swap ? bswap_32(val) : val;
+ *dst = swap ? swab32(val) : val;
}
int main(int argc, char **argv)
--
2.5.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: [linux-sunxi] [PATCH 1/3] mtd: nand: add NAND_NEED_SCRAMBLING option flag
On Fri, 16 Oct 2015 08:28:54 +0200 Boris Brezillon wrote: > Hi Julian, > > On Fri, 16 Oct 2015 09:32:38 +1100 > Julian Calaby wrote: > > > Hi Boris, > > > > On Fri, Oct 16, 2015 at 4:17 AM, Boris Brezillon > > wrote: > > > Some MLC NANDs are sensible to repeated patterns and require data to be > > > > Do you mean "sensitive" instead of "sensible"? > > Yes (I always mix the too, sensible is the french word for two > sensitive ;-)), I'll fix that. > > Best Regards, > > Boris > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel 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 v2 1/4] wait.[ch]: Introduce the simple waitqueue (swait) implementation
On 10/16/2015 07:46 AM, kbuild test robot wrote: > Hi Peter, > > [auto build test WARNING on v4.3-rc5 -- if it's inappropriate base, please > suggest rules for selecting the more suitable base] > > url: > https://github.com/0day-ci/linux/commits/Daniel-Wagner/Simple-wait-queue-support/20151014-154944 > config: mips-nlm_xlp_defconfig (attached as .config) > reproduce: > wget > https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross > -O ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > make.cross ARCH=mips > > All warnings (new ones prefixed by >>): > >>> mips-linux-gnu-ld: kernel/sched/.tmp_swait.o: warning: Inconsistent ISA >>> between e_flags and .MIPS.abiflags I tried to do trigger this warning on my local machine using the above steps. Neither 4.9.0 nor 4.6.3 version of the cross tool gcc was showing this. To the warning itself. I have no idea what this is about. Any ideas? thanks, daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pci: restrict 64-bit pci device to assign resource from behind of max_pfn
On 2015年10月15日 19:32, kbuild test robot wrote: Hi Wenlin, [auto build test ERROR on pci/next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Wenlin-Kang/pci-restrict-64-bit-pci-device-to-assign-resource-from-behind-of-max_pfn/20151015-184913 config: mips-fuloong2e_defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=mips All errors (new ones prefixed by >>): drivers/pci/setup-res.c: In function '__pci_assign_resource': drivers/pci/setup-res.c:224:6: error: 'max_pfn' undeclared (first use in this function) (max_pfn + 1) << PAGE_SHIFT : PCIBIOS_MIN_MEM; ^ drivers/pci/setup-res.c:224:6: note: each undeclared identifier is reported only once for each function it appears in vim +/max_pfn +224 drivers/pci/setup-res.c 218 * For 64-bit pci device, assign resource start from the next page 219 * boundary above the maximum physical page address 220 */ 221 resource_size_t min_iomem; 222 223 min_iomem = (res->flags & IORESOURCE_MEM_64) ? > 224 (max_pfn + 1) << PAGE_SHIFT : PCIBIOS_MIN_MEM; 225 min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : min_iomem; 226 #else 227 min = (res->flags & IORESOURCE_IO) ? PCIBIOS_MIN_IO : PCIBIOS_MIN_MEM; --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation Hi Thanks you point out this, due to I built it on x86 previously , so don't see the error. After added "#include " in drivers/pci/setup-res.c, it will be ok. -- Thanks, Wenlin Kang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-sunxi] [PATCH 1/3] mtd: nand: add NAND_NEED_SCRAMBLING option flag
Hi Julian, On Fri, 16 Oct 2015 09:32:38 +1100 Julian Calaby wrote: > Hi Boris, > > On Fri, Oct 16, 2015 at 4:17 AM, Boris Brezillon > wrote: > > Some MLC NANDs are sensible to repeated patterns and require data to be > > Do you mean "sensitive" instead of "sensible"? Yes (I always mix the too, sensible is the french word for sensitive ;-)), I'll fix that. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel 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: [RFC PATCH 3/4] random: Only do mixback once per read
Hi George, [auto build test ERROR on v4.3-rc5 -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/George-Spelvin/Alternate-sclable-urandom-patchset/20151016-133627 config: x86_64-randconfig-x010-10130227 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=x86_64 All errors (new ones prefixed by >>): In file included from include/asm-generic/percpu.h:6:0, from arch/x86/include/asm/percpu.h:551, from arch/x86/include/asm/preempt.h:5, from include/linux/preempt.h:64, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/uapi/linux/timex.h:56, from include/linux/timex.h:56, from include/linux/sched.h:19, from include/linux/utsname.h:5, from drivers/char/random.c:238: drivers/char/random.c: In function 'extract_buf': >> include/linux/percpu-defs.h:91:33: error: section attribute cannot be >> specified for local variables extern __PCPU_DUMMY_ATTRS char __pcpu_unique_##name; \ ^ include/linux/percpu-defs.h:116:2: note: in expansion of macro 'DEFINE_PER_CPU_SECTION' DEFINE_PER_CPU_SECTION(type, name, "") ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:92:26: error: section attribute cannot be specified for local variables __PCPU_DUMMY_ATTRS char __pcpu_unique_##name; \ ^ include/linux/percpu-defs.h:116:2: note: in expansion of macro 'DEFINE_PER_CPU_SECTION' DEFINE_PER_CPU_SECTION(type, name, "") ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ >> include/linux/percpu-defs.h:92:26: error: declaration of >> '__pcpu_unique_random_nonce' with no linkage follows extern declaration __PCPU_DUMMY_ATTRS char __pcpu_unique_##name; \ ^ include/linux/percpu-defs.h:116:2: note: in expansion of macro 'DEFINE_PER_CPU_SECTION' DEFINE_PER_CPU_SECTION(type, name, "") ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:91:33: note: previous declaration of '__pcpu_unique_random_nonce' was here extern __PCPU_DUMMY_ATTRS char __pcpu_unique_##name; \ ^ include/linux/percpu-defs.h:116:2: note: in expansion of macro 'DEFINE_PER_CPU_SECTION' DEFINE_PER_CPU_SECTION(type, name, "") ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ drivers/char/random.c:1134:31: error: section attribute cannot be specified for local variables static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:93:44: note: in definition of macro 'DEFINE_PER_CPU_SECTION' extern __PCPU_ATTRS(sec) __typeof__(type) name; \ ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ drivers/char/random.c:1134:31: error: section attribute cannot be specified for local variables static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:95:19: note: in definition of macro 'DEFINE_PER_CPU_SECTION' __typeof__(type) name ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ drivers/char/random.c:1134:31: error: weak declaration of 'random_nonce' must be public static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:95:19: note: in definition of macro 'DEFINE_PER_CPU_SECTION' __typeof__(type) name ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ drivers/char/random.c:1134:31: error: declaration of 'random_nonce' with no linkage follows extern declaration static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:95:19: note: in definition of macro 'DEFINE_PER_CPU_SECTION' __typeof__(type) name ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' sta
Re: [PATCH v2] powerpc/mpc5xxx: Avoid dereferencing potentially freed memory
Le 15/10/2015 08:36, Michael Ellerman a écrit : On Thu, 2015-10-15 at 07:56 +0200, Christophe JAILLET wrote: Use 'of_property_read_u32()' instead of 'of_get_property()'+pointer dereference in order to avoid access to potentially freed memory. Use 'of_get_next_parent()' to simplify the while() loop and avoid the need of a temp variable. Signed-off-by: Christophe JAILLET --- v2: Use of_property_read_u32 instead of of_get_property+pointer dereference *** Untested *** Thanks. Can someone with an mpc5xxx test this? cheers Hi, I don't think it is an issue, but while looking at another similar patch, I noticed that the proposed patch adds a call to be32_to_cpup() (within of_property_read_u32). Apparently, powerPC is a BE architecture, so this call should be a no-op. Just wanted to point it out, in case of. Best regards, CJ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] mailbox: Hi6220: add mailbox driver
On Fri, Oct 16, 2015 at 11:42:54AM +0530, Jassi Brar wrote: > On 16 October 2015 at 11:38, Leo Yan wrote: > > On Fri, Oct 16, 2015 at 11:17:32AM +0530, Jassi Brar wrote: > >> On Fri, Oct 16, 2015 at 10:59 AM, Leo Yan wrote: > >> > On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote: > >> >> On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote: > >> >> > >> >> > + > >> >> > +#define MBOX_CHAN_MAX 32 > >> >> > +#define MBOX_CHAN_NUM 2 > >> >> > + > >> >> You mean the hardware has 32 channels but this driver can not manage > >> >> more than 2 ? > >> >> > >> >> OR, there are 32 interfaces but only 2 physical 'floating' links, so > >> >> no more than 2 interfaces can be active at any time? > >> > > >> > For the later case. > >> Former is a s/w limitation and latter is h/w limitation. From what you > >> write below, it seems former to be the case. > > > > Sorry, i misunderstood the question. It's a s/w limitation. > > > >> > Mailbox also can be used by other modules, such > >> > like audio hifi; later need add links for them if want to enable > >> > audio. But so far only uses first 2 channels. > >> > > >> You mean every time your platform needs another channel, you'll update > >> the driver? Not sure about that. It should be simpler to assign which > >> ever and as many channels as the client asks via DT. > > > > For hi6220, every channel is fixed to specific purpose; > on different platform the purposes may be different, so > > > so i can > > register all of them in driver, such like hifi related channels; > > Though i cannot test them currently, but this will avoid extra > > efforts for enabling channels anymore, do you think this is okay? > > Or you prefer to bind with DT? > > > DT please. Ok, will do this. Thansk, Leo Yan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] isdn: correctly check failed allocation
From: Insu Yun
Date: Thu, 15 Oct 2015 12:29:28 -0400
> Since skb_clone is memory allocation, it could be failed when lack of
> resource.
> Therefore, return value of skb_clone needs to be checked and handle error.
>
> Signed-off-by: Insu Yun
> ---
> drivers/isdn/mISDN/layer2.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/isdn/mISDN/layer2.c b/drivers/isdn/mISDN/layer2.c
> index 949cabb..888c610 100644
> --- a/drivers/isdn/mISDN/layer2.c
> +++ b/drivers/isdn/mISDN/layer2.c
> @@ -1509,6 +1509,12 @@ l2_pull_iqueue(struct FsmInst *fi, int event, void
> *arg)
> }
>
> nskb = skb_clone(skb, GFP_ATOMIC);
> + if (!nskb) {
> + printk(KERN_WARNING "%s: no skb mem in %s\n",
> +mISDNDevName4ch(&l2->ch), __func__);
> + return;
> + }
> +
Again you have indented this code incorrectly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] xen-netback: corretly check failed allocation
From: Insu Yun
Date: Thu, 15 Oct 2015 12:26:16 -0400
> Since vzalloc can be failed in memory pressure,
> return value should be checked and return ENOMEM.
>
> Signed-off-by: Insu Yun
> ---
> drivers/net/xen-netback/xenbus.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/net/xen-netback/xenbus.c
> b/drivers/net/xen-netback/xenbus.c
> index 929a6e7..e288246 100644
> --- a/drivers/net/xen-netback/xenbus.c
> +++ b/drivers/net/xen-netback/xenbus.c
> @@ -788,6 +788,11 @@ static void connect(struct backend_info *be)
> /* Use the number of queues requested by the frontend */
> be->vif->queues = vzalloc(requested_num_queues *
> sizeof(struct xenvif_queue));
> + if (!be->vif->queues) {
> +xenbus_dev_fatal(dev, -ENOMEM, "allocating queues");
> +return;
> + }
This is definitely not indented correctly.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mlx4: corretly check failed allocation
From: Insu Yun Date: Thu, 15 Oct 2015 12:24:09 -0400 > When allocation fails, mlx4_alloc_cmd_mailbox returns -ENOMEM. > Since there is no case that mlx4_alloc_cmd_mailbox returns NULL, > it needs to be checked by IS_ERR, not IS_ERR_OR_NULL > > Signed-off-by: Insu Yun Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] powerpc/prom: Avoid reference to potentially freed memory
of_get_property() is used inside the loop, but then the reference to the
node is dropped before dereferencing the prop pointer, which could by then
point to junk if the node has been freed.
Instead use of_property_read_u32() to actually read the property
value before dropping the reference.
Signed-off-by: Christophe JAILLET
---
*** UNTESTED ***
---
arch/powerpc/kernel/prom.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
index bef76c5..dc4f6a4 100644
--- a/arch/powerpc/kernel/prom.c
+++ b/arch/powerpc/kernel/prom.c
@@ -783,14 +783,13 @@ void __init early_get_first_memblock_info(void *params,
phys_addr_t *size)
int of_get_ibm_chip_id(struct device_node *np)
{
of_node_get(np);
- while(np) {
+ while (np) {
struct device_node *old = np;
- const __be32 *prop;
+ u32 chip_id;
- prop = of_get_property(np, "ibm,chip-id", NULL);
- if (prop) {
+ if (!of_property_read_u32(np, "ibm,chip-id", &chip_id))
of_node_put(np);
- return be32_to_cpup(prop);
+ return chip_id;
}
np = of_get_parent(np);
of_node_put(old);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 3/4] random: Only do mixback once per read
Hi George, [auto build test ERROR on v4.3-rc5 -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/George-Spelvin/Alternate-sclable-urandom-patchset/20151016-133627 config: i386-randconfig-i1-201541 (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=i386 All errors (new ones prefixed by >>): In file included from include/asm-generic/percpu.h:6:0, from arch/x86/include/asm/percpu.h:551, from arch/x86/include/asm/preempt.h:5, from include/linux/preempt.h:64, from include/linux/spinlock.h:50, from include/linux/seqlock.h:35, from include/linux/time.h:5, from include/uapi/linux/timex.h:56, from include/linux/timex.h:56, from include/linux/sched.h:19, from include/linux/utsname.h:5, from drivers/char/random.c:238: drivers/char/random.c: In function 'extract_buf': include/linux/percpu-defs.h:91:33: error: section attribute cannot be specified for local variables extern __PCPU_DUMMY_ATTRS char __pcpu_unique_##name; \ ^ include/linux/percpu-defs.h:116:2: note: in expansion of macro 'DEFINE_PER_CPU_SECTION' DEFINE_PER_CPU_SECTION(type, name, "") ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:92:26: error: section attribute cannot be specified for local variables __PCPU_DUMMY_ATTRS char __pcpu_unique_##name; \ ^ include/linux/percpu-defs.h:116:2: note: in expansion of macro 'DEFINE_PER_CPU_SECTION' DEFINE_PER_CPU_SECTION(type, name, "") ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:92:26: error: declaration of '__pcpu_unique_random_nonce' with no linkage follows extern declaration __PCPU_DUMMY_ATTRS char __pcpu_unique_##name; \ ^ include/linux/percpu-defs.h:116:2: note: in expansion of macro 'DEFINE_PER_CPU_SECTION' DEFINE_PER_CPU_SECTION(type, name, "") ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:91:33: note: previous declaration of '__pcpu_unique_random_nonce' was here extern __PCPU_DUMMY_ATTRS char __pcpu_unique_##name; \ ^ include/linux/percpu-defs.h:116:2: note: in expansion of macro 'DEFINE_PER_CPU_SECTION' DEFINE_PER_CPU_SECTION(type, name, "") ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ >> drivers/char/random.c:1134:31: error: section attribute cannot be specified >> for local variables static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:93:44: note: in definition of macro 'DEFINE_PER_CPU_SECTION' extern __PCPU_ATTRS(sec) __typeof__(type) name; \ ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ >> drivers/char/random.c:1134:31: error: section attribute cannot be specified >> for local variables static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:95:19: note: in definition of macro 'DEFINE_PER_CPU_SECTION' __typeof__(type) name ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ >> drivers/char/random.c:1134:31: error: weak declaration of 'random_nonce' >> must be public static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:95:19: note: in definition of macro 'DEFINE_PER_CPU_SECTION' __typeof__(type) name ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' static DEFINE_PER_CPU(__u32, random_nonce); ^ >> drivers/char/random.c:1134:31: error: declaration of 'random_nonce' with no >> linkage follows extern declaration static DEFINE_PER_CPU(__u32, random_nonce); ^ include/linux/percpu-defs.h:95:19: note: in definition of macro 'DEFINE_PER_CPU_SECTION' __typeof__(type) name ^ drivers/char/random.c:1134:9: note: in expansion of macro 'DEFINE_PER_CPU' stati
Re: [PATCH v4 2/4] mailbox: Hi6220: add mailbox driver
On 16 October 2015 at 11:38, Leo Yan wrote: > On Fri, Oct 16, 2015 at 11:17:32AM +0530, Jassi Brar wrote: >> On Fri, Oct 16, 2015 at 10:59 AM, Leo Yan wrote: >> > On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote: >> >> On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote: >> >> >> >> > + >> >> > +#define MBOX_CHAN_MAX 32 >> >> > +#define MBOX_CHAN_NUM 2 >> >> > + >> >> You mean the hardware has 32 channels but this driver can not manage >> >> more than 2 ? >> >> >> >> OR, there are 32 interfaces but only 2 physical 'floating' links, so >> >> no more than 2 interfaces can be active at any time? >> > >> > For the later case. >> Former is a s/w limitation and latter is h/w limitation. From what you >> write below, it seems former to be the case. > > Sorry, i misunderstood the question. It's a s/w limitation. > >> > Mailbox also can be used by other modules, such >> > like audio hifi; later need add links for them if want to enable >> > audio. But so far only uses first 2 channels. >> > >> You mean every time your platform needs another channel, you'll update >> the driver? Not sure about that. It should be simpler to assign which >> ever and as many channels as the client asks via DT. > > For hi6220, every channel is fixed to specific purpose; on different platform the purposes may be different, so > so i can > register all of them in driver, such like hifi related channels; > Though i cannot test them currently, but this will avoid extra > efforts for enabling channels anymore, do you think this is okay? > Or you prefer to bind with DT? > DT please. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/RFT 0/2] regression fix: "smpboot: do_boot_cpu failed(-1) to wakeup CPU#1"
> Shane, Donald, > Please test this pair of patches. > > If the default kernel still has a problem booting CPU #1 on yoru Core2 system, > "cpu_init_udelay=1" should get you back to the legacy delays. I tried with both patches and it worked fine without cpu_init_udelay. Thanks, Shane -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] leds: rt5033: Add RT5033 Flash led device driver
Hi Jacek,
Sorry I'm late :(
I'll send version3 patch soon
On 2015년 10월 13일 17:53, Jacek Anaszewski wrote:
> Hi Ingi,
>
> On 10/13/2015 04:58 AM, Ingi Kim wrote:
>> Hi Jacek,
>>
>> Thanks for your kind comments
>> I also append reply below
>>
>> On 2015년 10월 13일 00:10, Jacek Anaszewski wrote:
>>> Hi Ingi,
>>>
>>> Thanks for the update. Few comments below.
>>>
>>> On 10/12/2015 03:12 PM, Ingi Kim wrote:
This patch adds device driver of Richtek RT5033 PMIC.
The driver supports a current regulated output to drive
white LEDs for camera flash.
Signed-off-by: Ingi Kim
---
drivers/leds/Kconfig | 8 ++
drivers/leds/Makefile | 1 +
drivers/leds/leds-rt5033.c | 223
+
include/linux/mfd/rt5033-private.h | 49
include/linux/mfd/rt5033.h | 22 +++-
5 files changed, 301 insertions(+), 2 deletions(-)
create mode 100644 drivers/leds/leds-rt5033.c
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 42990f2..29613e3 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -345,6 +345,14 @@ config LEDS_PCA963X
LED driver chip accessed via the I2C bus. Supported
devices include PCA9633 and PCA9634
+config LEDS_RT5033
+tristate "LED support for RT5033 PMIC"
+depends on LEDS_CLASS_FLASH && OF
+depends on MFD_RT5033
+help
+ This option enables support for on-chip LED driver on
+ RT5033 PMIC.
+
config LEDS_WM831X_STATUS
tristate "LED support for status LEDs on WM831x PMICs"
depends on LEDS_CLASS
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index b503f92..bcc4d93 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_LEDS_COBALT_QUBE)+=
leds-cobalt-qube.o
obj-$(CONFIG_LEDS_COBALT_RAQ)+= leds-cobalt-raq.o
obj-$(CONFIG_LEDS_SUNFIRE)+= leds-sunfire.o
obj-$(CONFIG_LEDS_PCA9532)+= leds-pca9532.o
+obj-$(CONFIG_LEDS_RT5033)+= leds-rt5033.o
obj-$(CONFIG_LEDS_GPIO_REGISTER)+= leds-gpio-register.o
obj-$(CONFIG_LEDS_GPIO)+= leds-gpio.o
obj-$(CONFIG_LEDS_LP3944)+= leds-lp3944.o
diff --git a/drivers/leds/leds-rt5033.c b/drivers/leds/leds-rt5033.c
new file mode 100644
index 000..b470c94
--- /dev/null
+++ b/drivers/leds/leds-rt5033.c
@@ -0,0 +1,223 @@
+/*
+ * led driver for RT5033
+ *
+ * Copyright (C) 2015 Samsung Electronics, Co., Ltd.
+ * Ingi Kim
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+#define RT5033_LED_FLASH_TIMEOUT_MIN64000
+#define RT5033_LED_FLASH_TIMEOUT_STEPS32000
+#define RT5033_LED_TORCH_CURRENT_LEVEL_MAX16
+
+/* Macro for getting offset of flash timeout */
+#define GET_TIMEOUT_OFFSET(tm, step)((tm) / (step) - 2)
+
+static struct rt5033_led *flcdev_to_led(
+struct led_classdev_flash *fled_cdev)
+{
+return container_of(fled_cdev, struct rt5033_led, fled_cdev);
+}
+
+static int rt5033_led_brightness_set(struct led_classdev *led_cdev,
+ enum led_brightness brightness)
+{
+struct led_classdev_flash *fled_cdev = lcdev_to_flcdev(led_cdev);
+struct rt5033_led *led = flcdev_to_led(fled_cdev);
>>>
>>> I assume that you don't use mutex here deliberately?
>>>
>>
>> Actually I'm not sure why flash driver uses mutex.
>
> Which flash driver do you have on mind?
>
Oh, nothing on my mind, I can understand it's usage on flash led driver through
your description
>> In consideration of blocking competition, however, I'd be better to use it
>>
>
> [...]
>
+
+static int rt5033_led_flash_strobe_set(struct led_classdev_flash
*fled_cdev,
+ bool state)
+{
+struct rt5033_led *led = flcdev_to_led(fled_cdev);
+u32 flash_tm_reg;
>>>
>>> I think that you need a mutex here and in rt5033_led_flash_strobe_set.
>>> Otherwise following is possible:
>>>
>>> Process 1:
>>> rt5033_led_flash_strobe_set(led_cdev, 1);
>>>
>>> regmap_update_bits(led->regmap,RT5033_REG_FLED_FUNCTION1,
>>> RT5033_FLED_FUNC1_MASK, RT5033_FLED_RESET);
>>> fled_cdev->led_cdev.brightness = LED_OFF;
>>>
>>> Process 2:
>>> led_set_brightness(led_cdev, 1);
>>>
>>> fled_cdev->led_cdev.brightness = 1;
>>>
>>> rt5033_led_brightness_set(led_cdev,
Re: [PATCH v4 2/4] mailbox: Hi6220: add mailbox driver
On Fri, Oct 16, 2015 at 11:17:32AM +0530, Jassi Brar wrote: > On Fri, Oct 16, 2015 at 10:59 AM, Leo Yan wrote: > > On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote: > >> On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote: > >> > >> > + > >> > +#define MBOX_CHAN_MAX 32 > >> > +#define MBOX_CHAN_NUM 2 > >> > + > >> You mean the hardware has 32 channels but this driver can not manage > >> more than 2 ? > >> > >> OR, there are 32 interfaces but only 2 physical 'floating' links, so > >> no more than 2 interfaces can be active at any time? > > > > For the later case. > Former is a s/w limitation and latter is h/w limitation. From what you > write below, it seems former to be the case. Sorry, i misunderstood the question. It's a s/w limitation. > > Mailbox also can be used by other modules, such > > like audio hifi; later need add links for them if want to enable > > audio. But so far only uses first 2 channels. > > > You mean every time your platform needs another channel, you'll update > the driver? Not sure about that. It should be simpler to assign which > ever and as many channels as the client asks via DT. For hi6220, every channel is fixed to specific purpose; so i can register all of them in driver, such like hifi related channels; Though i cannot test them currently, but this will avoid extra efforts for enabling channels anymore, do you think this is okay? Or you prefer to bind with DT? Thanks, Leo Yan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: i8042: add quirk to implement i8042 detect for AMD
Detecting platform supports i8042 or not, AMD resorted to
BIOS's FADT i8042 flag.
Signed-off-by: Vincent Wan
---
drivers/input/serio/i8042-x86ia64io.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/input/serio/i8042-x86ia64io.h
b/drivers/input/serio/i8042-x86ia64io.h
index c115565..bf3a605 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -9,6 +9,7 @@
#ifdef CONFIG_X86
#include
+#include
#endif
/*
@@ -1047,6 +1048,11 @@ static int __init i8042_platform_init(void)
/* Just return if pre-detection shows no i8042 controller exist */
if (!x86_platform.i8042_detect())
return -ENODEV;
+
+ if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD) {
+ if (!(acpi_gbl_FADT.boot_flags & ACPI_FADT_8042))
+ return -ENODEV;
+ }
#endif
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/16] PM / OPP: Add 'supply-names' binding
On 15-10-15, 17:22, Stephen Boyd wrote: > I'm lost why we need this property at all. What happened to using > > opp-microvolt-0 = <1 2 3>; > opp-microvolt-1 = <1>; > opp-microvolt-2 = <3 4 5>; > etc. Perhaps you are confusing this with the bindings we came up for picking right voltage levels based on the cuts/version of the hardware we are running on. The problem that Lee Jones mentioned and that can be used in your case as well. > That seems to avoid any problem with 3 vs. 1 element properties > combined into one large array. That's not the problem I was trying to solve here. > Having supply-names seems too > brittle and would tie us to a particular OPP user's decision to > call supplies by some name. No. The name has to match the -supply property present in the device's node, that's why we need this property :) > Also, I've seen devices that are split across two power domains. > These devices aren't CPUs, but they are other devices including > L2 caches. So we're going to need either multiple regulator > support or multiple "power domain at a particular performance > levels" support somehow. Right, that's a good example of why we need multi-regulator support :) -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/5] cpufreq: create cpu/cpufreq/policyX directories
On 15-10-15, 12:25, Saravana Kannan wrote: > Btw, does a Review-by have an implicit Acked-by? I have attended a session at Linaro Connect where this was discussed and the answer was: Acked-by: is more of a general agreement from the person that he is fine with the patch, but he might not have done a very careful review and he isn't really responsible for the patch's content. Reviewed-by: is a more strict tag and implies that the reviewer has reviewed it at his best and he is as much responsible for the content of the patch as the author. > Kinda unrelated to this patch, but shouldn't this function undo the > symlinks is has created so far before returning? Otherwise, we'd be > leaving around broken symlinks. Hmm, yeah. Will fix it separately. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] mailbox: Hi6220: add mailbox driver
On Fri, Oct 16, 2015 at 10:59 AM, Leo Yan wrote: > On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote: >> On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote: >> >> > + >> > +#define MBOX_CHAN_MAX 32 >> > +#define MBOX_CHAN_NUM 2 >> > + >> You mean the hardware has 32 channels but this driver can not manage >> more than 2 ? >> >> OR, there are 32 interfaces but only 2 physical 'floating' links, so >> no more than 2 interfaces can be active at any time? > > For the later case. Former is a s/w limitation and latter is h/w limitation. From what you write below, it seems former to be the case. > Mailbox also can be used by other modules, such > like audio hifi; later need add links for them if want to enable > audio. But so far only uses first 2 channels. > You mean every time your platform needs another channel, you'll update the driver? Not sure about that. It should be simpler to assign which ever and as many channels as the client asks via DT. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/7] platform-msi: Factor out allocation/free of private data
On 2015/10/15 23:39, Marc Zyngier wrote: > As we're going to have multiple paths to allocate/free the > platform-msi private data, factor this out into separate > utility functions. > > Signed-off-by: Marc Zyngier > --- > drivers/base/platform-msi.c | 84 > ++--- > 1 file changed, 48 insertions(+), 36 deletions(-) > > diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c > index 6148c78..92666cd 100644 > --- a/drivers/base/platform-msi.c > +++ b/drivers/base/platform-msi.c > @@ -189,21 +189,11 @@ struct irq_domain > *platform_msi_create_irq_domain(struct fwnode_handle *fwnode, > return domain; > } > > -/** > - * platform_msi_domain_alloc_irqs - Allocate MSI interrupts for @dev > - * @dev: The device for which to allocate interrupts > - * @nvec:The number of interrupts to allocate > - * @write_msi_msg: Callback to write an interrupt message for @dev > - * > - * Returns: > - * Zero for success, or an error code in case of failure > - */ > -int platform_msi_domain_alloc_irqs(struct device *dev, unsigned int nvec, > -irq_write_msi_msg_t write_msi_msg) > +static int platform_msi_alloc_priv_data(struct device *dev, unsigned int > nvec, > + irq_write_msi_msg_t write_msi_msg, > + struct platform_msi_priv_data **data) How about making platform_msi_alloc_priv_data() return a pointer instead of an int, that may simplify the code a bit. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 4/7] genirq/msi: Make the .prepare callback reusable
On 2015/10/15 23:39, Marc Zyngier wrote:
> +int msi_domain_prepare_irqs(struct irq_domain *domain, struct device *dev,
> + int nvec, msi_alloc_info_t *arg)
> +{
> + struct msi_domain_info *info = domain->host_data;
> + struct msi_domain_ops *ops = info->ops;
> + int ret;
> +
> + ret = ops->msi_check(domain, info, dev);
> + if (ret == 0)
> + ret = ops->msi_prepare(domain, dev, nvec, arg);
> + if (ret)
> + return ret;
> +
> + return 0;
Seems a simple "return ret" is enough:)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/RFT 0/2] regression fix: "smpboot: do_boot_cpu failed(-1) to wakeup CPU#1"
On Fri, 2015-10-16 at 00:14 -0400, Len Brown wrote: > Shane, Donald, > Please test this pair of patches. > > If the default kernel still has a problem booting CPU #1 on your Core2 system, > "cpu_init_udelay=1" should get you back to the legacy delays. Applied patches to Linus' 4.3-rc4 (with none of our recently discussed changes.) Result missing CPU is back! I also tried the "cpu_init_udelay=1" with rc5 and that also gave me back the missing CPU? Previously I had tried "cpu_init_udelay=1" and it did not get missing CPU back (with rc3 or rc4). I can do more testing if you need it. Thanks, Don -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARM: Exynos: Clock for v4.4 (dependency)
Dear Kukjin, Updated to Exynos5250 clock driver, required by next pull with DT. Best regards, Krzysztof The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f: Linux 4.3-rc1 (2015-09-12 16:35:56 -0700) are available in the git repository at: https://github.com/krzk/linux.git tags/samsung-clk-exynos5250-4.4 for you to fetch changes up to 9aaf43d9b59d6b5d8daeb3a4b9d894ea88fc34c5: clk: samsung: exynos5250: Add DISP1 clocks (2015-10-16 08:49:53 +0900) Just one patch for v4.4 (required by DT pull): New clocks for Exynos5250 to fix display issue on Snow board (HDMI and LVDS output is broken after resume from Suspend to RAM). Tomeu Vizoso (1): clk: samsung: exynos5250: Add DISP1 clocks drivers/clk/samsung/clk-exynos5250.c | 14 +- include/dt-bindings/clock/exynos5250.h | 4 +++- 2 files changed, 16 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARM: dts: Exynos for v4.4 (3rd)
Dear Kukjin, Last batch of changes to DT for Exynos for v4.4. Includes dependency - clock driver changes. Best regards, Krzysztof The following changes since commit 9aaf43d9b59d6b5d8daeb3a4b9d894ea88fc34c5: clk: samsung: exynos5250: Add DISP1 clocks (2015-10-16 08:49:53 +0900) are available in the git repository at: https://github.com/krzk/linux.git tags/samsung-dt-4.4-3 for you to fetch changes up to 1967da5699e660957737ec6c4015cfd8e428f0ff: ARM: dts: Add clocks to DISP1 domain in exynos5250 (2015-10-16 14:20:03 +0900) Last round (from my side) of v4.4 Device Tree improvements for Exynos based boards: 1. Fix USB OTG on Exynos3250 (Monk and Rinato), Exynos4210 (Trats and Universal) and Exynos4412 (Trats2). 2. Fix HDMI and LVDS display on Snow (Exynos5250) after second Suspend to RAM. 3. Minor cleanups and fixes. Krzysztof Kozlowski (2): Merge tag 'samsung-clk-exynos5250-4.4' into dt-for-next dt-bindings: Correct the example for Exynos power domain clocks Laurent Pinchart (2): ARM: dts: Fix typo in regulator enable GPIO property in s5pv210-aquila ARM: dts: Fix typo in regulator enable GPIO property in s5pv210-goni Marek Szyprowski (1): ARM: dts: Add vbus regulator to USB2 phy nodes on exynos3250, exynos4210 and exynos4412 boards Tomeu Vizoso (1): ARM: dts: Add clocks to DISP1 domain in exynos5250 Documentation/devicetree/bindings/arm/exynos/power_domain.txt | 5 ++--- arch/arm/boot/dts/exynos3250-monk.dts | 1 + arch/arm/boot/dts/exynos3250-rinato.dts | 1 + arch/arm/boot/dts/exynos4210-trats.dts| 2 +- arch/arm/boot/dts/exynos4210-universal_c210.dts | 2 +- arch/arm/boot/dts/exynos4412-trats2.dts | 1 + arch/arm/boot/dts/exynos5250.dtsi | 4 arch/arm/boot/dts/s5pv210-aquila.dts | 2 +- arch/arm/boot/dts/s5pv210-goni.dts| 4 ++-- 9 files changed, 14 insertions(+), 8 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the cgroup tree with the tip tree
Hi Tejun,
Today's linux-next merge of the cgroup tree got conflicts in:
kernel/events/core.c
kernel/sched/core.c
between commits:
516792e67c39 ("perf/core: Delete PF_EXITING checks from perf_cgroup_exit()
callback")
446685e9bfa1 ("sched/core: Delete PF_EXITING checks from cpu_cgroup_exit()
callback")
from the tip tree and commit:
2e91fa7f6d45 ("cgroup: keep zombies associated with their original cgroups")
from the cgroup tree.
I fixed it up (the latter removed the two functions that were modified
by the former 2 commits) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / OPP: Remove confusing error message in of_cpumask_init_opp_table()
On 15-10-15, 23:26, Rafael J. Wysocki wrote: > Well, to be honest, I would prefer a replacement. Ahh, I thought you will suggest a separate patch so that you don't need to rebase your tree. But I don't have any issues with a new version of the patch. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: phy: smsc: disable energy detect mode
Hello Florian,
Am 14.10.2015 um 06:17 schrieb Heiko Schocher:
Hello Florian,
Am 13.10.2015 um 21:26 schrieb Florian Fainelli:
On 12/10/15 22:13, Heiko Schocher wrote:
On some boards the energy enable detect mode leads in
trouble with some switches, so make the enabling of
this mode configurable through DT.
Signed-off-by: Heiko Schocher
---
.../devicetree/bindings/net/smsc-lan87xx.txt | 19 +
drivers/net/phy/smsc.c | 24 +-
2 files changed, 38 insertions(+), 5 deletions(-)
create mode 100644 Documentation/devicetree/bindings/net/smsc-lan87xx.txt
diff --git a/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
new file mode 100644
index 000..39aa1dc
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/smsc-lan87xx.txt
@@ -0,0 +1,19 @@
+SMSC LAN87xx Ethernet PHY
+
+Some boards require special tuning values. Configure them
+through an Ethernet OF device node.
+
+Optional properties:
+
+- disable-energy-detect:
+ If set, do not enable energy detect mode for the SMSC phy.
+ default: enable energy detect mode
Although energy detection is something that is implemented by many PHYs,
I am not sure a generic property is suitable here, I would prefix that
with the SMSC vendor prefix here to make it clear this only applies to
this PHY.
Hmm... but all PHYs should be able to enable, disable it in some way, or?
ping?
Would not you want to make it a reverse property here though, something
like this:
smsc,energy-detect: boolean, when present indicates the PHY reliably
supports energy detection
Yes, that was also my first thought, but currently, on this PHYs
energy detect mode is on ... and if I introduce such a property,
it will disable it for all existing boards, because property is
missing ... so, maybe I break boards ...
I have a v2 prepared, but what to do here?
+
+Examples:
+
+/* Attach to an Ethernet device with autodetected PHY */
+&cpsw_emac0 {
+phy_id = <&davinci_mdio>, <0>;
+phy-mode = "mii";
+disable-energy-detect;
+};
diff --git a/drivers/net/phy/smsc.c b/drivers/net/phy/smsc.c
index 70b0895..f90fbf3 100644
--- a/drivers/net/phy/smsc.c
+++ b/drivers/net/phy/smsc.c
@@ -43,16 +43,30 @@ static int smsc_phy_ack_interrupt(struct phy_device *phydev)
static int smsc_phy_config_init(struct phy_device *phydev)
{
+#ifdef CONFIG_OF
+int len;
+struct device *dev = &phydev->dev;
+struct device_node *of_node = dev->of_node;
That does not need to be ifdefd out, at best annontate with __maybe_unused?
Yes, I try it.
removed.
+#endif
int rc = phy_read(phydev, MII_LAN83C185_CTRL_STATUS);
+int enable_energy = 1;
if (rc < 0)
return rc;
-/* Enable energy detect mode for this SMSC Transceivers */
-rc = phy_write(phydev, MII_LAN83C185_CTRL_STATUS,
- rc | MII_LAN83C185_EDPWRDOWN);
-if (rc < 0)
-return rc;
+#ifdef CONFIG_OF
+if (!of_node && dev->parent->of_node)
+of_node = dev->parent->of_node;
That looks strange, why would the property be placed at the parent level
when this is a PHY device tree node property?
Hmm.. I recheck this.
Hmm.. the drivers/net/ethernet/ti/cpsw.c has no phy-handle
support ... I added this, so my v2 is now a patchset of 2 patches.
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/4] PM / OPP: Improve debug print messages with pr_fmt
On 15-10-15, 12:04, Stephen Boyd wrote: > On 10/15, Viresh Kumar wrote: > > With debug options on, it is difficult to locate OPP core's debug > > prints. Fix this by prefixing OPP debug prints with KBUILD_MODNAME. > > > > Signed-off-by: Viresh Kumar > > Why not use dynamic debug's m flag to turn on KBUILD_MODNAME when > debugging? > > >From Documentation/dynamic-debug-howto.txt > > mInclude module name in the printed message It wasn't just about debug messages but pr_info and pr_err as well. And so I defined pr_fmt instead. -- viresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 PATCH 4/4] random: Make non-blocking mixback non-blocking
Andi Kleen has reported that some loads cause hideous lock congestion
on the /dev/urandom pool lock. This patch uses some trickery to
allow extract_buf to avoid taking the pool lock to do mixback in case
of contention.
The fundamental idea is that, if there are multiple concurrent
readers, only one mixback is necessary for antibacktracking.
What a reader has to be sure of is that *some* mixback happens
after the reader is done hashing the pool.
So if one CPU is holding the mixback_lock, the others just spam their
mixback data into a global buffer (races be damned) and set a flag.
The lock holder promises to check that flag and do the mixback
before returning. This promise applies the entire time the
mixback_lock is held, so the flag must be checked after dropping it.
In theory this could be applied to the /dev/random pool as well, but
that's not subject to the same kind of abuse as urandom, so leave it
alone for the sake of conservatism.
The first two spin_trylock() operations in nonblocking_mixback() are
not strictly necessary; if either one succeeds, that shortens the
code path, but things would work if they failed unconditionally.
Another legal change would be to move the release of the mixback_lock
after the first __mix_pool_bytes. But since there's a shortcut
optimization if the pool lock is available, that would require keeping
a flag to indicate if the mixback_lock is held and needs to be released.
Signed-off-by: George Spelvin
---
drivers/char/random.c | 104 --
1 file changed, 100 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index cf34e83d..54df2982 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -419,7 +419,6 @@ static LIST_HEAD(random_ready_list);
*
**/
-struct entropy_store;
struct entropy_store {
/* read-only data: */
const struct poolinfo *poolinfo;
@@ -465,7 +464,17 @@ static struct entropy_store blocking_pool = {
push_to_pool),
};
-static struct entropy_store nonblocking_pool = {
+/* This is a variant with some extra fields for nonblocking mixback */
+struct entropy_store_plus {
+ struct entropy_store store;
+ bool mixback_flag;
+ __u32 mixback[SHA_DIGEST_WORDS];
+ spinlock_t mixback_lock;
+};
+
+#define nonblocking_pool nonblocking_plus.store
+static struct entropy_store_plus nonblocking_plus = {
+.store = {
.poolinfo = &poolinfo_table[1],
.name = "nonblocking",
.pull = &input_pool,
@@ -473,6 +482,9 @@ static struct entropy_store nonblocking_pool = {
.pool = nonblocking_pool_data,
.push_work = __WORK_INITIALIZER(nonblocking_pool.push_work,
push_to_pool),
+},
+.mixback_flag = false,
+.mixback_lock = __SPIN_LOCK_UNLOCKED(nonblocking_plus.mixback_lock),
};
static __u32 const twist_table[8] = {
@@ -554,6 +566,83 @@ static void mix_pool_bytes(struct entropy_store *r, const
void *in,
spin_unlock_irqrestore(&r->lock, flags);
}
+/*
+ * Because the /dev/urandom pool is by far the busiest, large machines
+ * with applications that hit the pool hard can fall off the locking
+ * cliff on the pool lock. (They *should* use a private CPRNG reseeded
+ * infrequently, but there are lazy programmers in the world.)
+ *
+ * This function avoids contention on the pool's lock, by taking
+ * advantage of the fact that mixback from a given pool state is logically
+ * idempotent: if there are multiple threads wanting to mix back, only
+ * one of them has to succeed. A non-deterministic mixture of the
+ * competing mixback data is also okay, so we use a common temporary
+ * buffer written without locking.
+ *
+ * It is also not necessary that a thread confirm that mixback has
+ * happened before returning to user space; a backtracking window a few
+ * microseconds long is not a concern, as long as it is strongly bounded.
+ * In this case, because the mixback lock is taken without disabling
+ * interrupts, the window is up to the interrupt latency long, but that's
+ * considered acceptable.
+ *
+ * What is important is that, after a mixback has started, any later
+ * pool readers will schedule an additional mixback. That's what all
+ * the dancing around with mixback_flag and mixback_lock is about.
+ */
+static void nonblocking_mixback(struct entropy_store_plus *r,
+ const void *in, int nbytes)
+{
+ unsigned long flags;
+
+ if (!spin_trylock_irqsave(&r->store.lock, flags)) {
+ /* Someone's currently writing to the pool. Anyone waiting? */
+ if (!spin_trylock(&r->mixback_lock)) {
+ /* Leave it for the lock holder to take care of. */
+ nbytes = min_t(int, nbytes, sizeof(r->mixback));
+ memcpy(r->
[RFC PATCH 3/4] random: Only do mixback once per read
Anti-backtracking is only required on read request boundaries, not on
each few bytes of output.
This reduces contention on the pool lock. Without mixback for each
block of output, some other mechanism must guarantee the hash result
will change each time the pool is hashed. This is provided by the
CPU ID and a per-CPU counter acting as a nonce.
Although a per-read nonce would be simpler for the current operation,
doing it per-CPU helps later.
This is a draft patch; this change has security implications which I'm
not entirely happy with in its current state, but it serves as a stub
for testing performance improvements. (The output is, at least, not
so bad as to cause problems in limited deployment for testing.)
Also, allowing concurrent output from a single pool breaks the FIPS
mode anti-repetition test in a fundamental way. I'm not sure how to
fix that.
Signed-off-by: George Spelvin
---
drivers/char/random.c | 70 ---
1 file changed, 50 insertions(+), 20 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index e62b30ba..cf34e83d 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -966,7 +966,8 @@ EXPORT_SYMBOL_GPL(add_disk_randomness);
static size_t account(struct entropy_store *r, size_t nbytes, int min,
int reserved);
-static void extract_buf(struct entropy_store *r, __u8 out[EXTRACT_SIZE]);
+static void extract_buf(struct entropy_store *r, __u8 out[EXTRACT_SIZE],
+ bool mixback);
/*
* This utility inline function is responsible for transferring entropy
@@ -1028,10 +1029,10 @@ static void _xfer_secondary_pool(struct entropy_store
*r, size_t nbytes)
while (bytes) {
int i = min_t(int, bytes, EXTRACT_SIZE);
- extract_buf(r->pull, tmp);
+ bytes -= i;
+ extract_buf(r->pull, tmp, bytes == 0);
mix_pool_bytes(r, tmp, i);
credit_entropy_bits(r, i*8);
- bytes -= i;
}
memzero_explicit(tmp, sizeof(tmp));
@@ -1110,31 +,54 @@ retry:
* extract_entropy_user.
*
* Note: we assume that .poolwords is a multiple of 16 words.
+ *
+ * The "mixback" flag enables anti-backtracking. This need only be
+ * set on the last extract_buf in a contiguous series of requests.
+ * Ensuring distinct outputs is done by including a unique nonce
+ * (consisting of the CPU ID and a per-CPU counter that will not wrap
+ * before a mixback occurs)
+ *
+ * (FIXME: Is one ahsn's worth of mixback sufficient anti-backtracking
+ * protection? Should we feed back more?)
*/
-static void extract_buf(struct entropy_store *r, __u8 out[EXTRACT_SIZE])
+static void extract_buf(struct entropy_store *r, __u8 out[EXTRACT_SIZE],
+ bool mixback)
{
int i;
union {
__u32 w[5];
- unsigned long l[LONGS(20)];
+ unsigned long l[LONGS(16)];
} hash;
+ __u32 nonce;
__u32 workspace[SHA_WORKSPACE_WORDS];
- unsigned long flags;
+ static DEFINE_PER_CPU(__u32, random_nonce);
/*
* If we have an architectural hardware random number
* generator, use it for SHA's initial vector
*/
sha_init(hash.w);
- for (i = 0; i < LONGS(20); i++) {
+ for (i = 0; i < LONGS(16); i++) {
unsigned long v;
if (!arch_get_random_long(&v))
break;
hash.l[i] = v;
}
+ /* Add the current CPU ID and nonce */
+ hash.w[3] += get_cpu();
+ nonce = __this_cpu_inc_return(random_nonce);
+ put_cpu();
+
+ /*
+* Theoretically, it's possible on a 64-bit system for someone to
+* request EXTRACT_SIZE << 32 bytes in one read. So force mixback
+* to be true each time the nonce wraps.
+*/
+ hash.w[4] += nonce;
+ mixback |= !nonce;
+
/* Generate a hash across the pool, 16 words (512 bits) at a time */
- spin_lock_irqsave(&r->lock, flags);
for (i = 0; i < r->poolinfo->poolwords; i += 16)
sha_transform(hash.w, (__u8 *)(r->pool + i), workspace);
@@ -1146,9 +1170,11 @@ static void extract_buf(struct entropy_store *r, __u8
out[EXTRACT_SIZE])
* mixing at least a SHA1 worth of hash data back, we make
* brute-forcing the feedback as hard as brute-forcing the
* hash.
+*
+* FIXME: update security analysis in light of reduced mixback.
*/
- __mix_pool_bytes(r, hash.w, sizeof(hash.w));
- spin_unlock_irqrestore(&r->lock, flags);
+ if (mixback)
+ mix_pool_bytes(r, hash.w, sizeof(hash.w));
memzero_explicit(workspace, sizeof(workspace));
@@ -1177,7 +1203,7 @@ static void extract_buf(struct entropy_store *r, __u8
out[EXTRACT_SIZE])
static ssize_t extract_entropy(struct entropy_store *r, void *buf,
[RFC PATCH 2/4] random: Remove two unused arguments from extract_entropy()
Now that _xfer_secondary_pool doesn't need the magic functionality,
the "min" and "reserved" arguments are always zero, so stop passing
them.
Signed-off-by: George Spelvin
---
drivers/char/random.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index c8ad49ba..e62b30ba 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -1175,7 +1175,7 @@ static void extract_buf(struct entropy_store *r, __u8
out[EXTRACT_SIZE])
* pool after each pull to avoid starving other readers.
*/
static ssize_t extract_entropy(struct entropy_store *r, void *buf,
-size_t nbytes, int min, int reserved)
+size_t nbytes)
{
ssize_t ret = 0, i;
__u8 tmp[EXTRACT_SIZE];
@@ -1199,7 +1199,7 @@ static ssize_t extract_entropy(struct entropy_store *r,
void *buf,
trace_extract_entropy(r->name, nbytes, ENTROPY_BITS(r), _RET_IP_);
xfer_secondary_pool(r, nbytes);
- nbytes = account(r, nbytes, min, reserved);
+ nbytes = account(r, nbytes, 0, 0);
while (nbytes) {
extract_buf(r, tmp);
@@ -1284,7 +1284,7 @@ void get_random_bytes(void *buf, int nbytes)
nonblocking_pool.entropy_total);
#endif
trace_get_random_bytes(nbytes, _RET_IP_);
- extract_entropy(&nonblocking_pool, buf, nbytes, 0, 0);
+ extract_entropy(&nonblocking_pool, buf, nbytes);
}
EXPORT_SYMBOL(get_random_bytes);
@@ -1374,7 +1374,7 @@ void get_random_bytes_arch(void *buf, int nbytes)
}
if (nbytes)
- extract_entropy(&nonblocking_pool, p, nbytes, 0, 0);
+ extract_entropy(&nonblocking_pool, p, nbytes);
}
EXPORT_SYMBOL(get_random_bytes_arch);
--
2.6.1
h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] mailbox: Hi6220: add mailbox driver
On Fri, Oct 16, 2015 at 10:43:00AM +0530, Jassi Brar wrote: > On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote: > > > + > > +#define MBOX_CHAN_MAX 32 > > +#define MBOX_CHAN_NUM 2 > > + > You mean the hardware has 32 channels but this driver can not manage > more than 2 ? > > OR, there are 32 interfaces but only 2 physical 'floating' links, so > no more than 2 interfaces can be active at any time? For the later case. Mailbox also can be used by other modules, such like audio hifi; later need add links for them if want to enable audio. But so far only uses first 2 channels. Thanks, Leo Yan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/4] random: Reduce stack usage in _xfer_secondary_pool
Rather than asking extract_entropy to fill a large buffer, transfer
bytes in EXTRACT_SIZE chunks using multiple calls to extract_buf.
(Which is what extract_entropy does internally.)
Signed-off-by: George Spelvin
---
drivers/char/random.c | 48
1 file changed, 36 insertions(+), 12 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index d0da5d85..c8ad49ba 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -964,8 +964,9 @@ EXPORT_SYMBOL_GPL(add_disk_randomness);
*
*/
-static ssize_t extract_entropy(struct entropy_store *r, void *buf,
- size_t nbytes, int min, int rsvd);
+static size_t account(struct entropy_store *r, size_t nbytes, int min,
+ int reserved);
+static void extract_buf(struct entropy_store *r, __u8 out[EXTRACT_SIZE]);
/*
* This utility inline function is responsible for transferring entropy
@@ -994,23 +995,46 @@ static void xfer_secondary_pool(struct entropy_store *r,
size_t nbytes)
static void _xfer_secondary_pool(struct entropy_store *r, size_t nbytes)
{
- __u32 tmp[OUTPUT_POOL_WORDS];
-
- /* For /dev/random's pool, always leave two wakeups' worth */
- int rsvd_bytes = r->limit ? 0 : random_read_wakeup_bits / 4;
+ u8 tmp[EXTRACT_SIZE];
int bytes = nbytes;
/* pull at least as much as a wakeup */
bytes = max_t(int, bytes, random_read_wakeup_bits / 8);
/* but never more than the buffer size */
- bytes = min_t(int, bytes, sizeof(tmp));
+ bytes = min_t(int, bytes, OUTPUT_POOL_WORDS*sizeof(u32));
+ /*
+* FIXME: Move this to after account(), so it shows the true amount
+* transferred?
+*/
trace_xfer_secondary_pool(r->name, bytes * 8, nbytes * 8,
ENTROPY_BITS(r), ENTROPY_BITS(r->pull));
- bytes = extract_entropy(r->pull, tmp, bytes,
- random_read_wakeup_bits / 8, rsvd_bytes);
- mix_pool_bytes(r, tmp, bytes);
- credit_entropy_bits(r, bytes*8);
+
+ /*
+* This is the only place we call account() with non-zero
+* "min" and "reserved" values. The minimum is used to
+* enforce catastrophic reseeding: if we can't get at least
+* random_read_wakeup_bits of entropy, don't bother reseeding
+* at all, but wait until a useful amount is available.
+*
+* The "reserved" is used to prevent reads from /dev/urandom
+* from emptying the unput pool; leave two wakeups' worth
+* for /dev/random.
+*/
+ bytes = account(r->pull, bytes, random_read_wakeup_bits / 8,
+ r->limit ? 0 : random_read_wakeup_bits / 4);
+
+ /* Now to the actual transfer, in EXTRACT_SIZE units */
+ while (bytes) {
+ int i = min_t(int, bytes, EXTRACT_SIZE);
+
+ extract_buf(r->pull, tmp);
+ mix_pool_bytes(r, tmp, i);
+ credit_entropy_bits(r, i*8);
+ bytes -= i;
+ }
+
+ memzero_explicit(tmp, sizeof(tmp));
}
/*
@@ -1087,7 +,7 @@ retry:
*
* Note: we assume that .poolwords is a multiple of 16 words.
*/
-static void extract_buf(struct entropy_store *r, __u8 *out)
+static void extract_buf(struct entropy_store *r, __u8 out[EXTRACT_SIZE])
{
int i;
union {
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/4] Alternate sclable urandom patchset
Sent as separate patches to make things easier to review; the action is all in #4. The first two are minor cleanups I've had in my tree for a while and felt like working on top of rather than backing out. The third I'm not happy with, but will serve as a proof-of-concept stub that I'll rewrite if the rest meets with approval. Since writing it, I've remembered that we already have a per-CPU "nonce pool" in the form of the get_random_int_hash array, and I should take advantage of that. Another thing I don't like is the mixback is only 160 bits, 80 of which are private. I'd rather have twice that, if the read is large enough. But that requires more code refactoring. But it does illustrate the basic idea of using a nonce to avoid the need to do synchronous mixback. We can do many calls to extract_buf, from the same or different processors, without doing mixback. The fourth is where the fun is. The names of things is certainly up for debate; creating a subclass of struct entropy_store called "entropy_store_plus" is not my proudest moment. I also considered just making the extra fields global variables. If someone wants to suggest an arrangement that's good for cache line sharing, that would be appreciated. But I think the nonblocking_mixback() function came out rather nice. This uses two locks, rather that the one in the idea I most recently posted, because add_interrupt_randomness() needs to take the lock, and I didn't want to force it to do an unbounded amount of mixback work. Using two locks avoids the need for interrupt handlers to do any mixback, and for readers to loop and thus possibly livelock. George Spelvin (4): random: Reduce stack usage in _xfer_secondary_pool random: Remove two unused arguments from extract_entropy() random: Only do mixback once per read random: Make non-blocking mixback non-blocking drivers/char/random.c | 218 ++ 1 file changed, 184 insertions(+), 34 deletions(-) -- 2.6.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: dts: uniphier: add ProXstream2 Vodka board support
Hi Arnd,
2015-10-16 0:17 GMT+09:00 Arnd Bergmann :
> On Thursday 15 October 2015 18:05:33 Masahiro Yamada wrote:
>> + aliases {
>> + serial0 = &serial0;
>> + serial1 = &serial1;
>> + serial2 = &serial2;
>> + i2c0 = &i2c0;
>> + i2c4 = &i2c4;
>> + i2c5 = &i2c5;
>> + i2c6 = &i2c6;
>>
>
> This looks like a typo, you probably mean
>
>i2c0 = &i2c0;
>i2c1 = &i2c4;
>i2c2 = &i2c5;
>i2c3 = &i2c6;
>
> Can you re-send this?
>
No, it is not a typo, but intentional.
i2c0 - i2c3 are connected to the pads of the SoC package.
On the other hand, i2c-4 - i2c-6 are connected to
internal devices inside the SoC package.
i2c-4 - i2c-6 are always connected to the same hardware
devices and always used for the same purpose.
My expected scenario is:
[1] i2c0 - i2c3 are connected to the on-board devices
depending on board variants.
On some boards, their status is "okay" and
on some boards, their status is "disabled".
[2] i2c4 - i2c6 are always used to communicate
with in-package devices. The status is always "okay".
[3] Some user-land applications may want to have access
through the same character devices,
/dev/i2c4, /dev/i2c5, /dev/i2c6
If your way is adopted,
the real hardware "i2c4" might be aligned to /dev/i2c1 on some boards,
and /dev/i2c2 on others, etc.
--
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] dt-bindings: mailbox: Document Hi6220 mailbox driver
Hi Jassi, Thanks for review. On Fri, Oct 16, 2015 at 10:26:48AM +0530, Jassi Brar wrote: > On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote: > > > + > > +Mailbox Device Node: > > + > > + > > +Required properties: > > + > > +- compatible: Shall be "hisilicon,hi6220-mbox" > > +- reg: Contains the mailbox register address range (base > > + address and length); the first item is for IPC > > + registers, the second item is shared buffer for > > + slots. > > > Is the shared-buffer a part of mailbox controller or just regular > memory that could be used for purposes other than mailbox also? If > latter, please remove it from here. The shared-buffer is part of mailbox controller, this region cannot be dynamically allocated for other purpose; it's hardcode by MCU firmware. > > +Mailbox client > > +=== > > + > > +"mboxes" and the optional "mbox-names" (please see > > +Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each > > value > > +of the mboxes property should contain a phandle to the mailbox controller > > +device node and second argument is the channel index. It must be 0 > > (hardware > > +support only one channel). > > > sorry, what must be 0? You have MBOX_CHAN_MAX and MBOX_CHAN_NUM as 32 > and 2 in the driver. Will fix it. Thanks, Leo Yan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/4] mailbox: Hi6220: add mailbox driver
On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote: > + > +#define MBOX_CHAN_MAX 32 > +#define MBOX_CHAN_NUM 2 > + You mean the hardware has 32 channels but this driver can not manage more than 2 ? OR, there are 32 interfaces but only 2 physical 'floating' links, so no more than 2 interfaces can be active at any time? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] ath6kl: Use vmalloc for loading firmware using api1 method
Signed-off-by: Brent Taylor
---
drivers/net/wireless/ath/ath6kl/init.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/ath/ath6kl/init.c
b/drivers/net/wireless/ath/ath6kl/init.c
index 6e473fa..2155739 100644
--- a/drivers/net/wireless/ath/ath6kl/init.c
+++ b/drivers/net/wireless/ath/ath6kl/init.c
@@ -673,10 +673,17 @@ static int ath6kl_get_fw(struct ath6kl *ar, const char
*filename,
return ret;
*fw_len = fw_entry->size;
- *fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
-
- if (*fw == NULL)
- ret = -ENOMEM;
+ if (&ar->fw == fw) {
+ *fw = vmalloc(fw_entry->size);
+ if (*fw == NULL)
+ ret = -ENOMEM;
+ else
+ memcpy(*fw, fw_entry->data, fw_entry->size);
+ } else {
+ *fw = kmemdup(fw_entry->data, fw_entry->size, GFP_KERNEL);
+ if (*fw == NULL)
+ ret = -ENOMEM;
+ }
release_firmware(fw_entry);
--
2.6.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/4] dt-bindings: mailbox: Document Hi6220 mailbox driver
On Mon, Oct 12, 2015 at 10:02 PM, Leo Yan wrote: > + > +Mailbox Device Node: > + > + > +Required properties: > + > +- compatible: Shall be "hisilicon,hi6220-mbox" > +- reg: Contains the mailbox register address range (base > + address and length); the first item is for IPC > + registers, the second item is shared buffer for > + slots. > Is the shared-buffer a part of mailbox controller or just regular memory that could be used for purposes other than mailbox also? If latter, please remove it from here. > +Mailbox client > +=== > + > +"mboxes" and the optional "mbox-names" (please see > +Documentation/devicetree/bindings/mailbox/mailbox.txt for details). Each > value > +of the mboxes property should contain a phandle to the mailbox controller > +device node and second argument is the channel index. It must be 0 (hardware > +support only one channel). > sorry, what must be 0? You have MBOX_CHAN_MAX and MBOX_CHAN_NUM as 32 and 2 in the driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 39/39] Update the buildsystem for KConfig finding Qt
Hi
On 2015-10-16, Stefan Lippers-Hollmann wrote:
> On 2015-09-22, Thiago Macieira wrote:
[...]
> + QT_SELECT=5 qmake -query QT_VERSION >/dev/null 2>&1 && export
> QT_SELECT=5 ||: ; \
Apparently this fails if qmake isn't guarded by qtchooser, but the
following should work (although I'm still not confident if that would
be the best approach):
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -227,6 +227,7 @@ $(obj)/.tmp_qtcheck: $(src)/Makefile
# Qt needs some extra effort...
$(obj)/.tmp_qtcheck:
@set -e; $(kecho) " CHECK qt"; \
+ qtchooser --list-versions | grep -q ^5$ && export QT_SELECT=5 ||: ; \
qtver=`qmake -query QT_VERSION` || { \
echo >&2 "*"; \
echo >&2 "* qmake failed."; \
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: linux-next: manual merge of the kvm-arm tree with the kvm tree
> -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: Friday, October 16, 2015 11:53 AM > To: Christoffer Dall ; Marc Zyngier > ; Marcelo Tosatti ; Gleb > Natapov ; k...@vger.kernel.org > Cc: linux-n...@vger.kernel.org; linux-kernel@vger.kernel.org; Wu, Feng > ; Paolo Bonzini ; Christian > Borntraeger ; Cornelia Huck > > Subject: linux-next: manual merge of the kvm-arm tree with the kvm tree > > I fixed it up (see below) and can carry the fix as necessary (no action > is required). Thanks Stephen! Thanks, Feng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] Mailbox: Provide support STi based platforms
On 5 October 2015 at 18:32, Lee Jones wrote: > Hi Jassi, > > This should be it. Exciting times! > > ST's platforms currently support a maximum of 5 Mailboxes, one for > each of the supported co-processors situated on the platform. Each > Mailbox is divided up into 4 instances which consist of 32 channels. > Messages are passed between the application and co-processors using > shared memory areas. > > Also included in the set is an example Client which should be generic > enough to use as a testing environment for all Mailbox IPs which use > shared memory or the API to pass messages. With small changes, it > should also be able to test more extravagant implementations. > > v3 -> v4: > - More protection in MBOX_BASE() MACRO > - Remove unused tx-only marker > Are you sure about the tx-only marker? :) Since it is also a DT property, I think we should have it removed before we apply the patchset. Lets get it done today. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 39/39] Update the buildsystem for KConfig finding Qt
Hi
On 2015-09-22, Thiago Macieira wrote:
> The buildsystem will now only search for Qt 4 and Qt 5. Support for Qt 2
> and 3 was dropped in the previous commits (Qt 3 was EOL'ed in 2010 or
> so...).
>
> For Qt 5, to be future-proof with the future direction notice appearing
> in the 5.5 release, C++11 support is automatically enabled.
[...]
> --- a/scripts/kconfig/Makefile
> +++ b/scripts/kconfig/Makefile
[...]
> + @set -e; $(kecho) " CHECK qt"; \
> + qtver=`qmake -query QT_VERSION` || { \
> + echo >&2 "*"; \
> + echo >&2 "* qmake failed."; \
> + echo >&2 "*"; \
> + exit 1; \
> + }; \
[...]
"qmake -query QT_VERSION" appears to be a little fragile on Debian
with both qt4-qmake and qt5-qmake installed, as it reports back
"4.8.7" by default. The actual qmake is hiding behind qtchooser
(/usr/bin/qmake -> qtchooser) and will report different environments
based on the chosen personality:
$ qmake -query QT_VERSION
4.8.7
$ QT_SELECT=5 qmake -query QT_VERSION
5.4.2
While I'm not quite sure what would be the best kind of test
here (and if qtchooser can be commonly expected), the following
might provide another approach to query the most recent installed
qt version:
$ qtchooser --list-versions | grep ^[0-9]*$ | sort | tac | head -n1
5
(and then exporting QT_SELECT=5 to the rest of the build).
Another approach which appears to work for me (with both qt4 and qt5)
would be this, but I'm not quite sure if this would be a good solution:
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -227,6 +227,7 @@ $(obj)/.tmp_qtcheck: $(src)/Makefile
# Qt needs some extra effort...
$(obj)/.tmp_qtcheck:
@set -e; $(kecho) " CHECK qt"; \
+ QT_SELECT=5 qmake -query QT_VERSION >/dev/null 2>&1 && export
QT_SELECT=5 ||: ; \
qtver=`qmake -query QT_VERSION` || { \
echo >&2 "*"; \
echo >&2 "* qmake failed."; \
Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86 smpboot: fix cpu_init_udelay=10000
From: Len Brown
For legacy machines cpu_init_udelay defaults to 10,000.
For modern machines it is set to 0.
The user should be able to set cpu_init_udelay to
any value on the cmdline, including 10,000.
Before this patch, that was seen as "unchanged from default"
and thus on a modern machine, the user request was ignored
and the delay was set to 0.
Signed-off-by: Len Brown
---
arch/x86/kernel/smpboot.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index e0c198e..32267cc 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -509,7 +509,7 @@ void __inquire_remote_apic(int apicid)
*/
#define UDELAY_10MS_DEFAULT 1
-static unsigned int init_udelay = UDELAY_10MS_DEFAULT;
+static unsigned int init_udelay = INT_MAX;
static int __init cpu_init_udelay(char *str)
{
@@ -522,13 +522,16 @@ early_param("cpu_init_udelay", cpu_init_udelay);
static void __init smp_quirk_init_udelay(void)
{
/* if cmdline changed it from default, leave it alone */
- if (init_udelay != UDELAY_10MS_DEFAULT)
+ if (init_udelay != INT_MAX)
return;
/* if modern processor, use no delay */
if (((boot_cpu_data.x86_vendor == X86_VENDOR_INTEL) &&
(boot_cpu_data.x86 == 6)) ||
((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) && (boot_cpu_data.x86
>= 0xF)))
init_udelay = 0;
+
+ /* else, use legacy delay */
+ init_udelay = UDELAY_10MS_DEFAULT;
}
/*
--
2.6.1.145.gb27dacc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/RFT 0/2] regression fix: "smpboot: do_boot_cpu failed(-1) to wakeup CPU#1"
Shane, Donald, Please test this pair of patches. If the default kernel still has a problem booting CPU #1 on yoru Core2 system, "cpu_init_udelay=1" should get you back to the legacy delays. thanks, Len Brown, 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/
[PATCH 2/2] x86 smpboot: fix CPU #1 boot timeout
From: Len Brown
Commit a9bcaa02a5104ace6a9d9e4a9cd9192a9e7744d6
("x86/smpboot: Remove SIPI delays from cpu_up()")
Caused some Intel Core2 processors to time-out when bringing up CPU #1.
That patch reduced the SIPI delays from udelay() 300, 200
to udelay() 0, 0 on modern processors.
Several Intel(R) Core(TM)2 systems
failed to bring up CPU #1 10/10 times after that change.
Increasing either of the SIPI delays to udelay(1) results in success.
So here we increase both to udelay(10). While this may be 20x slower
than the absolute minimum, it is still 20x to 30x faster
than the original code.
Signed-off-by: Len Brown
---
arch/x86/kernel/smpboot.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 32267cc..892ee2e5 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -660,7 +660,9 @@ wakeup_secondary_cpu_via_init(int phys_apicid, unsigned
long start_eip)
/*
* Give the other CPU some time to accept the IPI.
*/
- if (init_udelay)
+ if (init_udelay == 0)
+ udelay(10);
+ else
udelay(300);
pr_debug("Startup point 1\n");
@@ -671,7 +673,9 @@ wakeup_secondary_cpu_via_init(int phys_apicid, unsigned
long start_eip)
/*
* Give the other CPU some time to accept the IPI.
*/
- if (init_udelay)
+ if (init_udelay == 0)
+ udelay(10);
+ else
udelay(200);
if (maxlvt > 3) /* Due to the Pentium erratum 3AP. */
--
2.6.1.145.gb27dacc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] watchdog: Compile possible drivers with COMPILE_TEST
Hi Luis,
[auto build test ERROR on v4.3-rc5 -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/Luis-de-Bethencourt/watchdog-Compile-possible-drivers-with-COMPILE_TEST/20151015-025729
config: um-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=um
All error/warnings (new ones prefixed by >>):
drivers/watchdog/digicolor_wdt.c: In function 'dc_wdt_probe':
>> drivers/watchdog/digicolor_wdt.c:167:2: error: implicit declaration of
>> function 'iounmap' [-Werror=implicit-function-declaration]
iounmap(wdt->base);
^
cc1: some warnings being treated as errors
--
drivers/watchdog/sc520_wdt.c: In function 'sc520_wdt_unload':
>> drivers/watchdog/sc520_wdt.c:380:2: error: implicit declaration of function
>> 'iounmap' [-Werror=implicit-function-declaration]
iounmap(wdtmrctl);
^
drivers/watchdog/sc520_wdt.c: In function 'sc520_wdt_init':
>> drivers/watchdog/sc520_wdt.c:395:13: error: implicit declaration of function
>> 'ioremap' [-Werror=implicit-function-declaration]
wdtmrctl = ioremap(MMCR_BASE + OFFS_WDTMRCTL, 2);
^
>> drivers/watchdog/sc520_wdt.c:395:11: warning: assignment makes pointer from
>> integer without a cast [-Wint-conversion]
wdtmrctl = ioremap(MMCR_BASE + OFFS_WDTMRCTL, 2);
^
cc1: some warnings being treated as errors
vim +/iounmap +167 drivers/watchdog/digicolor_wdt.c
336694a0 Baruch Siach 2015-03-31 151 watchdog_init_timeout(&dc_wdt_wdd,
timeout, dev);
336694a0 Baruch Siach 2015-03-31 152 ret =
watchdog_register_device(&dc_wdt_wdd);
336694a0 Baruch Siach 2015-03-31 153 if (ret) {
336694a0 Baruch Siach 2015-03-31 154 dev_err(dev, "Failed to
register watchdog device");
336694a0 Baruch Siach 2015-03-31 155 goto err_iounmap;
336694a0 Baruch Siach 2015-03-31 156 }
336694a0 Baruch Siach 2015-03-31 157
336694a0 Baruch Siach 2015-03-31 158 wdt->restart_handler.notifier_call =
dc_restart_handler;
336694a0 Baruch Siach 2015-03-31 159 wdt->restart_handler.priority = 128;
336694a0 Baruch Siach 2015-03-31 160 ret =
register_restart_handler(&wdt->restart_handler);
336694a0 Baruch Siach 2015-03-31 161 if (ret)
336694a0 Baruch Siach 2015-03-31 162 dev_warn(&pdev->dev, "cannot
register restart handler\n");
336694a0 Baruch Siach 2015-03-31 163
336694a0 Baruch Siach 2015-03-31 164 return 0;
336694a0 Baruch Siach 2015-03-31 165
336694a0 Baruch Siach 2015-03-31 166 err_iounmap:
336694a0 Baruch Siach 2015-03-31 @167 iounmap(wdt->base);
336694a0 Baruch Siach 2015-03-31 168 return ret;
336694a0 Baruch Siach 2015-03-31 169 }
336694a0 Baruch Siach 2015-03-31 170
336694a0 Baruch Siach 2015-03-31 171 static int dc_wdt_remove(struct
platform_device *pdev)
336694a0 Baruch Siach 2015-03-31 172 {
336694a0 Baruch Siach 2015-03-31 173 struct dc_wdt *wdt =
platform_get_drvdata(pdev);
336694a0 Baruch Siach 2015-03-31 174
336694a0 Baruch Siach 2015-03-31 175
unregister_restart_handler(&wdt->restart_handler);
:: The code at line 167 was first introduced by commit
:: 336694a01dae7e788630f8043dae30337047b51b watchdog: digicolor: driver for
Conexant Digicolor CX92755 SoC
:: TO: Baruch Siach
:: CC: Wim Van Sebroeck
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
[git pull] drm fixes
Hi Linus, two MAINTAINERS entries that I didn't see the point in delaying. one drm mst fix to stop sending uninitialised data to monitors two amdgpu fixes one radeon mst tiling fix one vmwgfx regression fix one virtio warning fix. Nothing two crazy or exciting. I have found one locking problem that needs a bit of reorg to fix, but I'm not sure it's worth putting in -fixes as I don't think we've seen it hit in the real world ever, I just found it using the virtio-gpu driver when working on it. I'll possibly send it next week once I've time to discuss with Daniel. Dave. The following changes since commit 5b5f1455272e23f4e7889cec37228802d8d01adf: Merge tag 'nfsd-4.3-2' of git://linux-nfs.org/~bfields/linux (2015-10-13 11:31:03 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes for you to fetch changes up to d549f545e690c3cbdeb33df3579eae3230eb8904: drm/virtio: use %llu format string form atomic64_t (2015-10-16 11:36:36 +1000) Alex Deucher (1): drm/amdgpu: adjust default dispclk (v2) Arnd Bergmann (1): drm/virtio: use %llu format string form atomic64_t Boris BREZILLON (1): MAINTAINERS: add a maintainer for the atmel-hlcdc DRM driver Dave Airlie (4): drm/radeon: attach tile property to mst connector drm/dp/mst: make mst i2c transfer code more robust. Merge tag 'vmwgfx-fixes-4.3-151014' of git://people.freedesktop.org/~thomash/linux into drm-fixes Merge branch 'drm-fixes-4.3' of git://people.freedesktop.org/~agd5f/linux into drm-fixes Michel Dänzer (1): drm/amdgpu: Keep the pflip interrupts always enabled v7 Patrik Jakobsson (1): MAINTAINERS: Add myself as maintainer for the gma500 driver Thomas Hellstrom (1): drm/vmwgfx: Fix kernel NULL pointer dereference on older hardware MAINTAINERS | 15 ++ drivers/gpu/drm/amd/amdgpu/amdgpu_atombios.c | 8 ++-- drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 2 -- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 30 ++-- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 30 ++-- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c| 30 ++-- drivers/gpu/drm/drm_dp_mst_topology.c| 3 ++- drivers/gpu/drm/radeon/radeon_dp_mst.c | 1 + drivers/gpu/drm/virtio/virtgpu_debugfs.c | 4 ++-- drivers/gpu/drm/virtio/virtgpu_fence.c | 2 +- drivers/gpu/drm/vmwgfx/vmwgfx_surface.c | 3 ++- include/drm/drm_dp_mst_helper.h | 3 ++- 12 files changed, 115 insertions(+), 16 deletions(-)
[PATCH] zsmalloc: reduce size_class memory usage
Each `struct size_class' contains `struct zs_size_stat':
an array of NR_ZS_STAT_TYPE `unsigned long'. For zsmalloc
built with no CONFIG_ZSMALLOC_STAT this results in a waste
of `2 * sizeof(unsigned long)' per-class.
The patch removes unneeded `struct zs_size_stat' members
by redefining NR_ZS_STAT_TYPE (max stat idx in array).
Since both NR_ZS_STAT_TYPE and zs_stat_type are compile time
constants, GCC can eliminate zs_stat_inc()/zs_stat_dec() calls
that use zs_stat_type larger than NR_ZS_STAT_TYPE:
CLASS_ALMOST_EMPTY and CLASS_ALMOST_FULL at the moment.
./scripts/bloat-o-meter mm/zsmalloc.o.old mm/zsmalloc.o.new
add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-39 (-39)
function old new delta
fix_fullness_group97 94 -3
insert_zspage100 86 -14
remove_zspage141 119 -22
To summarize:
a) each class now uses less memory
b) we avoid a number of dec/inc stats (a minor optimization,
but still).
The gain will increase once we introduce additional stats.
A simple IO test.
iozone -t 4 -R -r 32K -s 60M -I +Z
patched base
" Initial write " 4145599.06 4127509.75
"Rewrite " 4146225.94 4223618.50
" Read " 17157606.00 17211329.50
"Re-read " 17380428.00 17267650.50
" Reverse Read " 16742768.00 16162732.75
"Stride read " 16586245.75 16073934.25
"Random read " 16349587.50 15799401.75
" Mixed workload " 10344230.62 9775551.50
" Random write " 4277700.62 4260019.69
" Pwrite " 4302049.12 4313703.88
" Pread " 6164463.16 6126536.72
" Fwrite " 7131195.00 6952586.00
" Fread " 12682602.25 12619207.50
Signed-off-by: Sergey Senozhatsky
---
mm/zsmalloc.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 2500ee8..0331c9a9 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -166,9 +166,14 @@ enum zs_stat_type {
OBJ_USED,
CLASS_ALMOST_FULL,
CLASS_ALMOST_EMPTY,
- NR_ZS_STAT_TYPE,
};
+#ifdef CONFIG_ZSMALLOC_STAT
+#define NR_ZS_STAT_TYPE(CLASS_ALMOST_EMPTY + 1)
+#else
+#define NR_ZS_STAT_TYPE(OBJ_USED + 1)
+#endif
+
struct zs_size_stat {
unsigned long objs[NR_ZS_STAT_TYPE];
};
@@ -447,19 +452,23 @@ static int get_size_class_index(int size)
static inline void zs_stat_inc(struct size_class *class,
enum zs_stat_type type, unsigned long cnt)
{
- class->stats.objs[type] += cnt;
+ if (type < NR_ZS_STAT_TYPE)
+ class->stats.objs[type] += cnt;
}
static inline void zs_stat_dec(struct size_class *class,
enum zs_stat_type type, unsigned long cnt)
{
- class->stats.objs[type] -= cnt;
+ if (type < NR_ZS_STAT_TYPE)
+ class->stats.objs[type] -= cnt;
}
static inline unsigned long zs_stat_get(struct size_class *class,
enum zs_stat_type type)
{
- return class->stats.objs[type];
+ if (type < NR_ZS_STAT_TYPE)
+ return class->stats.objs[type];
+ return 0;
}
#ifdef CONFIG_ZSMALLOC_STAT
--
2.6.1.134.g4b1fd35
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] scsi: kconfig: When possible, compile drivers with COMPILE_TEST
Hi Luis, [auto build test ERROR on scsi/for-next -- if it's inappropriate base, please suggest rules for selecting the more suitable base] url: https://github.com/0day-ci/linux/commits/Luis-de-Bethencourt/scsi-kconfig-When-possible-compile-drivers-with-COMPILE_TEST/20151015-073819 config: um-allmodconfig (attached as .config) reproduce: # save the attached .config to linux build tree make ARCH=um All error/warnings (new ones prefixed by >>): drivers/scsi/aha152x.c: In function 'aha152x_init': >> drivers/scsi/aha152x.c:3261:22: error: implicit declaration of function >> 'ioremap' [-Werror=implicit-function-declaration] void __iomem *p = ioremap(addresses[i], 0x4000); ^ >> drivers/scsi/aha152x.c:3261:22: warning: initialization makes pointer from >> integer without a cast [-Wint-conversion] >> drivers/scsi/aha152x.c:3267:4: error: implicit declaration of function >> 'iounmap' [-Werror=implicit-function-declaration] iounmap(p); ^ cc1: some warnings being treated as errors -- drivers/scsi/in2000.c: In function 'probe_bios': >> drivers/scsi/in2000.c:1903:20: error: implicit declaration of function >> 'ioremap' [-Werror=implicit-function-declaration] void __iomem *p = ioremap(addr, 0x34); ^ >> drivers/scsi/in2000.c:1903:20: warning: initialization makes pointer from >> integer without a cast [-Wint-conversion] >> drivers/scsi/in2000.c:1910:3: error: implicit declaration of function >> 'iounmap' [-Werror=implicit-function-declaration] iounmap(p); ^ cc1: some warnings being treated as errors -- In file included from drivers/scsi/g_NCR5380_mmio.c:9:0: drivers/scsi/g_NCR5380.c: In function 'generic_NCR5380_detect': >> drivers/scsi/g_NCR5380.c:399:11: error: implicit declaration of function >> 'ioremap' [-Werror=implicit-function-declaration] iomem = ioremap(base, NCR5380_region_size); ^ >> drivers/scsi/g_NCR5380.c:399:9: warning: assignment makes pointer from >> integer without a cast [-Wint-conversion] iomem = ioremap(base, NCR5380_region_size); ^ >> drivers/scsi/g_NCR5380.c:410:4: error: implicit declaration of function >> 'iounmap' [-Werror=implicit-function-declaration] iounmap(iomem); ^ cc1: some warnings being treated as errors -- drivers/scsi/t128.c: In function 't128_detect': >> drivers/scsi/t128.c:180:10: error: implicit declaration of function >> 'ioremap' [-Werror=implicit-function-declaration] p = ioremap(bases[current_base].address, 0x2000); ^ >> drivers/scsi/t128.c:180:8: warning: assignment makes pointer from integer >> without a cast [-Wint-conversion] p = ioremap(bases[current_base].address, 0x2000); ^ drivers/scsi/t128.c:190:5: warning: assignment makes pointer from integer without a cast [-Wint-conversion] p = ioremap(bases[current_base].address, 0x2000); ^ >> drivers/scsi/t128.c:203:3: error: implicit declaration of function 'iounmap' >> [-Werror=implicit-function-declaration] iounmap(p); ^ cc1: some warnings being treated as errors -- drivers/scsi/dtc.c: In function 'dtc_detect': >> drivers/scsi/dtc.c:203:11: error: implicit declaration of function 'ioremap' >> [-Werror=implicit-function-declaration] base = ioremap(addr, 0x2000); ^ >> drivers/scsi/dtc.c:203:9: warning: assignment makes pointer from integer >> without a cast [-Wint-conversion] base = ioremap(addr, 0x2000); ^ drivers/scsi/dtc.c:213:10: warning: assignment makes pointer from integer without a cast [-Wint-conversion] base = ioremap(bases[current_base].address, 0x2000); ^ >> drivers/scsi/dtc.c:225:5: error: implicit declaration of function 'iounmap' >> [-Werror=implicit-function-declaration] iounmap(base); ^ cc1: some warnings being treated as errors vim +/ioremap +3261 drivers/scsi/aha152x.c ^1da177e Linus Torvalds 2005-04-16 3255 ^1da177e Linus Torvalds 2005-04-16 3256 #if defined(AUTOCONF) ^1da177e Linus Torvalds 2005-04-16 3257 if (setup_count :: CC: Linus Torvalds --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation .config.gz Description: Binary data
Re: [BUG?] kernel OOPS at kmem_cache_alloc_node() because of smp_processor_id()
On 2015/10/15 22:39, Christoph Lameter wrote: > On Thu, 15 Oct 2015, Gonglei (Arei) wrote: > >> [0.016000] Call Trace: >> [0.016000] [] dump_trace+0x6c/0x2d0 >> [0.016000] [] dump_stack+0x69/0x71 >> [0.016000] [] panic+0x78/0x199 >> [0.016000] [] do_exit+0x26f/0x360 >> [0.016000] [] oops_end+0xe1/0xf0 >> [0.016000] [] __bad_area_nosemaphore+0x155/0x230 >> [0.016000] [] page_fault+0x1f/0x30 >> [0.016000] [] kmem_cache_alloc_node+0xbf/0x140 >> [0.016000] [] alloc_cpumask_var_node+0x16/0x70 >> [0.016000] [] native_send_call_func_ipi+0x18/0xf0 >> [0.016000] [] smp_call_function_many+0x1ae/0x250 >> [0.016000] [] smp_call_function+0x20/0x30 >> [0.016000] [] set_mtrr+0x5a/0x140 >> [0.016000] [] smp_callin+0xf0/0x1b4 >> [0.016000] [] start_secondary+0xe/0xb5 > > This happened during IPI processing? > >> crash> p cache_cache > > Arg. This is the SLAB allocator. You cannot enable debugging without > rebuilding the kernel with CONFIG_SLAB_DEBUG. > >> smp_processor_id() return 14, the CPU14, but the CPU14 is *stuck*, so cache= >> p->array[14] is NULL, >> why did this situation happen? And cause NULL pointer accessing? Is this a = >> kernel bug? > > Its likely a bug in some obscure code in a driver that corrupted memory or > messed up the way memory was handled. set_mtrr()? What was going on at the > time? A special graphics driver being loaded? That could cause issues. > It seems that the problem was fixed by Igor, right? https://lkml.org/lkml/2014/3/6/257 Cced Igor Mammedov. Regards, -Gonglei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the kvm-arm tree with the kvm tree
Hi all,
Today's linux-next merge of the kvm-arm tree got a conflict in:
arch/x86/include/asm/kvm_host.h
between commit:
d84f1e0755ba ("KVM: make kvm_set_msi_irq() public")
from the kvm tree and commits:
8feb4a04dc75 ("KVM: Define a new interface kvm_intr_is_single_vcpu()")
8fc52eb9cee4 ("KVM: Add kvm_arch_vcpu_{un}blocking callbacks")
from the kvm-arm tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc arch/x86/include/asm/kvm_host.h
index 53deb2750bf6,b926137d591f..
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@@ -1256,9 -1232,7 +1256,13 @@@ int x86_set_memory_region(struct kvm *k
bool kvm_vcpu_is_reset_bsp(struct kvm_vcpu *vcpu);
bool kvm_vcpu_is_bsp(struct kvm_vcpu *vcpu);
+bool kvm_intr_is_single_vcpu(struct kvm *kvm, struct kvm_lapic_irq *irq,
+ struct kvm_vcpu **dest_vcpu);
+
+void kvm_set_msi_irq(struct kvm_kernel_irq_routing_entry *e,
+ struct kvm_lapic_irq *irq);
++
+ static inline void kvm_arch_vcpu_blocking(struct kvm_vcpu *vcpu) {}
+ static inline void kvm_arch_vcpu_unblocking(struct kvm_vcpu *vcpu) {}
+
#endif /* _ASM_X86_KVM_HOST_H */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acpi: set return value to const char for some functions
On Fri, 2015-10-16 at 03:37 +, Moore, Robert wrote: > If you don't like the quote, just stick with my first assessment. Thanks, but if you can't make arguments yourself, it seems you're making assertions rather than assessments. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v3 1/2] net: hisilicon rm hnae sysfs interface
This patch removes the hns driver hnae sysfs interface according to
Arnd's review comments.
Signed-off-by: huangdaode
---
drivers/net/ethernet/hisilicon/hns/hnae.c | 47 ---
1 file changed, 47 deletions(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hnae.c
b/drivers/net/ethernet/hisilicon/hns/hnae.c
index f52e99a..9d3bb83 100644
--- a/drivers/net/ethernet/hisilicon/hns/hnae.c
+++ b/drivers/net/ethernet/hisilicon/hns/hnae.c
@@ -436,59 +436,12 @@ void hnae_ae_unregister(struct hnae_ae_dev *hdev)
}
EXPORT_SYMBOL(hnae_ae_unregister);
-static ssize_t handles_show(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- ssize_t s = 0;
- struct hnae_ae_dev *hdev = cls_to_ae_dev(dev);
- struct hnae_handle *h;
- int i = 0, j;
-
- list_for_each_entry_rcu(h, &hdev->handle_list, node) {
- s += sprintf(buf + s, "handle %d (eport_id=%u from %s):\n",
- i++, h->eport_id, h->dev->name);
- for (j = 0; j < h->q_num; j++) {
- s += sprintf(buf + s, "\tqueue[%d] on %p\n",
-j, h->qs[i]->io_base);
-#define HANDEL_TX_MSG "\t\ttx_ring on %p:%u,%u,%u,%u,%u,%llu,%llu\n"
- s += sprintf(buf + s,
-HANDEL_TX_MSG,
-h->qs[i]->tx_ring.io_base,
-h->qs[i]->tx_ring.buf_size,
-h->qs[i]->tx_ring.desc_num,
-h->qs[i]->tx_ring.max_desc_num_per_pkt,
-h->qs[i]->tx_ring.max_raw_data_sz_per_desc,
-h->qs[i]->tx_ring.max_pkt_size,
-h->qs[i]->tx_ring.stats.sw_err_cnt,
-h->qs[i]->tx_ring.stats.io_err_cnt);
- s += sprintf(buf + s,
- "\t\trx_ring on %p:%u,%u,%llu,%llu,%llu\n",
- h->qs[i]->rx_ring.io_base,
- h->qs[i]->rx_ring.buf_size,
- h->qs[i]->rx_ring.desc_num,
- h->qs[i]->rx_ring.stats.sw_err_cnt,
- h->qs[i]->rx_ring.stats.io_err_cnt,
- h->qs[i]->rx_ring.stats.seg_pkt_cnt);
- }
- }
-
- return s;
-}
-
-static DEVICE_ATTR_RO(handles);
-static struct attribute *hnae_class_attrs[] = {
- &dev_attr_handles.attr,
- NULL,
-};
-ATTRIBUTE_GROUPS(hnae_class);
-
static int __init hnae_init(void)
{
hnae_class = class_create(THIS_MODULE, "hnae");
if (IS_ERR(hnae_class))
return PTR_ERR(hnae_class);
- hnae_class->dev_groups = hnae_class_groups;
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v3 2/2] net: hisilicon fix a bug on Hisilicon Network Subsystem
This patch fixes the wrong judgement of mac_id when get port num.
Signed-off-by: huangdaode
Signed-off-by: yankejian
---
drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
index f8f7347..026b386 100644
--- a/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
+++ b/drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c
@@ -179,7 +179,7 @@ static int hns_mac_get_inner_port_num(struct hns_mac_cb
*mac_cb,
return -EINVAL;
}
} else if (mac_cb->dsaf_dev->dsaf_mode < DSAF_MODE_MAX) {
- if (mac_cb->mac_id <= DSAF_MAX_PORT_NUM_PER_CHIP) {
+ if (mac_cb->mac_id >= DSAF_MAX_PORT_NUM_PER_CHIP) {
dev_err(mac_cb->dev,
"input invalid,%s mac%d vmid%d!\n",
mac_cb->dsaf_dev->ae_dev.name,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v3 0/2] net: hisilicon fix some bugs in HNS drivers
This patchset fixes the two bugs in HNS driver, one is remove the hnae sysfs interface according to the review comments from Arnd Bergmann , another is fixing the wrong mac_id judgement bug which is found during internal tests. change log: v3: remove the hnae sysfs interface. v2: 1) remove first bug fix, which is fixed in another patch submitted by Arnd Bergmann 2) change the code sytyle according to Joe. v1: initial version. huangdaode (2): net: hisilicon rm hnae sysfs interface net: hisilicon fix a bug on Hisilicon Network Subsystem drivers/net/ethernet/hisilicon/hns/hnae.c | 47 --- drivers/net/ethernet/hisilicon/hns/hns_dsaf_mac.c | 2 +- 2 files changed, 1 insertion(+), 48 deletions(-) -- 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] acpi: set return value to const char for some functions
If you don't like the quote, just stick with my first assessment. > -Original Message- > From: Joe Perches [mailto:j...@perches.com] > Sent: Thursday, October 15, 2015 5:00 PM > To: Moore, Robert > Cc: LABBE Corentin; Zheng, Lv; Wysocki, Rafael J; l...@kernel.org; linux- > a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org; Box, > David E > Subject: Re: [PATCH] acpi: set return value to const char for some > functions > > On Thu, 2015-10-15 at 19:32 +, Moore, Robert wrote: > > if you started to use "const" for some methods you usually forced to > > use this in most of your code. But the time spent for maintaining > > (typing, recompiling when some const is missing, etc.) of > > const-correctness in code seems greater than for fixing of possible > > (very rare) problems caused by not using of const-correctness at all > > c is not c++. > > "seems" is a dubious statement. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: SoCFPGA ethernet broken
> Another debugging point, the SoCFPGA board has a Micrel ksz9021 PHY attached > to the ethernet port. What I'm seeing is that with 8b63ec1837fa patch, when > the call to ksz9021_config_init() is made both of_node and > dev->parent->of_node > are NULL, without the patch the dev->parent->of_node is a valid pointer. Thus > the skew values get programmed to the phy. Ah! You have the phy device tree parameters in the wrong place. These are phy paramters, so should really be in the phy node. But socfpga_cyclone5_socdk.dts has them in the MAC node. There is nothing in Documentation/devicetree/bindings/net/micrel.txt which says you are allowed to place them in the MAC node. Obviously the code did allow this, which is what has now broken. Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: SoCFPGA ethernet broken
On Thu, 15 Oct 2015, Florian Fainelli wrote: > On 15/10/15 13:49, Dinh Nguyen wrote: > >> > >> Does this text change with and without the 8b63ec1837fa patch? > > > > No, this text does not change with/without the 8b63ec1837fa patch. > > Could you instrument mdiobus_scan(), get_phy_device() and > phy_device_create/register to see if the parent is NULL, non-NULL? > [0.800479] get_phy_device bus=0xeee26c00 addr=0004 phy_id=00221611 [0.806735] phy_device_create dev->dev.parent=0xeee26c50 [0.84] phy_device_register completed [0.814675] mdiobus_scan phydev=0xeee27000 [1.979034] ksz9021_config_init of_node= Without patch [0.801294] get_phy_device bus=0xeeef6c00 addr=0004 phy_id=00221611 [0.807551] phy_device_create dev->dev.parent=0xeed6cc10 [0.811929] phy_device_register completed [0.815510] mdiobus_scan phydev=0xeeef7000 [1.979034] ksz9021_config_init of_node=0xef203538 [1.988064] ksz9021_load_values_from_of [1.992485] ksz9021_load_values_from_of [1.996905] ksz9021_load_values_from_of BR, Dinh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/11] smack: namespace groundwork
> On czw, 2015-10-15 at 14:41 +0200, Lukasz Pawelczyk wrote:
>
> > No, not a typo. A regular bug. Thanks for spotting it. Also sync
> > mechanism before freeing was missing:
>
>
> Hitfix, will be integrated with the next respin:
>
> diff --git a/security/smack/smack.h b/security/smack/smack.h
> index 3d432f4..3a795bf 100644
> --- a/security/smack/smack.h
> +++ b/security/smack/smack.h
> @@ -97,6 +97,7 @@ struct smack_ns {
> struct smack_known_ns {
> struct list_headsmk_list_known;
> struct list_headsmk_list_ns;
> + struct rcu_head smk_rcu;
> struct user_namespace *smk_ns;
> char*smk_mapped;
> struct smack_known *smk_unmapped;
> diff --git a/security/smack/smack_lsm.c b/security/smack/smack_lsm.c
> index 8e0da67..234da71 100644
> --- a/security/smack/smack_lsm.c
> +++ b/security/smack/smack_lsm.c
> @@ -4669,6 +4669,15 @@ static inline int smack_userns_create(struct
> user_namespace *ns)
> return 0;
> }
>
> +static void smk_free_known_ns(struct rcu_head *head)
> +{
> + struct smack_known_ns *sknp = container_of(head, struct
> smack_known_ns, smk_rcu);
> +
> + if (sknp->smk_allocated)
> + kfree(sknp->smk_mapped);
> + kfree(sknp);
> +}
> +
> static inline void smack_userns_free(struct user_namespace *ns)
> {
> struct smack_ns *snsp = ns->security;
> @@ -4680,12 +4689,11 @@ static inline void smack_userns_free(struct
> user_namespace *ns)
>
> mutex_lock(&skp->smk_mapped_lock);
> list_del_rcu(&sknp->smk_list_known);
> - if (sknp->smk_allocated)
> - kfree(sknp->smk_mapped);
> - kfree(sknp);
> mutex_unlock(&skp->smk_mapped_lock);
>
> list_del(&sknp->smk_list_ns);
Is list_del safe, given the operation
+ mutex_lock(&snsp->smk_mapped_lock);
+ list_add_rcu(&sknp->smk_list_ns, &snsp->smk_mapped);
+ mutex_unlock(&snsp->smk_mapped_lock);
in smk_import_mapped() function(copied below)?
> +
> + call_rcu(&sknp->smk_rcu, smk_free_known_ns);
> }
>
> kfree(snsp);
> --
>
+static struct smack_known_ns *smk_import_mapped(struct smack_known *skp,
+ struct user_namespace *ns,
+ const char *string, int len)
+{
+ struct smack_ns *snsp = ns->security;
+ struct smack_known_ns *sknp;
+ char *mapped;
+ bool allocated;
+
+ /* Mapping init_user_ns is against the design and pointless */
+ if (ns == &init_user_ns)
+ return ERR_PTR(-EBADR);
+
+ mapped = smk_parse_smack(string, len, &allocated);
+ if (IS_ERR(mapped))
+ return ERR_CAST(mapped);
+
+ mutex_lock(&skp->smk_mapped_lock);
+
+ /*
+* Don't allow one<->many mappings in namespace, rename.
+* This code won't get triggered for now as trying to assign
+* a duplicate is forbidden in proc_label_map_write().
+* Leaving this as this function might be also used elsewhere.
+*/
+ sknp = smk_find_mapped(skp, ns);
+ if (sknp != NULL) {
+ if (sknp->smk_allocated)
+ kfree(sknp->smk_mapped);
+ sknp->smk_mapped = mapped;
+ sknp->smk_allocated = allocated;
+ goto unlockout;
+ }
+
+ sknp = kzalloc(sizeof(*sknp), GFP_KERNEL);
+ if (sknp == NULL) {
+ sknp = ERR_PTR(-ENOMEM);
+ if (allocated)
+ kfree(mapped);
+ goto unlockout;
+ }
+
+ sknp->smk_ns = ns;
+ sknp->smk_mapped = mapped;
+ sknp->smk_allocated = allocated;
+ sknp->smk_unmapped = skp;
+ list_add_rcu(&sknp->smk_list_known, &skp->smk_mapped);
+
+ mutex_lock(&snsp->smk_mapped_lock);
+ list_add_rcu(&sknp->smk_list_ns, &snsp->smk_mapped);
+ mutex_unlock(&snsp->smk_mapped_lock);
+
+unlockout:
+ mutex_unlock(&skp->smk_mapped_lock);
+
+ return sknp;
+}
>
>
> --
> Lukasz Pawelczyk
> Samsung R&D Institute Poland
> Samsung Electronics
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] block: flush queued bios when the process blocks
On Thu, Oct 15, 2015 at 4:06 PM, Mike Snitzer wrote: > On Wed, Oct 14 2015 at 11:27pm -0400, > Ming Lei wrote: > >> On Sat, Oct 10, 2015 at 3:52 AM, Mike Snitzer wrote: >> > >> > Turns out that this change: >> > http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=wip&id=2639638c77768a86216be456c2764e32a2bcd841 >> > >> > needed to be reverted with: >> > http://git.kernel.org/cgit/linux/kernel/git/snitzer/linux.git/commit/?h=wip&id=ad3ccd760da7c05b90775372f9b39dc2964086fe >> > >> > Because nested plugs caused generic_make_request()'s onstack bio_list to >> > go out of scope (blk_finish_plug() wouldn't actually flush the list >> > within generic_make_request because XFS already added an outermost >> > plug). >> >> Looks you should have defined bio_list in plug as >> >>'struct bio_list bio_list' >> >> instead of one pointer. > > I realized that and fixed it (see commit ad3ccd760da7c05b90 referenced > above that does exactly that). That wasn't the problem. OK. > >> > >> > But even after fixing that I then hit issues with these changes now >> > resulting in imperfect 'in_generic_make_request' accounting that happens >> > lazily once the outermost plug completes blk_finish_plug. manifested as >> > dm-bufio.c:dm_bufio_prefetch's BUG_ON(dm_bufio_in_request()); hitting. >> >> Looks this problem should be related with above 'bio_list' definition too. > > No, as I explained it was due to the nested plug: > >> > >> > Basically using the blk-core's onstack plugging isn't workable for >> > fixing this deadlock and we're back to having to seriously consider >> > this (with its additional hook in the scheduler) > > To elaborate, for the code in DM (and other subsystems like bcache) that > rely on accurate accounting of whether we're actively _in_ > generic_make_request: using plug to store/manage the bio_list isn't That looks an interesting requirement, which means DM just need to know if the current callsite is from generic_make_request(), so what you need is just one per-task variable. With the stack variable of 'plug', it should be easier to do that for DM, for example, you can introduce one flag in 'struct blk_plug', then set it in the entry of generic_make_request(), and clear it in the exit of the function. > workable because nested plugs change the lifetime of when the bio_list > is processed (as I implemented it -- which was to respect nested plugs). > I could've forced the issue by making the bio_list get processed > regardless of nesting but that would've made the onstack plugging much > more convoluted (duality between nested vs not just for bio_list's > benefit and for what gain? Simply to avoid an extra conditional > immediately in the scheduler? That conditional was still added anyway > but just as part of blk_needs_flush_plug so in the end there wasn't any > benefit!). > > Hopefully my middle-of-the-night reply is coherent and helped to clarify > my position that (ab)using blk_plug for the bio_list management is > _really_ awkward. ;) Hope it wan't my reply to cause the break of your sleep, :-) Thanks, Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: manual merge of the dt-rh tree with the regulator tree
Hi Rob,
Today's linux-next merge of the dt-rh tree got a conflict in:
drivers/regulator/core.c
between commit:
85f3b4311629 ("regulator: core: Remove regulator_list")
from the regulator tree and commit:
5634acd9c8e3 ("regulator: core: Probe regulators on demand")
from the dt-rh tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/regulator/core.c
index 7896ef53ff86,c2e5c2ae85c1..
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@@ -1421,9 -1341,11 +1422,10 @@@ static struct regulator_dev *regulator_
if (dev && dev->of_node) {
node = of_get_regulator(dev, supply);
if (node) {
+ of_device_probe(node);
- list_for_each_entry(r, ®ulator_list, list)
- if (r->dev.parent &&
- node == r->dev.of_node)
- return r;
+ r = of_find_regulator_by_node(node);
+ if (r)
+ return r;
*ret = -EPROBE_DEFER;
return NULL;
} else {
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ahci: qoriq: Fix a compiling warning
Thanks Tejun.
Regards,
Yuantian
> -Original Message-
> From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo
> Sent: Friday, October 16, 2015 12:04 AM
> To: Arnd Bergmann
> Cc: linux-arm-ker...@lists.infradead.org; Tang Yuantian-B29983
> ; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; hdego...@redhat.com; fengguang...@intel.com
> Subject: Re: [PATCH] ahci: qoriq: Fix a compiling warning
>
> Hello,
>
> I see. I applied the following to libata/for-4.4.
>
> Thanks.
>
> -- 8< --
> From eb351031a15c4a83b9955aadad783c6672ab8868 Mon Sep 17 00:00:00
> 2001
> From: Arnd Bergmann
> Date: Wed, 14 Oct 2015 16:46:52 +0800
> Subject: [PATCH] ahci: qoriq: Fix a compiling warning
>
> kbuild test robot reports the warnings:
> drivers/ata/ahci_qoriq.c: In function 'ahci_qoriq_hardreset':
> >> include/asm-generic/io.h:163:2: warning: 'px_is' may be used
> >> uninitialized in this function [-Wuninitialized]
> drivers/ata/ahci_qoriq.c:70:14: note: 'px_is' was declared here
> >> include/asm-generic/io.h:163:2: warning: 'px_cmd' may be used
> >> uninitialized in this function [-Wuninitialized]
> drivers/ata/ahci_qoriq.c:70:6: note: 'px_cmd' was declared here
>
> This patch fixed it by introducing a local variable.
>
> Signed-off-by: Arnd Bergmann
> Signed-off-by: Tang Yuantian
> Signed-off-by: Tejun Heo
> ---
> drivers/ata/ahci_qoriq.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/ata/ahci_qoriq.c b/drivers/ata/ahci_qoriq.c index
> e5e4988..58c1a94 100644
> --- a/drivers/ata/ahci_qoriq.c
> +++ b/drivers/ata/ahci_qoriq.c
> @@ -76,6 +76,7 @@ static int ahci_qoriq_hardreset(struct ata_link *link,
> unsigned int *class,
> struct ata_taskfile tf;
> bool online;
> int rc;
> + bool ls1021a_workaround = (qoriq_priv->type == AHCI_LS1021A);
>
> DPRINTK("ENTER\n");
>
> @@ -92,7 +93,7 @@ static int ahci_qoriq_hardreset(struct ata_link *link,
> unsigned int *class,
>* After the sequence is complete, software should restore the
>* PxCMD and PxIS with the stored values.
>*/
> - if (qoriq_priv->type == AHCI_LS1021A) {
> + if (ls1021a_workaround) {
> px_cmd = readl(port_mmio + PORT_CMD);
> px_is = readl(port_mmio + PORT_IRQ_STAT);
> }
> @@ -106,7 +107,7 @@ static int ahci_qoriq_hardreset(struct ata_link *link,
> unsigned int *class,
>ahci_check_ready);
>
> /* restore the PxCMD and PxIS on ls1021 */
> - if (qoriq_priv->type == AHCI_LS1021A) {
> + if (ls1021a_workaround) {
> px_val = readl(port_mmio + PORT_CMD);
> if (px_val != px_cmd)
> writel(px_cmd, port_mmio + PORT_CMD);
> --
> 2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] pwm-backlight: fix the panel power sequence
Hi YH,
[auto build test ERROR on pwm/for-next -- if it's inappropriate base, please
suggest rules for selecting the more suitable base]
url:
https://github.com/0day-ci/linux/commits/YH-Huang/pwm-backlight-fix-the-panel-power-sequence/20151016-093957
config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
drivers/video/backlight/pwm_bl.c: In function 'pwm_backlight_probe':
>> drivers/video/backlight/pwm_bl.c:245:20: error: too few arguments to
>> function 'devm_gpiod_get_optional'
pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
^
In file included from drivers/video/backlight/pwm_bl.c:13:0:
include/linux/gpio/consumer.h:80:32: note: declared here
struct gpio_desc *__must_check devm_gpiod_get_optional(struct device *dev,
^
vim +/devm_gpiod_get_optional +245 drivers/video/backlight/pwm_bl.c
239 pb->notify_after = data->notify_after;
240 pb->check_fb = data->check_fb;
241 pb->exit = data->exit;
242 pb->dev = &pdev->dev;
243 pb->enabled = false;
244
> 245 pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
246 if (IS_ERR(pb->enable_gpio)) {
247 ret = PTR_ERR(pb->enable_gpio);
248 goto err_alloc;
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: Binary data
Re: SoCFPGA ethernet broken
On Thu, 15 Oct 2015, Florian Fainelli wrote: > On 15/10/15 13:49, Dinh Nguyen wrote: > >> > >> Does this text change with and without the 8b63ec1837fa patch? > > > > No, this text does not change with/without the 8b63ec1837fa patch. > > Could you instrument mdiobus_scan(), get_phy_device() and > phy_device_create/register to see if the parent is NULL, non-NULL? > Yes, I can do that. > So far, I cannot see what is wrong with David's changes, quite the > contrary, and if there was something wrong with the PHY device creation, > it should not get you that far. > > You have not answered my previous question though, do you have PHY > fixups registered for that ID? By fixups, do you mean the skew values that are in the device tree? Those are the only fixups that I have the PHY. Another debugging point, the SoCFPGA board has a Micrel ksz9021 PHY attached to the ethernet port. What I'm seeing is that with 8b63ec1837fa patch, when the call to ksz9021_config_init() is made both of_node and dev->parent->of_node are NULL, without the patch the dev->parent->of_node is a valid pointer. Thus the skew values get programmed to the phy. BR, Dinh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [alsa-devel] [RFC PATCH] ASoC: Modify check condition of multiple bindings of components
On Thu, 2015-10-15 at 15:26 +0200, Lars-Peter Clausen wrote: > On 10/15/2015 02:10 PM, Mark Brown wrote: > > On Wed, Oct 14, 2015 at 11:00:01AM +0200, Lars-Peter Clausen wrote: > > > >> It was never intended that it is possible to bind a component to multiple > >> cards. That it was possible was a bug that was overlooked and some people > >> tried to do it which caused apparently random crashes later on, caused by > >> the data structure corruption. This is why we added the check to catch this > >> kind of mistake early and to avoid the crashes. > > > > This is true, but I do think it's something that we should have some > > story on supporting for some of this hardware that has a bunch of > > channels in one IP block that can't really interact with each other. > > It's going to make it a lot easier for people to think about the > > hardware and how to describe it. > > I'm not saying we shouldn't support it, just that we can't support it with > the current code. And adding support for it will require a fair bit of > restructuring. > > If a hardware block as multiple independent channels the best approach in my > opinion is to register multiple components (Which we can't do at the moment, > because there can only be one component per device). From a framework point Yes... I have tried to register 2 platforms in my ASoC platform driver but alsa considered they are the same platform since they are from the same device. > of view there is no difference between a single device with multiple > independent channels and multiple independent devices with one channel each. > Both have the same logical topology. > Yes, but in my case there is only one HW, one set of registers, and one set of clocks, it should be a single device node in the device tree. > - Lars > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] powerpc: on crash, kexec'ed kernel needs all CPUs are online
On Thu, 15 Oct 2015 21:00:58 +0200 Laurent Vivier wrote: > On kexec, all secondary offline CPUs are onlined before > starting the new kernel, this is not done in the case of kdump. > > If kdump is configured and a kernel crash occurs whereas > some secondaries CPUs are offline (SMT=off), > the new kernel is not able to start them and displays some > "Processor X is stuck.". > > Starting with POWER8, subcore logic relies on all threads of > core being booted. So, on startup kernel tries to start all > threads, and asks OPAL (or RTAS) to start all CPUs (including > threads). If a CPU has been offlined by the previous kernel, > it has not been returned to OPAL, and thus OPAL cannot restart > it: this CPU has been lost... > > Signed-off-by: Laurent Vivier Nice analysis of the problem. But, I'm a bit uneasy about this approach to fixing it: Onlining potentially hundreds of CPU threads seems like a risky operation in a kernel that's already crashed. I don't have a terribly clear idea of what is the best way to address this. Here's a few ideas in the right general direction: * I'm already looking into a kdump userspace fixes to stop it attempting to bring up secondary CPUs * A working kernel option to say "only allow this many online cpus ever" which we could pass to the kdump kernel would be nice * Paulus had an idea about offline threads returning themselves directly to OPAL by kicking a flag at kdump/kexec time. BenH, Paulus, OPAL <-> kernel cpu transitions don't seem to work quite how I thought they would. IIUC there's a register we can use to directly control which threads on a core are active. Given that I would have thought cpu "ownership" OPAL vs. kernel would be on a per-core, rather than per-thread basis. Is there some way we can change the CPU onlining / offlining code so that if threads aren't in OPAL, we directly enable them, rather than just hoping they're in a nap loop somewhere? -- David Gibson Senior Software Engineer, Virtualization, Red Hat pgpcBYjgyiSCO.pgp Description: OpenPGP digital signature
Re: [PATCH V15 00/11] x86: Intel Cache Allocation Technology Support
On Thu, Oct 15, 2015 at 01:36:14PM +0200, Peter Zijlstra wrote: > On Tue, Oct 13, 2015 at 06:31:27PM -0300, Marcelo Tosatti wrote: > > I am rewriting the interface with ioctls, with commands similar to the > > syscall interface proposed. > > Which is horrible for other use cases. I really don't see the problem > with the cgroup stuff. Can you detail what "horrible" means? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sunrpc: fix waitqueue_active without memory barrier in sunrpc
Tatsukawa Kosuke wrote:
> J. Bruce Fields wrote:
>> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote:
>>> Tatsukawa Kosuke wrote:
>>> > J. Bruce Fields wrote:
>>> >> Thanks for the detailed investigation.
>>> >>
>>> >> I think it would be worth adding a comment if that might help someone
>>> >> having to reinvestigate this again some day.
>>> >
>>> > It would be nice, but I find it difficult to write a comment in the
>>> > sunrpc layer why a memory barrier isn't necessary, using the knowledge
>>> > of how nfsd uses it, and the current implementation of the network code.
>>> >
>>> > Personally, I would prefer removing the call to waitqueue_active() which
>>> > would make the memory barrier totally unnecessary at the cost of a
>>> > spin_lock + spin_unlock by unconditionally calling
>>> > wake_up_interruptible.
>>>
>>> On second thought, the callbacks will be called frequently from the tcp
>>> code, so it wouldn't be a good idea.
>>
>> So, I was even considering documenting it like this, if it's not
>> overkill.
>>
>> Hmm... but if this is right, then we may as well ask why we're doing the
>> wakeups at all. Might be educational to test the code with them
>> removed.
>
> sk_write_space will be called in sock_wfree() with UDP/IP each time
> kfree_skb() is called. With TCP/IP, sk_write_space is only called if
> SOCK_NOSPACE has been set.
>
> sk_data_ready will be called in both tcp_rcv_established() for TCP/IP
> and in sock_queue_rcv_skb() for UDP/IP. The latter lacks a memory
> barrier with sk_data_ready called right after __skb_queue_tail().
> I think this hasn't caused any problems because sk_data_ready wasn't
> used.
Actually, svc_udp_data_ready() calls set_bit() which is an atomic
operation. So there won't be a problem unless svsk is NULL.
>> --b.
>>
>> commit 0882cfeb39e0
>> Author: J. Bruce Fields
>> Date: Thu Oct 15 16:53:41 2015 -0400
>>
>> svcrpc: document lack of some memory barriers.
>>
>> Kosuke Tatsukawa points out an odd lack of memory barriers in some sites
>> here. I think the code's correct, but it's probably worth documenting.
>>
>> Reported-by: Kosuke Tatsukawa
>>
>> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
>> index 856407fa085e..90480993ec4a 100644
>> --- a/net/sunrpc/svcsock.c
>> +++ b/net/sunrpc/svcsock.c
>> @@ -399,6 +399,25 @@ static int svc_sock_secure_port(struct svc_rqst *rqstp)
>> return svc_port_is_privileged(svc_addr(rqstp));
>> }
>>
>> +static void svc_no_smp_mb(void)
>> +{
>> +/*
>> + * Kosuke Tatsukawa points out there should normally be an
>> + * smp_mb() at the callsites of this function. (Either that or
>> + * we could just drop the waitqueue_active() checks.)
>> + *
>> + * It appears they aren't currently necessary, though, basically
>> + * because nfsd does non-blocking reads from these sockets, so
>> + * the only places we wait on this waitqueue is in sendpage and
>> + * sendmsg, which won't be waiting for wakeups on newly arrived
>> + * data.
>> + *
>> + * Maybe we should add the memory barriers anyway, but these are
>> + * hot paths so we'd need to be convinced there's no sigificant
>> + * penalty.
>> + */
>> +}
>> +
>> /*
>> * INET callback when data has been received on the socket.
>> */
>> @@ -414,7 +433,7 @@ static void svc_udp_data_ready(struct sock *sk)
>> set_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags);
>> svc_xprt_enqueue(&svsk->sk_xprt);
>> }
>> -smp_mb();
>> +svc_no_smp_mb();
>> if (wq && waitqueue_active(wq))
>> wake_up_interruptible(wq);
>> }
>> @@ -433,7 +452,7 @@ static void svc_write_space(struct sock *sk)
>> svc_xprt_enqueue(&svsk->sk_xprt);
>> }
>>
>> -smp_mb();
>> +svc_no_smp_mb();
>> if (wq && waitqueue_active(wq)) {
>> dprintk("RPC svc_write_space: someone sleeping on %p\n",
>> svsk);
>> @@ -789,7 +808,7 @@ static void svc_tcp_listen_data_ready(struct sock *sk)
>> }
>>
>> wq = sk_sleep(sk);
>> -smp_mb();
>> +svc_no_smp_mb();
>> if (wq && waitqueue_active(wq))
>> wake_up_interruptible_all(wq);
>> }
>> @@ -811,7 +830,7 @@ static void svc_tcp_state_change(struct sock *sk)
>> set_bit(XPT_CLOSE, &svsk->sk_xprt.xpt_flags);
>> svc_xprt_enqueue(&svsk->sk_xprt);
>> }
>> -smp_mb();
>> +svc_no_smp_mb();
>> if (wq && waitqueue_active(wq))
>> wake_up_interruptible_all(wq);
>> }
>> @@ -827,7 +846,7 @@ static void svc_tcp_data_ready(struct sock *sk)
>> set_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags);
>> svc_xprt_enqueue(&svsk->sk_xprt);
>> }
>> -smp_mb();
>> +svc_no_smp_mb();
>> if (wq && waitqueue_active(wq))
>> wake_up_interruptible(wq);
>> }
>> @@ -1599,7 +1618,7 @@ static void svc_sock_detach(struct svc_xprt *xprt)
>> sk->sk_write_space
Re: mmotm 2015-10-15-15-20 uploaded
Hi Andrew, On Thu, 15 Oct 2015 15:20:51 -0700 a...@linux-foundation.org wrote: > > * msgrcv-use-freezable-blocking-call.patch > linux-next.patch > linux-next-rejects.patch > * mm-page_alloc-rename-__gfp_wait-to-__gfp_reclaim-nvem-fix.patch This last one did not apply and seemed to have already been part of a previous patch ... so I dropped it. -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REPOST PATCH] ftrace: Calculate the correct dyn_ftrace number to report to the userspace
On Thu, 17 Sep 2015 00:19:42 +0800
Minfei Huang wrote:
> Now, ftrace only calculate the dyn_ftrace number in the adding
> breakpoint loop, not in adding update and finish update loop.
>
> Calculate the correct dyn_ftrace, once ftrace reports the failure message
> to the userspace.
>
Bah, your emails got lost in my Inbox. Sorry about that.
I'll make an effort to look at this first thing tomorrow.
[ Cc'ing myself to remind me ]
-- Steve
> Signed-off-by: Minfei Huang
> ---
> arch/x86/kernel/ftrace.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> index 8b7b0a5..311bcf3 100644
> --- a/arch/x86/kernel/ftrace.c
> +++ b/arch/x86/kernel/ftrace.c
> @@ -556,6 +556,7 @@ void ftrace_replace_code(int enable)
> run_sync();
>
> report = "updating code";
> + count = 0;
>
> for_ftrace_rec_iter(iter) {
> rec = ftrace_rec_iter_record(iter);
> @@ -563,11 +564,13 @@ void ftrace_replace_code(int enable)
> ret = add_update(rec, enable);
> if (ret)
> goto remove_breakpoints;
> + count++;
> }
>
> run_sync();
>
> report = "removing breakpoints";
> + count = 0;
>
> for_ftrace_rec_iter(iter) {
> rec = ftrace_rec_iter_record(iter);
> @@ -575,6 +578,7 @@ void ftrace_replace_code(int enable)
> ret = finish_update(rec, enable);
> if (ret)
> goto remove_breakpoints;
> + count++;
> }
>
> run_sync();
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the input tree
Hi Dmitry,
After merging the input tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from samples/hidraw/hid-example.c:14:0:
./usr/include/linux/input.h:17:31: fatal error: input-event-codes.h: No such
file or directory
Caused by commit
d794709c3916 ("Input: Add input-event-codes header file")
I have used the input tree from next-20151015 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] powerpc: on crash, kexec'ed kernel needs all CPUs are online
On Thu, 2015-10-15 at 21:00 +0200, Laurent Vivier wrote: > On kexec, all secondary offline CPUs are onlined before > starting the new kernel, this is not done in the case of kdump. > > If kdump is configured and a kernel crash occurs whereas > some secondaries CPUs are offline (SMT=off), > the new kernel is not able to start them and displays some > "Processor X is stuck.". Do we know why they are stuck? I really don't like this fix. The reason we're doing a kdump is because the first kernel has panicked, possibly with locks held or data structures corrupted. Calling cpu_up() then goes and tries to run a bunch of code in the crashed kernel, which increases the chance of us just wedging completely. 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] selftests/seccomp: build and pass on arm64
On 10/15/2015 05:02 PM, Kees Cook wrote: > On Thu, Oct 15, 2015 at 4:01 PM, Shuah Khan wrote: >> On 10/15/2015 05:00 PM, Shuah Khan wrote: >>> On 10/15/2015 04:07 PM, Kees Cook wrote: On Thu, Oct 15, 2015 at 1:06 PM, Shuah Khan wrote: > On 10/15/2015 12:42 PM, Kees Cook wrote: >> On Thu, Oct 15, 2015 at 7:07 AM, Shuah Khan >> wrote: >>> On 10/06/2015 01:30 PM, Kees Cook wrote: Changing arm64 syscalls is done via a specific register set, more like s390 than like arm (specific ptrace call) and x86 (part of general registers). Since (restarting) poll doesn't exist on arm64, switch to using nanosleep for testing restart_syscall. And since it looks like the syscall ABI is inconsistent on arm-compat, so we must work around it (and document it) in the test. Signed-off-by: Kees Cook --- v3: - correctly set syscall number on native arm64. v2: - switch to nanosleep from a bad mix of poll and ppoll for testing restart. --- >>> >>> Is this good to go? Failed to apply to linux-kselftest next. >>> If you can rebase and resend. I can get this into 4.4-rc1 >> >> Yes please. :) >> > > ok. Please rebase to linux-kselftest next and resend the patch. Am I looking at the right tree? linux-kselftest#next doesn't appear to have the s390 patch that was included in 4.3. >>> >>> I see what happened. Your patch is linux-next fixes and that went into >>> 4.3-rc2. I can get linux-next rebase to 4.3-rc2 and get your patch in. >>> Thanks for clearing this up. >> >> oops rebase linux-kselftest next i.e > > Okay, cool. Let me know if I need to do anything more. :) > Applied to linux-ksefltest next for 4.4-rc1 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[6]: 3.4-rc smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
> try booting upstream with "cpu_init_udelay=1".
> If it works, then it actually implicates this commit:
>
> a9bcaa02a5104ace6a9d9e4a9cd9192a9e7744d6
> ("x86/smpboot: Remove SIPI delays from cpu_up()")
>
> Unfortunately the commit message for that on is erroneous --
> "cpu_init_udelay=1" is actually a NO-OP,
> because that matches the compiled-in default.
> Indeed, any non-zero value bug 1 should work.
That does seem to work. Heh, I tried that with 1 last week.
Thanks,
Shane
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
> > By the way, I have a pending patch which expands this option like
> > this:
> >
> > apic_extnmi={ bsp | all | none }
> >
> > If apic_extnmi=all is specified, external NMIs are broadcast to
> > all CPUs. This raises the successful rate of kernel panic in the case
> > where an external NMI to CPU 0 is swallowed by other NMI handlers or
> > blocked due to hang-up in NMI context. The patch works without any
> > problems, but I'm going to drop the feature if it will cause long
> > discussion. I'd like to settle this patch set down once. At least,
> > I'm going to change this option to apic_extnmi={bsp|none} style for
> > the future expansion.
> >
> > How do you think about this?
>
> Do it right away with all three variants. They make a lot of sense to
> me.
OK. I'll do that.
Regards,
--
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option
> * Thomas Gleixner wrote:
>
> > Borislav,
> >
> > On Mon, 5 Oct 2015, Borislav Petkov wrote:
> > > On Mon, Oct 05, 2015 at 02:03:58AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > That's different from my point of view. I'm not going to pass
> > > > some data from the first kernel to the second kernel. I'm just going to
> > > > provide a configurable option for the second kernel to users.
> > >
> > > Dude, WTF?! You're adding a kernel command line which is supposed to
> > > be used *only* by the kdump kernel. But nooo, it is there in the open
> > > and visible to people. And anyone can type it in during boot. AND THAT
> > > SHOULDN'T BE POSSIBLE IN THE FIRST PLACE!
> > >
> > > This information is strictly for the kdump kernel - it shouldn't be a
> > > generic command line option. How hard it is to understand that simple
> > > fact?!
> >
> > Calm down!
> >
> > Disabling that NMI in the first kernel is not going to make the world
> > explode. We have enough command line options a user can type in, which
> > are way worse than that one. If some "expert" types nonsense on the
> > first kernel command line, then it's none of our problems, really.
> >
> > If Kawai would have marked that option as a debug feature, this
> > discussion would have probably never happened.
> >
> > Aside of that, the best way to hand in options for the kdump kernel is
> > the command line. We have an existing interface for that.
> >
> > Let's move on. Nothing to see here.
>
> So Boris kind of has a point: there are numerous problems with boot options as
> kexec parameter interface:
>
> - boot option strings are not a well defined programmatic interface:
> - failures are not obvious (they are often ignored)
> - inserting/setting parameters is awkward as well.
>
> - boot options are not an ABI, so when options have dual use with kexec it's
> easy
>to break things inadvertently: without that failure being apparent other
> than
>reintroducing obscure kexec failure modes again.
>
> - in the booted up kexec kernel it's not really obvious which options got
> set by
>kexec and which got set by the user - as there's no separation of
> namespaces.
>
> - likewise, if the user specifies an option in conflict with a kexec
> requirement
>it's not really obvious what's happening: the user setting should probably
>dominate - I'm not sure that's the case with the current kexec code.
Thanks for the detailed explanation. I can understand the disadvantages
of using boot option. So these are essential problems with boot options
rather than new boot option added for kexec'ed kernel.
> Boot options are basically a user interface.
>
> On the other hand the hack of (ab-)using boot parameters as kexec parameter
> passing is an existing, many years old practice and we cannot just stop it
> without
> offering an alternative (and better!) interface first.
>
> We could improve things by either adding a separate kexec-only parameter
> passing
> facility (like programmatic boot parameters are) - or by creating some sort of
> boot parameter alias that clearly identifies kexec parameters.
>
> So for example when introducing 'noextnmi' we'd also add a facility to add a
> 'kexec_noextnmi' alias - which clearly identifies this boot parameter as a
> kexec
> related one.
>
> Every 'kexec' inserted parameter would be prefixed by kexec_ - and then the
> separation of namespaces (and the prioritization of user vs. kexec
> requirements)
> becomes well defined as well..
>
> We should also probably print a warning if a kexec_* parameter is passed in
> that
> has no matching handler in the kexec()-ed kernel.
It would be reasonable. Or we might improve kexec command so that
it removes conflict boot options with warnings.
As I stated in another mail, I'm going to change "noextnmi" to
"apic_extnmi={bsp|all|none}", which can be used both the first and
second kernels. So, I'll add this option without "kexec_" prefix
at this point.
> I do concur that this patch is probably OK given existing practices.
Thanks!
--
Hidehiro Kawai
Hitachi, Ltd. Research & Development Group
N�r��yb�X��ǧv�^�){.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z� �w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i
Re: [PATCH RFC 0/7] Adding core support for wire-MSI bridges
On 2015/10/15 23:39, Marc Zyngier wrote: > There seems to be a new class of interrupt controller out there whose > sole purpose (apart from making everybody's life a nightmare) is to > turn wired interrupts into MSIs. > > Instead of considering that the MSIs allocated to a device are for the > direct use of that device, we can turn this set of MSIs into a irq > domain, and use that domain to build a standard irqchip on top of > that. Hi Marc, There's a working to enable Intel VMD storage device, which has the similar requirement. Basically a PCIe hierarchy is hidden behind a parent PCIe device, so we need to use the PCIe irqs on parent to de-multiple PCIe IRQs from hidden PCIe devices. Seems a chance for consolidation here. cc Keith Busch who is the author of VMD device driver. Thanks! Gerry > > This requires some (slightly ugly) surgery in both the generic MSI and > platform MSI layers, but the amount of code is actually relatively > small (about +150 LoC so far). > > On top of that, we add a dummy driver for a such a bridge, hoping that > this will give enough information to driver authors so that they can > use this new feature. An even more stupid client driver is provided to > show the interrupt stack allocation: > > dummydev dummy-dev: Probing > dummydev dummy-dev: Allocated IRQ35 > dummydev dummy-dev: Probing OK > dummydev dummy-dev: IRQ35 hwirq 5 domain msichip_domain_ops > dummydev dummy-dev: IRQ35 hwirq 0 domain msi_domain_ops > dummydev dummy-dev: IRQ35 hwirq 8192 domain its_domain_ops > dummydev dummy-dev: IRQ35 hwirq 8192 domain gic_irq_domain_ops > > While this seems to work, it is far from being perfect: > > - This is a prototype: error handling is rubbish, and there could be > better abstractions to use. > > - It relies on not declaring this bridge with IRQCHIP_DECLARE in order > to prevent the DT layer from allocating interrupts behind our back. > > - There is some probe ordering issues between the bridge and the wired > interrupt device, leading to the use of -EPROBE_DEFER. > > The last two points could be addressed directly in the OF layer, as > this is a generic device ordering issue (and people are already > working on that). > > I'd welcome any comment on that approach (though I'm going to make > myself scarse over the next two weeks). > > Marc Zyngier (7): > platform-msi: Allow MSIs to be allocated in chunks > platform-msi: Factor out allocation/free of private data > irqdomain: Make irq_domain_alloc_irqs_recursive available > genirq/msi: Make the .prepare callback reusable > genirq/msi: Add msi_domain_populate_irqs > platform-msi: Allow creation of a MSI-based stacked irq domain > irqchip: [Example] dummy wired interrupt/MSI bridge driver > > drivers/base/platform-msi.c | 185 > drivers/irqchip/Kconfig | 7 ++ > drivers/irqchip/Makefile | 1 + > drivers/irqchip/irq-msichip.c | 271 > ++ > include/linux/irqdomain.h | 3 + > include/linux/msi.h | 16 +++ > kernel/irq/irqdomain.c| 6 +- > kernel/irq/msi.c | 47 +++- > 8 files changed, 481 insertions(+), 55 deletions(-) > create mode 100644 drivers/irqchip/irq-msichip.c > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Patch v7 0/7] Consolidate ACPI PCI root common code into ACPI core
On 2015/10/16 5:49, Rafael J. Wysocki wrote: > On Thursday, October 15, 2015 03:48:29 PM Bjorn Helgaas wrote: >> On Wed, Oct 14, 2015 at 02:29:35PM +0800, Jiang Liu wrote: >>> From: Liu Jiang >>> >>> This patch set consolidates common code to support ACPI PCI root on x86 >>> and IA64 platforms into ACPI core, to reproduce duplicated code and >>> simplify maintenance. And a patch set based on previous version to support >>> ACPI based PCIe host bridge on ARM64 has been posted at: >>> https://lkml.org/lkml/2015/5/26/207 >>> >>> It's based on latest mainstream kernel. It passes Fengguang's 0day test >>> suite and has been tested on two IA64 platforms and one x86 platform. >>> >>> V6->V7: >>> 1) Improve commit message according to Bjorn's suggestion. >>> 2) Move arch specific logic(code) from ACPI core into arch code >>>according to Bjorn's review comments. >> >> Thanks for cleaning this up; I think it looks much better. >> >> As far as I'm concerned, this series is ready to go. I assume Rafael >> will merge it. > > Yes, I'm going to do that. > > Thanks a lot for your help with the review! Thanks Bjorn and Rafael for review! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sunrpc: fix waitqueue_active without memory barrier in sunrpc
J. Bruce Fields wrote:
> On Thu, Oct 15, 2015 at 11:44:20AM +, Kosuke Tatsukawa wrote:
>> Tatsukawa Kosuke wrote:
>> > J. Bruce Fields wrote:
>> >> Thanks for the detailed investigation.
>> >>
>> >> I think it would be worth adding a comment if that might help someone
>> >> having to reinvestigate this again some day.
>> >
>> > It would be nice, but I find it difficult to write a comment in the
>> > sunrpc layer why a memory barrier isn't necessary, using the knowledge
>> > of how nfsd uses it, and the current implementation of the network code.
>> >
>> > Personally, I would prefer removing the call to waitqueue_active() which
>> > would make the memory barrier totally unnecessary at the cost of a
>> > spin_lock + spin_unlock by unconditionally calling
>> > wake_up_interruptible.
>>
>> On second thought, the callbacks will be called frequently from the tcp
>> code, so it wouldn't be a good idea.
>
> So, I was even considering documenting it like this, if it's not
> overkill.
>
> Hmm... but if this is right, then we may as well ask why we're doing the
> wakeups at all. Might be educational to test the code with them
> removed.
sk_write_space will be called in sock_wfree() with UDP/IP each time
kfree_skb() is called. With TCP/IP, sk_write_space is only called if
SOCK_NOSPACE has been set.
sk_data_ready will be called in both tcp_rcv_established() for TCP/IP
and in sock_queue_rcv_skb() for UDP/IP. The latter lacks a memory
barrier with sk_data_ready called right after __skb_queue_tail().
I think this hasn't caused any problems because sk_data_ready wasn't
used.
> --b.
>
> commit 0882cfeb39e0
> Author: J. Bruce Fields
> Date: Thu Oct 15 16:53:41 2015 -0400
>
> svcrpc: document lack of some memory barriers.
>
> Kosuke Tatsukawa points out an odd lack of memory barriers in some sites
> here. I think the code's correct, but it's probably worth documenting.
>
> Reported-by: Kosuke Tatsukawa
>
> diff --git a/net/sunrpc/svcsock.c b/net/sunrpc/svcsock.c
> index 856407fa085e..90480993ec4a 100644
> --- a/net/sunrpc/svcsock.c
> +++ b/net/sunrpc/svcsock.c
> @@ -399,6 +399,25 @@ static int svc_sock_secure_port(struct svc_rqst *rqstp)
> return svc_port_is_privileged(svc_addr(rqstp));
> }
>
> +static void svc_no_smp_mb(void)
> +{
> + /*
> + * Kosuke Tatsukawa points out there should normally be an
> + * smp_mb() at the callsites of this function. (Either that or
> + * we could just drop the waitqueue_active() checks.)
> + *
> + * It appears they aren't currently necessary, though, basically
> + * because nfsd does non-blocking reads from these sockets, so
> + * the only places we wait on this waitqueue is in sendpage and
> + * sendmsg, which won't be waiting for wakeups on newly arrived
> + * data.
> + *
> + * Maybe we should add the memory barriers anyway, but these are
> + * hot paths so we'd need to be convinced there's no sigificant
> + * penalty.
> + */
> +}
> +
> /*
> * INET callback when data has been received on the socket.
> */
> @@ -414,7 +433,7 @@ static void svc_udp_data_ready(struct sock *sk)
> set_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags);
> svc_xprt_enqueue(&svsk->sk_xprt);
> }
> - smp_mb();
> + svc_no_smp_mb();
> if (wq && waitqueue_active(wq))
> wake_up_interruptible(wq);
> }
> @@ -433,7 +452,7 @@ static void svc_write_space(struct sock *sk)
> svc_xprt_enqueue(&svsk->sk_xprt);
> }
>
> - smp_mb();
> + svc_no_smp_mb();
> if (wq && waitqueue_active(wq)) {
> dprintk("RPC svc_write_space: someone sleeping on %p\n",
> svsk);
> @@ -789,7 +808,7 @@ static void svc_tcp_listen_data_ready(struct sock *sk)
> }
>
> wq = sk_sleep(sk);
> - smp_mb();
> + svc_no_smp_mb();
> if (wq && waitqueue_active(wq))
> wake_up_interruptible_all(wq);
> }
> @@ -811,7 +830,7 @@ static void svc_tcp_state_change(struct sock *sk)
> set_bit(XPT_CLOSE, &svsk->sk_xprt.xpt_flags);
> svc_xprt_enqueue(&svsk->sk_xprt);
> }
> - smp_mb();
> + svc_no_smp_mb();
> if (wq && waitqueue_active(wq))
> wake_up_interruptible_all(wq);
> }
> @@ -827,7 +846,7 @@ static void svc_tcp_data_ready(struct sock *sk)
> set_bit(XPT_DATA, &svsk->sk_xprt.xpt_flags);
> svc_xprt_enqueue(&svsk->sk_xprt);
> }
> - smp_mb();
> + svc_no_smp_mb();
> if (wq && waitqueue_active(wq))
> wake_up_interruptible(wq);
> }
> @@ -1599,7 +1618,7 @@ static void svc_sock_detach(struct svc_xprt *xprt)
> sk->sk_write_space = svsk->sk_owspace;
>
> wq = sk_sleep(sk);
> - smp_mb();
> + svc_no_smp_mb();
> if (wq && waitqueue_active(wq))
> wake_up_interruptible(wq);
> }
---
Kosuke TATSUKAWA | 3rd IT Platform Department
Re: [PATCH v2] x86/mm: warn on W+x mappings
On Thu, 2015-10-15 at 12:33 +0200, Borislav Petkov wrote: > Yeah, that's actually a good idea. Why not upstream it for the wider > audience so that people can actually start reporting b0rked UEFIs? > With > a big and nice FW_BUG splat in there... We attempted to upstream in the past but later I discovered that my implementation in particular is causing warnings due to SMP. Also, I need to implement an alternative or extension to the current efi_map_region, which have the __init qualifier. This is because mappings might happen after the __inits have been discarded. I have this work currently in my scope. Thanks and BR, Ricardo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V15 00/11] x86: Intel Cache Allocation Technology Support
On Thu, Oct 15, 2015 at 01:37:02PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 13, 2015 at 07:40:58PM -0300, Marcelo Tosatti wrote:
> > How can you fix the issue of sockets with different reserved cache
> > regions with hw in the cgroup interface?
>
> No idea what you're referring to. But IOCTLs blow.
Tejun brought up syscalls. Syscalls seem too generic.
So ioctls were chosen instead.
It is necessary to perform the following operations:
1) create cache reservation (params = size, type).
2) delete cache reservation.
3) attach cache reservation (params = cache reservation id, pid).
4) detach cache reservation (params = cache reservation id, pid).
Can it done via cgroups? If so, works for me.
A list of problems with the cgroup interface has been written,
in the thread... and we found another problem.
List of problems with cgroup interface:
1) Global IPI on CBM <---> task change does not scale.
* cbm_update_all() - Update the cache bit mask for all packages.
*/
static inline void cbm_update_all(u32 closid)
{
on_each_cpu_mask(&rdt_cpumask, cbm_cpu_update, (void *)closid,
1);
}
Consider a machine with 32 sockets.
2) Syscall interface specification is in kbytes, not
cache ways (which is what must be recorded by the OS
to allow migration of the OS between different
hardware systems).
3) Compilers are able to configure cache optimally for
given ranges of code inside applications, easily,
if desired.
4) Problem-2: The decision to allocate cache is tied to application
initialization / destruction, and application initialization is
essentially random from the POV of the system (the events which trigger
the execution of the application are not visible from the system).
Think of a server running two different servers: one database
with requests that are received with poisson distribution, average 30
requests per hour, and every request takes 1 minute.
One httpd server with nearly constant load.
Without cache reservations, database requests takes 2 minutes.
That is not acceptable for the database clients.
But with cache reservation, database requests takes 1 minute.
You want to maximize performance of httpd and database requests
What you do? You allow the database server to perform cache
reservation once a request comes in, and to undo the reservation
once the request is finished.
Its impossible to perform this with a centralized interface.
5) Modify scenario 2 above as follows: each database request
is handled by two newly created threads, and they share a certain
percentage
of data cache, and a certain percentage of code cache.
So the dispatcher thread, on arrival of request, has to:
- create data cache reservation = tcrid-A.
- create code cache reservation = tcrid-B.
- create thread-1.
- assign tcird-A and B to thread-1.
- create thread-2.
- assign tcird-A and B to thread-2.
6) Create reservations in such a way that the sum is larger than
total amount of cache, and CPU pinning (example from Karen Noel):
VM-1 on socket-1 with 80% of reservation.
VM-2 on socket-2 with 80% of reservation.
VM-1 pinned to socket-1.
VM-2 pinned to socket-2.
Cgroups interface attempts to set a cache mask globally. This is the
problem the "expand" proposal solves:
https://lkml.org/lkml/2015/7/29/682
7) Consider two sockets with different region of L3 cache
shared with HW:
— CPUID.(EAX=10H, ECX=1):EBX[31:0] reports a bit mask. Each set bit
within the length of the CBM
indicates the corresponding unit of the L3 allocation may be used by
other entities in the platform (e.g. an
integrated graphics engine or hardware units outside the processor core
and have direct access to L3).
Each cleared bit within the length of the CBM indicates the
corresponding allocation unit can be configured
to implement a priority-based allocation scheme chosen by an OS/VMM
without interference with other
hardware agents in the system. Bits outside the length of the CBM are
reserved.
You want the kernel to maintain different bitmasks in the CBM:
socket1 [range-A]
socket2 [range-B]
And the kernel will automatically switch from range A to range B
when the thread switches sockets.
-
Problems 6, 7 and 2 are fatal for us. If you can fix them in the cgroup
interface, we can use it (please understand these problems, you seem to
ignore them for some reason).
Problems 1 4 and 5 seem to come from Tejun.
Problem 3 could be a possibility.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 17/18] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked
> -Original Message-
> From: Paolo Bonzini [mailto:paolo.bonz...@gmail.com] On Behalf Of Paolo
> Bonzini
> Sent: Friday, October 16, 2015 2:13 AM
> To: David Matlack ; Wu, Feng
> Cc: alex.william...@redhat.com; Joerg Roedel ; Marcelo
> Tosatti ; eric.au...@linaro.org; kvm list
> ; io...@lists.linux-foundation.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v9 17/18] KVM: Update Posted-Interrupts Descriptor when
> vCPU is blocked
>
>
>
> On 15/10/2015 19:39, David Matlack wrote:
> > But after spending more time reading the source code this morning I
> > found that kvm_vcpu_check_block() eventually calls into
> > vmx_sync_pir_to_irr(), which copies PIR to IRR and clears ON. And then
> > apic_find_highest_irr() detects the pending posted interrupt.
>
> Right. And related to this, Feng, can you check if this is still
> necessary on kvm/queue:
>
> @@ -6518,6 +6523,20 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> kvm_vcpu_reload_apic_access_page(vcpu);
> }
>
> + /*
> + * KVM_REQ_EVENT is not set when posted interrupts are set by
> + * VT-d hardware, so we have to update RVI unconditionally.
> + */
> + if (kvm_lapic_enabled(vcpu)) {
> + /*
> + * Update architecture specific hints for APIC
> + * virtual interrupt delivery.
> + */
> + if (kvm_x86_ops->hwapic_irr_update)
> + kvm_x86_ops->hwapic_irr_update(vcpu,
> + kvm_lapic_find_highest_irr(vcpu));
> + }
> +
> if (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) {
> kvm_apic_accept_events(vcpu);
> if (vcpu->arch.mp_state == KVM_MP_STATE_INIT_RECEIVED) {
> @@ -6534,13 +6553,6 @@ static int vcpu_enter_guest(struct kvm_vcpu *vcpu)
> kvm_x86_ops->enable_irq_window(vcpu);
>
> if (kvm_lapic_enabled(vcpu)) {
> - /*
> - * Update architecture specific hints for APIC
> - * virtual interrupt delivery.
> - */
> - if (kvm_x86_ops->hwapic_irr_update)
> - kvm_x86_ops->hwapic_irr_update(vcpu,
> - kvm_lapic_find_highest_irr(vcpu));
> update_cr8_intercept(vcpu);
> kvm_lapic_sync_to_vapic(vcpu);
> }
>
I think the above code is needed, before the place where 'KVM_REQ_EVENT'
got checked in vcpu_enter_guest(), VT-d hardware can issue notification
event at any time. Consider the following scenario:
vcpu_run()
{
..
for(;;) {
point #1
vcpu_enter_guest()
}
point #2
}
For example, if we receive notification events issued by VT-d hardware at
point #1 and point#2, then enter vcpu_enter_guest() with 'KVM_REQ_EVENT'
not set, the interrupts cannot be delivered to guest during _this_ VM-Entry.
The point is that VT-d hardware can issue notification event at any time,
but it cannot set 'KVM_REQ_EVENT' like software does.
Maybe one thing we can do is only executing the following code when
vt-d pi is enabled,
+ /*
+ * KVM_REQ_EVENT is not set when posted interrupts are set by
+ * VT-d hardware, so we have to update RVI unconditionally.
+ */
+ if (kvm_lapic_enabled(vcpu)) {
+ /*
+ * Update architecture specific hints for APIC
+ * virtual interrupt delivery.
+ */
+ if (kvm_x86_ops->hwapic_irr_update)
+ kvm_x86_ops->hwapic_irr_update(vcpu,
+ kvm_lapic_find_highest_irr(vcpu));
+ }
+
And do this inside the KVM_REQ_EVENT check when VT-d PI is not enabled.
Thanks,
Feng
>
> It may be obsolete now that we have the patch from Radim to set
> KVM_REQ_EVENT
> in vmx_sync_pir_to_irr
> (http://permalink.gmane.org/gmane.linux.kernel/2057138).
>
> Thanks,
>
> Paolo
[RESEND PATCH] pwm-backlight: fix the panel power sequence
In order to match the panel power sequence, disable the enable_gpio
in the probe function. Also, reorder the code in the power_on and
power_off function to match the timing.
Signed-off-by: YH Huang
---
drivers/video/backlight/pwm_bl.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index eff379b..99eca1e 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -54,10 +54,11 @@ static void pwm_backlight_power_on(struct pwm_bl_data *pb,
int brightness)
if (err < 0)
dev_err(pb->dev, "failed to enable power supply\n");
+ pwm_enable(pb->pwm);
+
if (pb->enable_gpio)
gpiod_set_value(pb->enable_gpio, 1);
- pwm_enable(pb->pwm);
pb->enabled = true;
}
@@ -66,12 +67,12 @@ static void pwm_backlight_power_off(struct pwm_bl_data *pb)
if (!pb->enabled)
return;
- pwm_config(pb->pwm, 0, pb->period);
- pwm_disable(pb->pwm);
-
if (pb->enable_gpio)
gpiod_set_value(pb->enable_gpio, 0);
+ pwm_config(pb->pwm, 0, pb->period);
+ pwm_disable(pb->pwm);
+
regulator_disable(pb->power_supply);
pb->enabled = false;
}
@@ -241,8 +242,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->dev = &pdev->dev;
pb->enabled = false;
- pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable",
- GPIOD_OUT_HIGH);
+ pb->enable_gpio = devm_gpiod_get_optional(&pdev->dev, "enable");
if (IS_ERR(pb->enable_gpio)) {
ret = PTR_ERR(pb->enable_gpio);
goto err_alloc;
@@ -264,6 +264,9 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->enable_gpio = gpio_to_desc(data->enable_gpio);
}
+ if (pb->enable_gpio)
+ gpiod_direction_output(pb->enable_gpio, 0);
+
pb->power_supply = devm_regulator_get(&pdev->dev, "power");
if (IS_ERR(pb->power_supply)) {
ret = PTR_ERR(pb->power_supply);
--
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: linux-next: build failure after merge of the mfd tree
Hi Arnd, On Thu, 15 Oct 2015 14:28:20 +0200 Arnd Bergmann wrote: > > diff --git a/include/asm-generic/io-64-nonatomic-hi-lo.h > b/include/asm-generic/io-64-nonatomic-hi-lo.h > new file mode 100644 > index ..32b73abce1b0 > --- /dev/null > +++ b/include/asm-generic/io-64-nonatomic-hi-lo.h > @@ -0,0 +1,2 @@ > +/* XXX: delete asm-generic/io-64-nonatomic-hi-lo.h after converting new > users */ > +#include Turns out you need the same for io-64-nonatomic-lo-hi.h as well ... -- Cheers, Stephen Rothwells...@canb.auug.org.au -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] doc: dt: add documentation for Mediatek spi-nor controller
Hi Bayi,
On Tue, Oct 13, 2015 at 05:39:18PM +0800, Bayi Cheng wrote:
> Add device tree binding documentation for serial flash with
> Mediatek serial flash controller
>
> Signed-off-by: Bayi Cheng
> ---
> .../devicetree/bindings/mtd/mtk-quadspi.txt| 30
> ++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
>
> diff --git a/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> new file mode 100644
> index 000..8fff0ed
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mtd/mtk-quadspi.txt
> @@ -0,0 +1,30 @@
> +* MTD SPI nor driver for MTK MT81xx (and similar) serial flash controller
> +
> +Required properties:
> +- compatible: should be "mediatek,mt8173-nor";
> +- reg: physical base address and length of the controller's
> register
> +- clocks: the phandle of the clock needed by the nor controller
> +- clock-names: the name of the clocks
> + the clocks needed "spi" and "sf". "spi" is used for spi bus,
> + and "sf" is used for controller, these are the clocks witch
> + hardware needs to enabling nor flash and nor flash controller.
> + See
> Documentation/devicetree/bindings/clock/clock-bindings.txt for details.
> +- #address-cells: should be <1>
> +- #size-cells: should be <0>
> +
> +Example:
> +
> +nor_flash: spi@1100d000 {
> + compatible = "mediatek,mt8173-nor";
> + reg = <0 0x1100d000 0 0xe0>;
> + clocks = <&pericfg CLK_PERI_SPI>,
> + <&topckgen CLK_TOP_SPINFI_IFR_SEL>;
> + clock-names = "spi", "sf";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + flash@0 {
I see you've added the 'flash' node as I requested, but you didn't
document it above, and your driver doesn't use it.
Brian
> +
> + };
> +};
> +
> --
> 1.8.1.1.dirty
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 3/4] bpf: add support for persistent maps/progs
This work adds support for "persistent" eBPF maps/programs. The term
"persistent" is to be understood that maps/programs have a facility
that lets them survive process termination. This is desired by various
eBPF subsystem users.
Just to name one example: tc classifier/action. Whenever tc parses
the ELF object, extracts and loads maps/progs into the kernel, these
file descriptors will be out of reach after the tc instance exits.
So a subsequent tc invocation won't be able to access/relocate on this
resource, and therefore maps cannot easily be shared, f.e. between the
ingress and egress networking data path.
The current workaround is that Unix domain sockets (UDS) need to be
instrumented in order to pass the created eBPF map/program file
descriptors to a third party management daemon through UDS' socket
passing facility. This makes it a bit complicated to deploy shared
eBPF maps or programs (programs f.e. for tail calls) among various
processes.
We've been brainstorming on how we could tackle this issue and various
approches have been tried out so far:
The first idea was to implement a fuse backend that proxies bpf(2)
syscalls that create/load maps and programs, where the fuse
implementation would hold these fds internally and pass them to
things like tc via UDS socket passing. There could be various fuse
implementations tailored to a particular eBPF subsystem's needs. The
advantage is that this would shift the complexity entirely into user
space, but with a couple of drawbacks along the way. One being that
fuse needs extra library dependencies and it also doesn't resolve the
issue that an extra daemon needs to run in the background. At Linux
Plumbers 2015, we've all concluded eventually that using fuse is not
an option and an in-kernel solution is needed.
The next idea I've tried out was an extension to the bpf(2) syscall
that works roughly in a way we bind(2)/connect(2) to paths backed
by special inodes in case of UDS. This works on top of any file system
that allows to create special files, where the newly created inode
operations are similar to those of S_IFSOCK inodes. The inode would
be instrumented as a lookup key in an rhashtable backend with the
prog/map stored as value. We found that there are a couple of
disadvantages on this approach. Since the underlying implementation
of the inode can differ among file systems, we need a periodic garbage
collection for dropping the rhashtable entry and the references to
the maps/progs held with it (it could be done by piggybacking into
the rhashtable's rehashing, though). The other issue is that this
requires to add something like S_IFBPF (to clearly identify this inode
as special to eBPF), where the available space in the S_IFMT is already
severly limited and could possibly clash with future POSIX values being
allocated there. Moreover, this approach might not be flexible enough
from a functionality point of view, f.e. things like future debugging
facilities, etc could be added that really wouldn't fit into bpf(2)
syscall (however, the bpf(2) syscall strictly stays the central place
to manage eBPF things).
This eventually leads us to this patch, which implements a minimal
eBPF file system. The idea is a bit similar, but to the point that
these inodes reside at one or multiple mount points. A directory
hierarchy can be tailored to a specific application use-case from the
various subsystem users and maps/progs pinned inside it. Two new eBPF
commands (BPF_PIN_FD, BPF_NEW_FD) have been added to the syscall in
order to create one or multiple special inodes from an existing file
descriptor that points to a map/program (we call it eBPF fd pinning),
or to create a new file descriptor from an existing special inode.
BPF_PIN_FD requires CAP_SYS_ADMIN capabilities, whereas BPF_NEW_FD
can also be done unpriviledged when having appropriate permissions
to the path.
The next step I'm working on is to add dump eBPF map/prog commands
to bpf(2), so that a specification from a given file descriptor can
be retrieved. This can be used by things like CRIU but also applications
can inspect the meta data after calling BPF_NEW_FD.
Signed-off-by: Daniel Borkmann
Signed-off-by: Alexei Starovoitov
---
include/linux/bpf.h| 21 ++
include/uapi/linux/bpf.h | 45 +---
include/uapi/linux/magic.h | 1 +
include/uapi/linux/xattr.h | 3 +
kernel/bpf/Makefile| 4 +-
kernel/bpf/inode.c | 614 +
kernel/bpf/syscall.c | 108
7 files changed, 758 insertions(+), 38 deletions(-)
create mode 100644 kernel/bpf/inode.c
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index 0ae6f77..bb82764 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -8,8 +8,10 @@
#define _LINUX_BPF_H 1
#include
+
#include
#include
+#include
struct bpf_map;
@@ -137,6 +139,17 @@ struct bpf_prog_aux {
};
};
+enum bpf_fd_type {
+ BPF_FD_TYPE_PROG,
+ BPF_FD_TYPE_MAP,
+};
+
+uni
[PATCH net-next 4/4] bpf: add sample usages for persistent maps/progs
This patch adds a couple of stand-alone examples on how BPF_PIN_FD
and BPF_NEW_FD commands can be used.
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
---
samples/bpf/Makefile | 2 +
samples/bpf/fds_example.c | 224 ++
samples/bpf/libbpf.c | 20 +
samples/bpf/libbpf.h | 3 +
4 files changed, 249 insertions(+)
create mode 100644 samples/bpf/fds_example.c
diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 63e7d50..f08a3cf 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -4,6 +4,7 @@ obj- := dummy.o
# List of programs to build
hostprogs-y := test_verifier test_maps
hostprogs-y += sock_example
+hostprogs-y += fds_example
hostprogs-y += sockex1
hostprogs-y += sockex2
hostprogs-y += sockex3
@@ -18,6 +19,7 @@ hostprogs-y += lathist
test_verifier-objs := test_verifier.o libbpf.o
test_maps-objs := test_maps.o libbpf.o
sock_example-objs := sock_example.o libbpf.o
+fds_example-objs := fds_example.o libbpf.o
sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
sockex3-objs := bpf_load.o libbpf.o sockex3_user.o
diff --git a/samples/bpf/fds_example.c b/samples/bpf/fds_example.c
new file mode 100644
index 000..6f912be
--- /dev/null
+++ b/samples/bpf/fds_example.c
@@ -0,0 +1,224 @@
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include
+#include
+
+#include "libbpf.h"
+
+static char *fname;
+
+static void test_bpf_pin_fd(int fd)
+{
+ char buff[64];
+ int ret;
+
+ memset(buff, 0, sizeof(buff));
+ ret = bpf_pin_fd(fd, fname);
+ getxattr(fname, "bpf.type", buff, sizeof(buff));
+
+ printf("fd:%d type:%s pinned (%s)\n", fd, buff, strerror(errno));
+ assert(ret == 0);
+}
+
+static int test_bpf_new_fd(void)
+{
+ char buff[64];
+ int fd;
+
+ memset(buff, 0, sizeof(buff));
+ getxattr(fname, "bpf.type", buff, sizeof(buff));
+ fd = bpf_new_fd(fname);
+
+ printf("fd:%d type:%s fetched (%s)\n", fd, buff, strerror(errno));
+ assert(fd > 0);
+
+ return fd;
+}
+
+static int test_bpf_map_create(void)
+{
+ int fd;
+
+ fd = bpf_create_map(BPF_MAP_TYPE_ARRAY, sizeof(uint32_t),
+ sizeof(uint32_t), 1024);
+
+ printf("fd:%d created (%s)\n", fd, strerror(errno));
+ assert(fd > 0);
+
+ return fd;
+}
+
+static int test_bpf_map_insert(int fd, uint32_t val)
+{
+ uint32_t key = 123;
+ int ret;
+
+ ret = bpf_update_elem(fd, &key, &val, 0);
+
+ printf("fd:%d wrote (%u, %u)\n", fd, key, val);
+ assert(ret == 0);
+
+ return ret;
+}
+
+static int test_bpf_map_lookup(int fd)
+{
+ uint32_t key = 123, val;
+ int ret;
+
+ ret = bpf_lookup_elem(fd, &key, &val);
+
+ printf("fd:%d read (%u, %u)\n", fd, key, val);
+ assert(ret == 0);
+
+ return ret;
+}
+
+static int bpf_map_test_case_1(void)
+{
+ int fd;
+
+ fd = test_bpf_map_create();
+ test_bpf_pin_fd(fd);
+ test_bpf_map_insert(fd, 456);
+ test_bpf_map_lookup(fd);
+ close(fd);
+
+ return 0;
+}
+
+static int bpf_map_test_case_2(void)
+{
+ int fd;
+
+ fd = test_bpf_new_fd();
+ test_bpf_map_lookup(fd);
+ close(fd);
+
+ return 0;
+}
+
+static int bpf_map_test_case_3(void)
+{
+ int fd1, fd2;
+
+ unlink(fname);
+ fd1 = test_bpf_map_create();
+ test_bpf_pin_fd(fd1);
+ fd2 = test_bpf_new_fd();
+ test_bpf_map_lookup(fd1);
+ test_bpf_map_insert(fd2, 456);
+ test_bpf_map_lookup(fd1);
+ test_bpf_map_lookup(fd2);
+ test_bpf_map_insert(fd1, 789);
+ test_bpf_map_lookup(fd2);
+ close(fd1);
+ close(fd2);
+
+ return 0;
+}
+
+static int test_bpf_prog_create(void)
+{
+ struct bpf_insn insns[] = {
+ BPF_MOV64_IMM(BPF_REG_0, 1),
+ BPF_EXIT_INSN(),
+ };
+ int ret;
+
+ ret = bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER, insns,
+ sizeof(insns), "GPL", 0);
+
+ assert(ret > 0);
+ printf("fd:%d created\n", ret);
+
+ return ret;
+}
+
+static int test_bpf_prog_attach(int fd)
+{
+ int sock, ret;
+
+ sock = open_raw_sock("lo");
+ ret = setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, &fd, sizeof(fd));
+
+ printf("sock:%d got fd:%d attached\n", sock, fd);
+ assert(ret == 0);
+
+ return ret;
+}
+
+static int bpf_prog_test_case_1(void)
+{
+ int fd;
+
+ fd = test_bpf_prog_create();
+ test_bpf_pin_fd(fd);
+ close(fd);
+
+ return 0;
+}
+
+static int bpf_prog_test_case_2(void)
+{
+ int fd;
+
+ fd = test_bpf_new_fd();
+ test_bpf_prog_attach(fd);
+ close(fd);
+
+ return 0;
+}
+
+static int bpf_prog_test_case_3(void)
+{
+ int fd1,
[PATCH net-next 0/4] BPF updates
This set adds support for persistent maps/progs. Please see
individual patches for further details.
A man-page update to bpf(2) will be sent afterwards, also a
iproute2 patch for support in tc.
Thanks!
Daniel Borkmann (4):
bpf: abstract anon_inode_getfd invocations
bpf: align and clean bpf_{map,prog}_get helpers
bpf: add support for persistent maps/progs
bpf: add sample usages for persistent maps/progs
include/linux/bpf.h| 23 +-
include/uapi/linux/bpf.h | 45 +---
include/uapi/linux/magic.h | 1 +
include/uapi/linux/xattr.h | 3 +
kernel/bpf/Makefile| 4 +-
kernel/bpf/inode.c | 614 +
kernel/bpf/syscall.c | 164 ++--
kernel/bpf/verifier.c | 3 +-
samples/bpf/Makefile | 2 +
samples/bpf/fds_example.c | 224 +
samples/bpf/libbpf.c | 20 ++
samples/bpf/libbpf.h | 3 +
12 files changed, 1045 insertions(+), 61 deletions(-)
create mode 100644 kernel/bpf/inode.c
create mode 100644 samples/bpf/fds_example.c
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next 2/4] bpf: align and clean bpf_{map,prog}_get helpers
Add a bpf_map_get() function that we're going to use later on and
align/clean the remaining helpers a bit so that we have them a bit
more consistent:
- __bpf_map_get() and __bpf_prog_get() that both work on the fd
struct, check whether the descriptor is eBPF and return the
pointer to the map/prog stored in the private data.
Also, we can return f.file->private_data directly, the function
signature is enough of a documentation already.
- bpf_map_get() and bpf_prog_get() that both work on u32 user fd,
call their respective __bpf_map_get()/__bpf_prog_get() variants,
and take a reference.
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
---
include/linux/bpf.h | 2 +-
kernel/bpf/syscall.c | 41 +++--
kernel/bpf/verifier.c | 3 +--
3 files changed, 25 insertions(+), 21 deletions(-)
diff --git a/include/linux/bpf.h b/include/linux/bpf.h
index e3a51b7..0ae6f77 100644
--- a/include/linux/bpf.h
+++ b/include/linux/bpf.h
@@ -167,7 +167,7 @@ struct bpf_prog *bpf_prog_get(u32 ufd);
void bpf_prog_put(struct bpf_prog *prog);
void bpf_prog_put_rcu(struct bpf_prog *prog);
-struct bpf_map *bpf_map_get(struct fd f);
+struct bpf_map *__bpf_map_get(struct fd f);
void bpf_map_put(struct bpf_map *map);
extern int sysctl_unprivileged_bpf_disabled;
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 2b89ef0..3fff82c 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -162,19 +162,29 @@ free_map:
/* if error is returned, fd is released.
* On success caller should complete fd access with matching fdput()
*/
-struct bpf_map *bpf_map_get(struct fd f)
+struct bpf_map *__bpf_map_get(struct fd f)
{
- struct bpf_map *map;
-
if (!f.file)
return ERR_PTR(-EBADF);
-
if (f.file->f_op != &bpf_map_fops) {
fdput(f);
return ERR_PTR(-EINVAL);
}
- map = f.file->private_data;
+ return f.file->private_data;
+}
+
+static struct bpf_map *bpf_map_get(u32 ufd)
+{
+ struct fd f = fdget(ufd);
+ struct bpf_map *map;
+
+ map = __bpf_map_get(f);
+ if (IS_ERR(map))
+ return map;
+
+ atomic_inc(&map->refcnt);
+ fdput(f);
return map;
}
@@ -202,7 +212,7 @@ static int map_lookup_elem(union bpf_attr *attr)
return -EINVAL;
f = fdget(ufd);
- map = bpf_map_get(f);
+ map = __bpf_map_get(f);
if (IS_ERR(map))
return PTR_ERR(map);
@@ -261,7 +271,7 @@ static int map_update_elem(union bpf_attr *attr)
return -EINVAL;
f = fdget(ufd);
- map = bpf_map_get(f);
+ map = __bpf_map_get(f);
if (IS_ERR(map))
return PTR_ERR(map);
@@ -314,7 +324,7 @@ static int map_delete_elem(union bpf_attr *attr)
return -EINVAL;
f = fdget(ufd);
- map = bpf_map_get(f);
+ map = __bpf_map_get(f);
if (IS_ERR(map))
return PTR_ERR(map);
@@ -355,7 +365,7 @@ static int map_get_next_key(union bpf_attr *attr)
return -EINVAL;
f = fdget(ufd);
- map = bpf_map_get(f);
+ map = __bpf_map_get(f);
if (IS_ERR(map))
return PTR_ERR(map);
@@ -549,21 +559,16 @@ static int bpf_prog_new_fd(struct bpf_prog *prog)
O_RDWR | O_CLOEXEC);
}
-static struct bpf_prog *get_prog(struct fd f)
+static struct bpf_prog *__bpf_prog_get(struct fd f)
{
- struct bpf_prog *prog;
-
if (!f.file)
return ERR_PTR(-EBADF);
-
if (f.file->f_op != &bpf_prog_fops) {
fdput(f);
return ERR_PTR(-EINVAL);
}
- prog = f.file->private_data;
-
- return prog;
+ return f.file->private_data;
}
/* called by sockets/tracing/seccomp before attaching program to an event
@@ -574,13 +579,13 @@ struct bpf_prog *bpf_prog_get(u32 ufd)
struct fd f = fdget(ufd);
struct bpf_prog *prog;
- prog = get_prog(f);
-
+ prog = __bpf_prog_get(f);
if (IS_ERR(prog))
return prog;
atomic_inc(&prog->aux->refcnt);
fdput(f);
+
return prog;
}
EXPORT_SYMBOL_GPL(bpf_prog_get);
diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
index 1d6b97b..735999a 100644
--- a/kernel/bpf/verifier.c
+++ b/kernel/bpf/verifier.c
@@ -1988,8 +1988,7 @@ static int replace_map_fd_with_map_ptr(struct
verifier_env *env)
}
f = fdget(insn->imm);
-
- map = bpf_map_get(f);
+ map = __bpf_map_get(f);
if (IS_ERR(map)) {
verbose("fd %d is not pointing to valid
bpf_map\n",
insn->imm);
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
[PATCH net-next 1/4] bpf: abstract anon_inode_getfd invocations
Since we're going to use anon_inode_getfd() invocations in more than just
the current places, make a helper function for both, so that we only need
to pass a map/prog pointer to the helper itself in order to get a fd. The
new helpers are called bpf_map_new_fd() and bpf_prog_new_fd().
Signed-off-by: Daniel Borkmann
Acked-by: Alexei Starovoitov
---
kernel/bpf/syscall.c | 17 ++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
index 687dd6c..2b89ef0 100644
--- a/kernel/bpf/syscall.c
+++ b/kernel/bpf/syscall.c
@@ -111,6 +111,12 @@ static const struct file_operations bpf_map_fops = {
.release = bpf_map_release,
};
+static int bpf_map_new_fd(struct bpf_map *map)
+{
+ return anon_inode_getfd("bpf-map", &bpf_map_fops, map,
+ O_RDWR | O_CLOEXEC);
+}
+
/* helper macro to check that unused fields 'union bpf_attr' are zero */
#define CHECK_ATTR(CMD) \
memchr_inv((void *) &attr->CMD##_LAST_FIELD + \
@@ -141,8 +147,7 @@ static int map_create(union bpf_attr *attr)
if (err)
goto free_map;
- err = anon_inode_getfd("bpf-map", &bpf_map_fops, map, O_RDWR |
O_CLOEXEC);
-
+ err = bpf_map_new_fd(map);
if (err < 0)
/* failed to allocate fd */
goto free_map;
@@ -538,6 +543,12 @@ static const struct file_operations bpf_prog_fops = {
.release = bpf_prog_release,
};
+static int bpf_prog_new_fd(struct bpf_prog *prog)
+{
+ return anon_inode_getfd("bpf-prog", &bpf_prog_fops, prog,
+ O_RDWR | O_CLOEXEC);
+}
+
static struct bpf_prog *get_prog(struct fd f)
{
struct bpf_prog *prog;
@@ -647,7 +658,7 @@ static int bpf_prog_load(union bpf_attr *attr)
if (err < 0)
goto free_used_maps;
- err = anon_inode_getfd("bpf-prog", &bpf_prog_fops, prog, O_RDWR |
O_CLOEXEC);
+ err = bpf_prog_new_fd(prog);
if (err < 0)
/* failed to allocate fd */
goto free_used_maps;
--
1.9.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
