Re: [PATCH 4.1 000/102] 4.1.8-stable review
Hi Guenter,
On Sat, Sep 19, 2015 at 05:25:59PM -0700, Guenter Roeck wrote:
> On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote:
> >This is the start of the stable review cycle for the 4.1.8 release.
> >There are 102 patches in this series, all will be posted as a response
> >to this one. If anyone has any issues with these being applied, please
> >let me know.
> >
> >Responses should be made by Mon Sep 21 17:15:55 UTC 2015.
> >Anything received after that time might be too late.
> >
>
> Build results:
> total: 137 pass: 136 fail: 1
> Failed builds:
> arm:allmodconfig
> Qemu test results:
> total: 93 pass: 83 fail: 10
> Failed tests:
> arm:beagle:multi_v7_defconfig:omap3-beagle
> arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm
> arm:overo:multi_v7_defconfig:omap3-overo-tobi
> arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702
> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706
> arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed
> arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310
> mips:fuloong2e_defconfig
>
> The new failures are all caused by a single new build failure.
>
> arch/arm/mach-rockchip/platsmp.c: In function 'rockchip_boot_secondary':
> arch/arm/mach-rockchip/platsmp.c:155:3: error:
> 'rockchip_secondary_startup' undeclared
>
> Caused by 'ARM: rockchip: fix the CPU soft reset'.
It looks like this patch needs to be backported as well :
commit cb8cc37f4d38d96552f2c52deb15e511cdacf906
Author: Caesar Wang
Date: Mon Jul 6 11:37:23 2015 +0800
ARM: rockchip: fix broken build
The following was seen in branch[0] build.
arch/arm/mach-rockchip/platsmp.c:154:23: error:
'rockchip_secondary_startup' undeclared (first use in this function)
branch[0]:
git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git
v4.3-armsoc/soc
The broken build is caused by the commit fe4407c0dc58
("ARM: rockchip: fix the CPU soft reset").
Signed-off-by: Caesar Wang
The breakage was a result of it being wrongly merged in my branch with
the cache invalidation rework from Russell 02b4e2756e01c
("ARM: v7 setup function should invalidate L1 cache").
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 0/6] block: loop: improve loop with AIO
On 09/17/2015 04:31 PM, Ming Lei wrote: On Tue, Aug 18, 2015 at 3:19 AM, Christoph Hellwig wrote: Thanks Ming, this series looks fine to me: Reviewed-by: Christoph Hellwig Jens, are you OK with this patchset? Yes, I think it looks good now. I have queued it up for 4.4. Thanks Ming. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP
On Sun, 20 Sep 2015, Herbert Xu wrote: > On Sat, Sep 19, 2015 at 10:21:45AM +0100, Lee Jones wrote: > > > > That's not how it works. It's helpful, more often than not, to submit > > the entire set to each maintainer concerned so they can keep up with > > the general conversation. By only sending specific patches to > > maintainers you essentially blinker them to the bigger picture. > > > > As a maintainer you should _know_ that you can't apply patches from > > other subsystems without appropriate Acks. I'm sure you'd take > > exception to another maintainer who started accepting patches for > > subsystems you are responsible for. This works both ways. > > No you are mistaken. You should only put patches which have > dependencies on each other in a series. If the patches can be > applied independently of each other there is no need to have > them in a single series. That's just not true. I've explained why it's important for everyone involved to see the bigger picture. Let me use this set in an example. The patches can (and should) be applied separately, but they are heavily entwined. Let's say I only sent the ARM patch to Maxime (the STi Maintainer) and only sent you the driver and the binding document. There's a chance Maxime could apply the DTS changes prior to a proper review of the bindings. Granted, one way round this would be to place the DTS changes into a holding-pen until the binding has been accepted, but this method is highly impractical and puts unnecessary burden on the contributor. There are 1000's of examples where all parties need to see reviews on other, related but not dependant, parts of a set. For many of the sets I review it's critical for me what else is going on in related diffs. I guess for the subsystems you maintain it's less of an issue, but still, it _is_ how people tend to submit code and there is no good reason for you to dictate otherwise. > Obviously if they can go into different trees then they cannot > have dependencies. > > Cheers, -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 3/3] mfd: add CSR SiRFSoC on-chip power management module driver
On Thu, 17 Sep 2015, Barry Song wrote:
> From: Guo Zeng
>
> CSR SiRFSoC Power Control Module includes power on or power
> off for sysctl power and gnss, it also includes onkey, RTC
> domain clock controllers and interrupt controller for power
> events.
There are lots of Three (and four) Letter Abbreviations (TLAs) here,
which mean nothing to the average reader. Please break them out in
the commit log as I have done i.e. "Long Abbreviated Word (LAW)", so
us normies can see what they mean.
> Signed-off-by: Guo Zeng
> Signed-off-by: Barry Song
> ---
> .../devicetree/bindings/mfd/sirf-pwrc.txt | 37
This should be in a separate patch.
> drivers/mfd/Kconfig| 12 ++
> drivers/mfd/Makefile | 2 +
> drivers/mfd/sirfsoc_pwrc.c | 238
> +
> include/linux/mfd/sirfsoc_pwrc.h | 97 +
> 5 files changed, 386 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
> create mode 100644 drivers/mfd/sirfsoc_pwrc.c
> create mode 100644 include/linux/mfd/sirfsoc_pwrc.h
>
> diff --git a/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
> b/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
> new file mode 100644
> index 000..b919cdd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sirf-pwrc.txt
> @@ -0,0 +1,37 @@
> +SiRFSoC Power Controller (PWRC) module
> +
> +Power Controller is used to control the whole SoC power process.
> +The power controller controls the process of Power-On sequence,
s/power controller/Power Controller/
> +Power-Off sequence, different power modes switching and power
> +status configuration. the pwrc is access by io bridge, so the
s/the pwrc/The PWRC/
s/access/accessed/
s/io/IO/
> +node's parent should be io bridge.
s/io/IO/
Not quite sure what an IO bridge is though.
> +Required properties:
> +- compatible: "sirf,prima2-pwrc", or "sirf,atlas7-pwrc"
> +- reg: Address range of pwrc register set
Address start and size.
> +- sysctl:mfd cell device of pwrc
> +- rtcm-clk:mfd cell device of pwrc
> +- onkey:mfd cell device of pwrc
MFD is a Linuxisum. Please find another way to document them.
I always find documentation easier to read then it's tabbed out
nicely. Like:
Required properties:
- compatible: "sirf,prima2-pwrc", or "sirf,atlas7-pwrc"
- reg : Address range of pwrc register set
- sysctl: mfd cell device of pwrc
- rtcm-clk : mfd cell device of pwrc
- onkey : mfd cell device of pwrc
> +Example:
> +
> +pwrc@3000 {
> + compatible = "sirf,atlas7-pwrc";
> + reg = <0x3000 0x100>;
This doesn't look like a real address. It looks like an offset.
Please provide a full example, complete with the parent node (which I
assume has ranges set-up).
> + sysctl {
> + compatible = "sirf,sirf-sysctl";
> + };
> +
> + rtcm-clk {
> + compatible = "sirf,atlas7-rtcmclk";
> + };
> +
> + onkey {
> + compatible = "sirf,prima2-onkey";
> + };
Why do these require their own cells?
Do they have their own properties? If so, where are they documented?
> +};
> +
> +pwrc@3000 {
> + compatible = "sirf,prima2-pwrc";
> + reg = <0x3000 0x100>;
> +};
> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
> index 99d6367..5b67bee 100644
> --- a/drivers/mfd/Kconfig
> +++ b/drivers/mfd/Kconfig
> @@ -1515,5 +1515,17 @@ config MFD_VEXPRESS_SYSREG
> System Registers are the platform configuration block
> on the ARM Ltd. Versatile Express board.
>
> +config MFD_SIRFSOC_PWRC
> +bool "CSR SiRFSoC on-chip Power Control Module"
> + depends on ARCH_SIRF
> + default y
> +select MFD_CORE
> +select REGMAP_IRQ
> +help
> + CSR SiRFSoC Power Control Module includes power on or power
> + off for sysctl power and gnss, it also includes onkey, RTC
> + domain clock controllers and interrupt controller for power
> + events.
Break out the TLAs.
Your tabbing is all over the place here. Please match existing
entries.
> endmenu
> endif
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index a59e3fc..255fb80 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -192,3 +192,5 @@ obj-$(CONFIG_MFD_SKY81452)+= sky81452.o
> intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
> obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> +
> +obj-$(CONFIG_MFD_SIRFSOC_PWRC) += sirfsoc_pwrc.o
> diff --git a/drivers/mfd/sirfsoc_pwrc.c b/drivers/mfd/sirfsoc_pwrc.c
> new file mode 100644
> index 000..b43f8b4
> --- /dev/null
> +++ b/drivers/mfd/sirfsoc_pwrc.c
> @@ -0,0 +1,238 @@
> +/*
> + * power management mfd for CSR SiRFSoC chips
"Power Management MFD for CSR SiRFSoC chips"
> + * Copyright (c) 2014 Cambridge Silicon Radio Limited, a CSR
Re: [PATCH 3/9] mfd: arizona: Add TST_CAP bits for headphone detection
On Wed, 16 Sep 2015, Charles Keepax wrote: > On wm5110/8280 some additional settings are required to get accurate > measurements at the top end of the headphone detection range. This patch > adds the bits required for this. > > Signed-off-by: Charles Keepax > --- > drivers/mfd/wm5110-tables.c |2 ++ > include/linux/mfd/arizona/registers.h |8 > 2 files changed, 10 insertions(+), 0 deletions(-) Acked-by: Lee Jones > diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c > index aae17d6..28f2ae3 100644 > --- a/drivers/mfd/wm5110-tables.c > +++ b/drivers/mfd/wm5110-tables.c > @@ -1912,6 +1912,7 @@ static bool wm5110_readable_register(struct device > *dev, unsigned int reg) > case ARIZONA_HP1_SHORT_CIRCUIT_CTRL: > case ARIZONA_HP2_SHORT_CIRCUIT_CTRL: > case ARIZONA_HP3_SHORT_CIRCUIT_CTRL: > + case ARIZONA_HP_TEST_CTRL_1: > case ARIZONA_AIF1_BCLK_CTRL: > case ARIZONA_AIF1_TX_PIN_CTRL: > case ARIZONA_AIF1_RX_PIN_CTRL: > @@ -2857,6 +2858,7 @@ static bool wm5110_volatile_register(struct device > *dev, unsigned int reg) > case ARIZONA_INPUT_ENABLES_STATUS: > case ARIZONA_OUTPUT_STATUS_1: > case ARIZONA_RAW_OUTPUT_STATUS_1: > + case ARIZONA_HP_TEST_CTRL_1: > case ARIZONA_SLIMBUS_RX_PORT_STATUS: > case ARIZONA_SLIMBUS_TX_PORT_STATUS: > case ARIZONA_INTERRUPT_STATUS_1: > diff --git a/include/linux/mfd/arizona/registers.h > b/include/linux/mfd/arizona/registers.h > index ab219c9..c7c11c9 100644 > --- a/include/linux/mfd/arizona/registers.h > +++ b/include/linux/mfd/arizona/registers.h > @@ -242,6 +242,7 @@ > #define ARIZONA_HP1_SHORT_CIRCUIT_CTRL 0x4A0 > #define ARIZONA_HP2_SHORT_CIRCUIT_CTRL 0x4A1 > #define ARIZONA_HP3_SHORT_CIRCUIT_CTRL 0x4A2 > +#define ARIZONA_HP_TEST_CTRL_1 0x4A4 > #define ARIZONA_SPK_CTRL_2 0x4B5 > #define ARIZONA_SPK_CTRL_3 0x4B6 > #define ARIZONA_DAC_COMP_1 0x4DC > @@ -3702,6 +3703,13 @@ > #define ARIZONA_HP3_SC_ENA_WIDTH 1 /* HP3_SC_ENA */ > > /* > + * R1188 (0x4A4) HP Test Ctrl 1 > + */ > +#define ARIZONA_HP1_TST_CAP_SEL_MASK 0x0003 /* HP1_TST_CAP_SEL > - [1:0] */ > +#define ARIZONA_HP1_TST_CAP_SEL_SHIFT 0 /* HP1_TST_CAP_SEL > - [1:0] */ > +#define ARIZONA_HP1_TST_CAP_SEL_WIDTH 2 /* HP1_TST_CAP_SEL > - [1:0] */ > + > +/* > * R1244 (0x4DC) - DAC comp 1 > */ > #define ARIZONA_OUT_COMP_COEFF_MASK 0x /* OUT_COMP_COEFF - > [15:0] */ -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mfd: rt5033: Remove unnecessary MODULE_ALIAS()
On Mon, 31 Aug 2015, Javier Martinez Canillas wrote:
> The driver has a I2C device id table that is used to create the module
> aliases which already contains a "rt5033". So the alias is not needed.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> drivers/mfd/rt5033.c | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/rt5033.c b/drivers/mfd/rt5033.c
> index d60f91619c4a..110de2a583af 100644
> --- a/drivers/mfd/rt5033.c
> +++ b/drivers/mfd/rt5033.c
> @@ -137,7 +137,6 @@ static struct i2c_driver rt5033_driver = {
> };
> module_i2c_driver(rt5033_driver);
>
> -MODULE_ALIAS("i2c:rt5033");
> MODULE_DESCRIPTION("Richtek RT5033 multi-function core driver");
> MODULE_AUTHOR("Beomho Seo ");
> MODULE_LICENSE("GPL");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: tps6105x: Fix NULL pointer access.
On Fri, 04 Sep 2015, Grigoryev Denis wrote:
> When tps6105x used in TPS6105X_MODE_SHUTDOWN mode the driver calls
> mfd_add_devices() with mfd_cell->name == NULL, that causes an ooops in
> platform_device_register() later.
>
> This patch reorders mfd_cell structures and makes code to call
> mfd_add_devices() with proper number of cells.
>
> Signed-off-by: Denis Grigoryev
> ---
> drivers/mfd/tps6105x.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mfd/tps6105x.c b/drivers/mfd/tps6105x.c
> index 5de95c2..be2c286 100644
> --- a/drivers/mfd/tps6105x.c
> +++ b/drivers/mfd/tps6105x.c
> @@ -124,11 +124,11 @@ static int tps6105x_startup(struct tps6105x *tps6105x)
> */
> static struct mfd_cell tps6105x_cells[] = {
> {
> - /* name will be runtime assigned */
> + .name = "tps6105x-gpio",
> .id = -1,
> },
> {
> - .name = "tps6105x-gpio",
> + /* name will be runtime assigned */
> .id = -1,
> },
> };
So you have 2 cells with identical .name's and identical .id's.
How does that work?
> @@ -138,6 +138,7 @@ static int tps6105x_probe(struct i2c_client *client,
> {
> struct tps6105x *tps6105x;
> struct tps6105x_platform_data *pdata;
> + int n_cells = ARRAY_SIZE(tps6105x_cells);
> int ret;
> int i;
>
> @@ -162,33 +163,34 @@ static int tps6105x_probe(struct i2c_client *client,
> case TPS6105X_MODE_SHUTDOWN:
> dev_info(>dev,
>"present, not used for anything, only GPIO\n");
> + n_cells = 1;
> break;
> case TPS6105X_MODE_TORCH:
> - tps6105x_cells[0].name = "tps6105x-leds";
> + tps6105x_cells[1].name = "tps6105x-leds";
Now you're over-writing cell names! I'd say this was a hack.
Please just create an entry for each device, like usual.
> dev_warn(>dev,
>"torch mode is unsupported\n");
> break;
> case TPS6105X_MODE_TORCH_FLASH:
> - tps6105x_cells[0].name = "tps6105x-flash";
> + tps6105x_cells[1].name = "tps6105x-flash";
> dev_warn(>dev,
>"flash mode is unsupported\n");
> break;
> case TPS6105X_MODE_VOLTAGE:
> - tps6105x_cells[0].name ="tps6105x-regulator";
> + tps6105x_cells[1].name = "tps6105x-regulator";
> break;
> default:
> break;
> }
>
> /* Set up and register the platform devices. */
> - for (i = 0; i < ARRAY_SIZE(tps6105x_cells); i++) {
> + for (i = 0; i < n_cells; i++) {
> /* One state holder for all drivers, this is simple */
> tps6105x_cells[i].platform_data = tps6105x;
> tps6105x_cells[i].pdata_size = sizeof(*tps6105x);
> }
>
> return mfd_add_devices(>dev, 0, tps6105x_cells,
> -ARRAY_SIZE(tps6105x_cells), NULL, 0, NULL);
> +n_cells, NULL, 0, NULL);
> }
>
> static int tps6105x_remove(struct i2c_client *client)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] backlight: adp8860: Remove unnecessary MODULE_ALIAS()
On Sun, 30 Aug 2015, Javier Martinez Canillas wrote:
> The driver has a I2C device id table that is used to create the modaliases
> and also "adp8860-backlight" is not a supported I2C id, so it's never used.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> drivers/video/backlight/adp8860_bl.c | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/video/backlight/adp8860_bl.c
> b/drivers/video/backlight/adp8860_bl.c
> index 71147f4461b8..98ffe71e8af2 100644
> --- a/drivers/video/backlight/adp8860_bl.c
> +++ b/drivers/video/backlight/adp8860_bl.c
> @@ -819,4 +819,3 @@ module_i2c_driver(adp8860_driver);
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Michael Hennerich ");
> MODULE_DESCRIPTION("ADP8860 Backlight driver");
> -MODULE_ALIAS("i2c:adp8860-backlight");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] backlight: adp8870: Remove unnecessary MODULE_ALIAS()
On Sun, 30 Aug 2015, Javier Martinez Canillas wrote:
> The driver has a I2C device id table that is used to create the modaliases
> and also "adp8870-backlight" is not a supported I2C id, so it's never used.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> drivers/video/backlight/adp8870_bl.c | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/video/backlight/adp8870_bl.c
> b/drivers/video/backlight/adp8870_bl.c
> index 037e43083343..9d738352d7d4 100644
> --- a/drivers/video/backlight/adp8870_bl.c
> +++ b/drivers/video/backlight/adp8870_bl.c
> @@ -992,4 +992,3 @@ module_i2c_driver(adp8870_driver);
> MODULE_LICENSE("GPL v2");
> MODULE_AUTHOR("Michael Hennerich ");
> MODULE_DESCRIPTION("ADP8870 Backlight driver");
> -MODULE_ALIAS("i2c:adp8870-backlight");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: wm8998: Fixup register defaults/readables
On Wed, 09 Sep 2015, Charles Keepax wrote:
> Remove defaults for a bunch of volatile registers and remove
> ARIZONA_CTRL_IF_SPI_CFG_1 from the readable list since it doesn't exist
> on wm8998 which is I2C only.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/mfd/wm8998-tables.c |8
> 1 files changed, 0 insertions(+), 8 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/wm8998-tables.c b/drivers/mfd/wm8998-tables.c
> index e6de3cd..08fc520 100644
> --- a/drivers/mfd/wm8998-tables.c
> +++ b/drivers/mfd/wm8998-tables.c
> @@ -199,8 +199,6 @@ static const struct reg_default wm8998_reg_default[] = {
> { 0x0069, 0x01FF },/* R105 - Always On Triggers Sequence
> Select 4 */
> { 0x006A, 0x01FF },/* R106 - Always On Triggers Sequence
> Select 5 */
> { 0x006B, 0x01FF },/* R107 - Always On Triggers Sequence
> Select 6 */
> - { 0x006E, 0x01FF },/* R110 - Trigger Sequence Select 32 */
> - { 0x006F, 0x01FF },/* R111 - Trigger Sequence Select 33 */
> { 0x0090, 0x },/* R144 - Haptics Control 1 */
> { 0x0091, 0x7FFF },/* R145 - Haptics Control 2 */
> { 0x0092, 0x },/* R146 - Haptics phase 1 intensity */
> @@ -270,16 +268,13 @@ static const struct reg_default wm8998_reg_default[] = {
> { 0x021A, 0x01A6 },/* R538 - Mic Bias Ctrl 3 */
> { 0x0293, 0x0080 },/* R659 - Accessory Detect Mode 1 */
> { 0x029B, 0x },/* R667 - Headphone Detect 1 */
> - { 0x029C, 0x },/* R668 - Headphone Detect 2 */
> { 0x02A2, 0x },/* R674 - Micd Clamp control */
> { 0x02A3, 0x1102 },/* R675 - Mic Detect 1 */
> { 0x02A4, 0x009F },/* R676 - Mic Detect 2 */
> - { 0x02A5, 0x },/* R677 - Mic Detect 3 */
> { 0x02A6, 0x3737 },/* R678 - Mic Detect Level 1 */
> { 0x02A7, 0x2C37 },/* R679 - Mic Detect Level 2 */
> { 0x02A8, 0x1422 },/* R680 - Mic Detect Level 3 */
> { 0x02A9, 0x030A },/* R681 - Mic Detect Level 4 */
> - { 0x02AB, 0x },/* R683 - Mic Detect 4 */
> { 0x02CB, 0x },/* R715 - Isolation control */
> { 0x02D3, 0x },/* R723 - Jack detect analogue */
> { 0x0300, 0x },/* R768 - Input Enables */
> @@ -707,13 +702,11 @@ static const struct reg_default wm8998_reg_default[] = {
> { 0x0D1A, 0x },/* R3354 - IRQ2 Status 3 Mask */
> { 0x0D1B, 0x },/* R3355 - IRQ2 Status 4 Mask */
> { 0x0D1C, 0xFEFF },/* R3356 - IRQ2 Status 5 Mask */
> - { 0x0D1D, 0x },/* R3357 - IRQ2 Status 6 Mask */
> { 0x0D1F, 0x },/* R3359 - IRQ2 Control */
> { 0x0D53, 0x },/* R3411 - AOD IRQ Mask IRQ1 */
> { 0x0D54, 0x },/* R3412 - AOD IRQ Mask IRQ2 */
> { 0x0D56, 0x },/* R3414 - Jack detect debounce */
> { 0x0E00, 0x },/* R3584 - FX_Ctrl1 */
> - { 0x0E01, 0x },/* R3585 - FX_Ctrl2 */
> { 0x0E10, 0x6318 },/* R3600 - EQ1_1 */
> { 0x0E11, 0x6300 },/* R3601 - EQ1_2 */
> { 0x0E12, 0x0FC8 },/* R3602 - EQ1_3 */
> @@ -833,7 +826,6 @@ static bool wm8998_readable_register(struct device *dev,
> unsigned int reg)
> switch (reg) {
> case ARIZONA_SOFTWARE_RESET:
> case ARIZONA_DEVICE_REVISION:
> - case ARIZONA_CTRL_IF_SPI_CFG_1:
> case ARIZONA_CTRL_IF_I2C1_CFG_1:
> case ARIZONA_CTRL_IF_I2C1_CFG_2:
> case ARIZONA_WRITE_SEQUENCER_CTRL_0:
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] mfd: Add battery charger as subdevice to the tps65217.
On Tue, 08 Sep 2015, Enric Balletbo i Serra wrote:
> Add tps65217 battery charger subdevice.
>
> Signed-off-by: Enric Balletbo i Serra
> ---
> drivers/mfd/tps65217.c | 4
> 1 file changed, 4 insertions(+)
Applied, thanks.
> diff --git a/drivers/mfd/tps65217.c b/drivers/mfd/tps65217.c
> index 55add04..d32b5442 100644
> --- a/drivers/mfd/tps65217.c
> +++ b/drivers/mfd/tps65217.c
> @@ -39,6 +39,10 @@ static const struct mfd_cell tps65217s[] = {
> .name = "tps65217-bl",
> .of_compatible = "ti,tps65217-bl",
> },
> + {
> + .name = "tps65217-charger",
> + .of_compatible = "ti,tps65217-charger",
> + },
> };
>
> /**
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] mfd: arizona: Add register bits to support the ANC block
On Wed, 09 Sep 2015, Charles Keepax wrote:
> Some Arizona devices have a hardware ANC block present. This patch adds
> the registers necessary to configure this hardware block.
>
> Signed-off-by: Charles Keepax
> ---
>
> Changes since v2:
> - Added missing default for 0xF0A
>
> Thanks,
> Charles
>
> drivers/mfd/wm5110-tables.c | 186
> +
> include/linux/mfd/arizona/registers.h | 70
> 2 files changed, 256 insertions(+), 0 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/wm5110-tables.c b/drivers/mfd/wm5110-tables.c
> index dae04dd..f154991 100644
> --- a/drivers/mfd/wm5110-tables.c
> +++ b/drivers/mfd/wm5110-tables.c
> @@ -1637,6 +1637,185 @@ static const struct reg_default wm5110_reg_default[]
> = {
> { 0x0EF8, 0x },/* R3832 - ISRC 3 CTRL 3 */
> { 0x0F00, 0x },/* R3840 - Clock Control */
> { 0x0F01, 0x },/* R3841 - ANC_SRC */
> + { 0x0F08, 0x001c },/* R3848 - ANC Coefficient */
> + { 0x0F09, 0x },/* R3849 - ANC Coefficient */
> + { 0x0F0A, 0x },/* R3850 - ANC Coefficient */
> + { 0x0F0B, 0x },/* R3851 - ANC Coefficient */
> + { 0x0F0C, 0x },/* R3852 - ANC Coefficient */
> + { 0x0F0D, 0x },/* R3853 - ANC Coefficient */
> + { 0x0F0E, 0x },/* R3854 - ANC Coefficient */
> + { 0x0F0F, 0x },/* R3855 - ANC Coefficient */
> + { 0x0F10, 0x },/* R3856 - ANC Coefficient */
> + { 0x0F11, 0x },/* R3857 - ANC Coefficient */
> + { 0x0F12, 0x },/* R3858 - ANC Coefficient */
> + { 0x0F15, 0x },/* R3861 - FCL Filter Control */
> + { 0x0F17, 0x0004 },/* R3863 - FCL ADC Reformatter Control */
> + { 0x0F18, 0x0004 },/* R3864 - ANC Coefficient */
> + { 0x0F19, 0x0002 },/* R3865 - ANC Coefficient */
> + { 0x0F1A, 0x },/* R3866 - ANC Coefficient */
> + { 0x0F1B, 0x0010 },/* R3867 - ANC Coefficient */
> + { 0x0F1C, 0x },/* R3868 - ANC Coefficient */
> + { 0x0F1D, 0x },/* R3869 - ANC Coefficient */
> + { 0x0F1E, 0x },/* R3870 - ANC Coefficient */
> + { 0x0F1F, 0x },/* R3871 - ANC Coefficient */
> + { 0x0F20, 0x },/* R3872 - ANC Coefficient */
> + { 0x0F21, 0x },/* R3873 - ANC Coefficient */
> + { 0x0F22, 0x },/* R3874 - ANC Coefficient */
> + { 0x0F23, 0x },/* R3875 - ANC Coefficient */
> + { 0x0F24, 0x },/* R3876 - ANC Coefficient */
> + { 0x0F25, 0x },/* R3877 - ANC Coefficient */
> + { 0x0F26, 0x },/* R3878 - ANC Coefficient */
> + { 0x0F27, 0x },/* R3879 - ANC Coefficient */
> + { 0x0F28, 0x },/* R3880 - ANC Coefficient */
> + { 0x0F29, 0x },/* R3881 - ANC Coefficient */
> + { 0x0F2A, 0x },/* R3882 - ANC Coefficient */
> + { 0x0F2B, 0x },/* R3883 - ANC Coefficient */
> + { 0x0F2C, 0x },/* R3884 - ANC Coefficient */
> + { 0x0F2D, 0x },/* R3885 - ANC Coefficient */
> + { 0x0F2E, 0x },/* R3886 - ANC Coefficient */
> + { 0x0F2F, 0x },/* R3887 - ANC Coefficient */
> + { 0x0F30, 0x },/* R3888 - ANC Coefficient */
> + { 0x0F31, 0x },/* R3889 - ANC Coefficient */
> + { 0x0F32, 0x },/* R3890 - ANC Coefficient */
> + { 0x0F33, 0x },/* R3891 - ANC Coefficient */
> + { 0x0F34, 0x },/* R3892 - ANC Coefficient */
> + { 0x0F35, 0x },/* R3893 - ANC Coefficient */
> + { 0x0F36, 0x },/* R3894 - ANC Coefficient */
> + { 0x0F37, 0x },/* R3895 - ANC Coefficient */
> + { 0x0F38, 0x },/* R3896 - ANC Coefficient */
> + { 0x0F39, 0x },/* R3897 - ANC Coefficient */
> + { 0x0F3A, 0x },/* R3898 - ANC Coefficient */
> + { 0x0F3B, 0x },/* R3899 - ANC Coefficient */
> + { 0x0F3C, 0x },/* R3900 - ANC Coefficient */
> + { 0x0F3D, 0x },/* R3901 - ANC Coefficient */
> + { 0x0F3E, 0x },/* R3902 - ANC Coefficient */
> + { 0x0F3F, 0x },/* R3903 - ANC Coefficient */
> + { 0x0F40, 0x },/* R3904 - ANC Coefficient */
> + { 0x0F41, 0x },/* R3905 - ANC Coefficient */
> + { 0x0F42, 0x },/* R3906 - ANC Coefficient */
> + { 0x0F43, 0x },/* R3907 - ANC Coefficient */
> + { 0x0F44, 0x },/* R3908 - ANC Coefficient */
> + { 0x0F45, 0x },/* R3909 - ANC Coefficient */
> + { 0x0F46, 0x },/* R3910 - ANC Coefficient */
> + { 0x0F47, 0x },/* R3911 -
Re: [PATCH linux-next v9 0/3] mfd: flexcom: add a driver for Flexcom
Patch set description? Once Rob is satisfied, please re-submit this set with Nicolas' Acks and I will re-review. > ChangeLog > > v9: > - go back to v5 (use the new "atmel,flexcom-mode" DT property). > - fix the name of the spi node in the DT example: from spi@f8034400 to > spi@400 > - align the fields of the struct platform_driver atmel_flexcom_driver as > suggested by Lee Jones. > > v8: > - fix the name of the spi node in the DT example: from spi@f8034400 to > spi@2,0 > - use the return code of op_property_read_u32_index() instead of -EINVAL > to report error. > - add Acked-by from Nicolas Ferre > > v7: > - read the operating mode from the very first u32 of the reg property from > the first available child node (should be unique). > - update the DT bindings documentation accordingly. > > v6: > - select the operating mode according to the "compatible" DT property of > the first available child node (should be unique). > - remove the "atmel,flexcom-mode" DT property so the need of a header file > defining macros for the possible values of this deprecated property. > > v5: > - create a header file containing macros used by DT bindings > - use numeric constants instead of strings to select the Flexcom mode > - change the license to "GPL v2" > - update the DT binding documentation to make it more readable and add > references to USART, SPI and I2C DT binding documentations. remove the > useless label in the Example section. > - change the register prefix from FX_ to FLEX_ to match the Flexcom > programmer datasheet. > - rename some variables to make them more understandable. > > v4: > - check clk_prepare_enable() return code in atmel_flexcom_probe() > - add a commit message to the DT binding patch > > v3: > - remove MODULE_ALIAS() > - add Acked-by from Boris Brezillon and Alexandre Belloni > > v2: > - enhance the documentation of DT bindings and change the way the "ranges" > property is used. > - replace __raw_readl() and __raw_writel() by readl() and writel(). > - change the module license to "GPL" for v2 or later > - print the selected flexcom mode after the hardware version > > v1: > This series of patches a support to the Atmel Flexcom, a wrapper which > integrates an USART, a SPI controller and a TWI controller. Only one > peripheral can be used at a time. The active function is selected though > the Flexcom Mode Register. > > Cyrille Pitchen (3): > mfd: atmel-flexcom: create include file with macros used by DT > bindings > mfd: devicetree: add bindings for Atmel Flexcom > mfd: atmel-flexcom: add a driver for Atmel Flexible Serial > Communication Unit > > .../devicetree/bindings/mfd/atmel-flexcom.txt | 67 + > drivers/mfd/Kconfig| 11 +++ > drivers/mfd/Makefile | 1 + > drivers/mfd/atmel-flexcom.c| 104 > + > include/dt-bindings/mfd/atmel-flexcom.h| 16 > 5 files changed, 199 insertions(+) > create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt > create mode 100644 drivers/mfd/atmel-flexcom.c > create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h > -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: bcm590xx: Remove unnecessary MODULE_ALIAS()
On Mon, 31 Aug 2015, Javier Martinez Canillas wrote:
> The driver has a I2C device id table that is used to create the module
> aliases and also "bcm590xx" isn't a supported I2C id, so it's never used.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> drivers/mfd/bcm590xx.c | 1 -
> 1 file changed, 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/bcm590xx.c b/drivers/mfd/bcm590xx.c
> index da2af5b4f855..320aaefee718 100644
> --- a/drivers/mfd/bcm590xx.c
> +++ b/drivers/mfd/bcm590xx.c
> @@ -128,4 +128,3 @@ module_i2c_driver(bcm590xx_i2c_driver);
> MODULE_AUTHOR("Matt Porter ");
> MODULE_DESCRIPTION("BCM590xx multi-function driver");
> MODULE_LICENSE("GPL v2");
> -MODULE_ALIAS("i2c:bcm590xx");
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 2/3] mfd: update intel_soc_pmic structure to support Broxton WC PMIC
On Tue, 15 Sep 2015, Qipeng Zha wrote:
> IRQ control registers of Intel Broxton Whisky Cove PMIC are
> separated in two parts, so add secondary IRQ chip.
> And the new member of device will be used in PMC IPC regmap APIs.
>
> Signed-off-by: Qipeng Zha
> ---
> include/linux/mfd/intel_soc_pmic.h | 2 ++
> 1 file changed, 2 insertions(+)
Acked-by: Lee Jones
> diff --git a/include/linux/mfd/intel_soc_pmic.h
> b/include/linux/mfd/intel_soc_pmic.h
> index abcbfcf..cf619db 100644
> --- a/include/linux/mfd/intel_soc_pmic.h
> +++ b/include/linux/mfd/intel_soc_pmic.h
> @@ -25,6 +25,8 @@ struct intel_soc_pmic {
> int irq;
> struct regmap *regmap;
> struct regmap_irq_chip_data *irq_chip_data;
> + struct regmap_irq_chip_data *irq_chip_data_level2;
> + struct device *dev;
> };
>
> #endif /* __INTEL_SOC_PMIC_H__ */
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 3/3] mfd: add Intel Broxton Whiskey Cove PMIC driver
On Tue, 15 Sep 2015, Qipeng Zha wrote:
> Add MFD core driver for Intel Broxton Whiskey Cove PMIC,
> which is specially accessed by hardware IPC, not a generic
> I2C device
>
> Signed-off-by: Qipeng Zha
>
> ---
> change in v6
> Replace INIT_REGMAP_IRQ with REGMAP_IRQ_REG.
If that's all that has changed my Ack can carry:
Acked-by: Lee Jones
Still no Ack for the regmap side though, so still can't apply.
> change in v5
> Fix issues in code style, espcially make error messages readable;
> Put regmap_irq macro in header file and separate into two patch;
> Use DEFFINE_RES_IRQ to define irq resource;
> Remove default_i2c_addr and use macro directly;
> Change platform driver name to make it more readable;
>
> change in v4
> Add compile dependency to PMC IPC driver in Makefile, or will
> use NULL stubs defined in PMC IPC header file;
>
> change in v3
> Implement ipc regmap r/w callback in pmic driver, since there dropped
> before patch of implement virtual ipc support in regmap core;
> Update some function's comment;
> ---
> drivers/mfd/Makefile | 1 +
> drivers/mfd/intel_soc_pmic_bxtwc.c | 478
> +
> include/linux/mfd/intel_bxtwc.h| 69 ++
> 3 files changed, 548 insertions(+)
> create mode 100644 drivers/mfd/intel_soc_pmic_bxtwc.c
> create mode 100644 include/linux/mfd/intel_bxtwc.h
>
> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
> index 0e5cfeb..8fc894e 100644
> --- a/drivers/mfd/Makefile
> +++ b/drivers/mfd/Makefile
> @@ -183,5 +183,6 @@ obj-$(CONFIG_MFD_RT5033) += rt5033.o
> obj-$(CONFIG_MFD_SKY81452) += sky81452.o
>
> intel-soc-pmic-objs := intel_soc_pmic_core.o intel_soc_pmic_crc.o
> +intel-soc-pmic-$(CONFIG_INTEL_PMC_IPC) += intel_soc_pmic_bxtwc.o
> obj-$(CONFIG_INTEL_SOC_PMIC) += intel-soc-pmic.o
> obj-$(CONFIG_MFD_MT6397) += mt6397-core.o
> diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c
> b/drivers/mfd/intel_soc_pmic_bxtwc.c
> new file mode 100644
> index 000..40acaff
> --- /dev/null
> +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
> @@ -0,0 +1,478 @@
> +/*
> + * MFD core driver for Intel Broxton Whiskey Cove PMIC
> + *
> + * Copyright (C) 2015 Intel Corporation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but WITHOUT
> + * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
> + * more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +/* PMIC device registers */
> +#define REG_ADDR_MASK0xFF00
> +#define REG_ADDR_SHIFT 8
> +#define REG_OFFSET_MASK 0xFF
> +
> +/* Interrupt Status Registers */
> +#define BXTWC_IRQLVL10x4E02
> +#define BXTWC_PWRBTNIRQ 0x4E03
> +
> +#define BXTWC_THRM0IRQ 0x4E04
> +#define BXTWC_THRM1IRQ 0x4E05
> +#define BXTWC_THRM2IRQ 0x4E06
> +#define BXTWC_BCUIRQ 0x4E07
> +#define BXTWC_ADCIRQ 0x4E08
> +#define BXTWC_CHGR0IRQ 0x4E09
> +#define BXTWC_CHGR1IRQ 0x4E0A
> +#define BXTWC_GPIOIRQ0 0x4E0B
> +#define BXTWC_GPIOIRQ1 0x4E0C
> +#define BXTWC_CRITIRQ0x4E0D
> +
> +/* Interrupt MASK Registers */
> +#define BXTWC_MIRQLVL1 0x4E0E
> +#define BXTWC_MPWRTNIRQ 0x4E0F
> +
> +#define BXTWC_MTHRM0IRQ 0x4E12
> +#define BXTWC_MTHRM1IRQ 0x4E13
> +#define BXTWC_MTHRM2IRQ 0x4E14
> +#define BXTWC_MBCUIRQ0x4E15
> +#define BXTWC_MADCIRQ0x4E16
> +#define BXTWC_MCHGR0IRQ 0x4E17
> +#define BXTWC_MCHGR1IRQ 0x4E18
> +#define BXTWC_MGPIO0IRQ 0x4E19
> +#define BXTWC_MGPIO1IRQ 0x4E1A
> +#define BXTWC_MCRITIRQ 0x4E1B
> +
> +/* Whiskey Cove PMIC share same ACPI ID between different platforms */
> +#define BROXTON_PMIC_WC_HRV 4
> +
> +/* Manage in two IRQ chips since mask registers are not consecutive */
> +enum bxtwc_irqs {
> + /* Level 1 */
> + BXTWC_PWRBTN_LVL1_IRQ = 0,
> + BXTWC_TMU_LVL1_IRQ,
> + BXTWC_THRM_LVL1_IRQ,
> + BXTWC_BCU_LVL1_IRQ,
> + BXTWC_ADC_LVL1_IRQ,
> + BXTWC_CHGR_LVL1_IRQ,
> + BXTWC_GPIO_LVL1_IRQ,
> + BXTWC_CRIT_LVL1_IRQ,
> +
> + /* Level 2 */
> + BXTWC_PWRBTN_IRQ,
> +};
> +
> +enum bxtwc_irqs_level2 {
> + /* Level 2 */
> + BXTWC_THRM0_IRQ = 0,
> + BXTWC_THRM1_IRQ,
> + BXTWC_THRM2_IRQ,
> + BXTWC_BCU_IRQ,
> + BXTWC_ADC_IRQ,
> + BXTWC_CHGR0_IRQ,
> + BXTWC_CHGR1_IRQ,
> +
Re: [PATCH 6/6] mfd: arizona: Update DT binding documentation for jack detection
On Wed, 16 Sep 2015, Charles Keepax wrote: > Add additional bindings for both inverting the polarity of the jack > detection pins and allowing the use of a second jack detection pin. Note > that the second jack detection pin is hard wired in the chip so can only > be enabled through the binding, rather than a pin being specified. > > Signed-off-by: Charles Keepax > Reviewed-by: Chanwoo Choi > --- > Documentation/devicetree/bindings/mfd/arizona.txt |6 ++ > 1 files changed, 6 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > b/Documentation/devicetree/bindings/mfd/arizona.txt > index b98a11b..cb3a652 100644 > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > @@ -73,6 +73,12 @@ Optional properties: > If this node is not mentioned or if the value is unknown, then > headphone detection mode is set to HPDETL. > > + - wlf,use-jd-gpio : Use GPIO input along with JD1 for dual pin jack > +detection. > + - wlf,use-jd-gpio-nopull : Internal pull on GPIO is disabled when used for > +jack detection. > + - wlf,jd-invert : Invert the polarity of the jack detection switch As before, I need an Ack from one of the DT guys, or perhaps Linus W. >- wlf,micd-software-compare : Use a software comparison to determine mic > presence >- wlf,micd-detect-debounce : Additional software microphone detection -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: wm831x: Fix possible NULL pointer dereference
On Mon, 14 Sep 2015, Javier Martinez Canillas wrote:
> The driver always checks for pdata being NULL expect in one place.
> Add a check to prevent a possible NULL pointer deference error.
>
> Signed-off-by: Javier Martinez Canillas
>
> ---
>
> drivers/mfd/wm831x-core.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
Applied, thanks.
NB: I'll also try to remember to fix-up the spelling error in the
commit log.
> diff --git a/drivers/mfd/wm831x-core.c b/drivers/mfd/wm831x-core.c
> index 28366a90e1ad..3e0e99ec5836 100644
> --- a/drivers/mfd/wm831x-core.c
> +++ b/drivers/mfd/wm831x-core.c
> @@ -1626,7 +1626,9 @@ int wm831x_device_init(struct wm831x *wm831x, unsigned
> long id, int irq)
> mutex_init(>io_lock);
> mutex_init(>key_lock);
> dev_set_drvdata(wm831x->dev, wm831x);
> - wm831x->soft_shutdown = pdata->soft_shutdown;
> +
> + if (pdata)
> + wm831x->soft_shutdown = pdata->soft_shutdown;
>
> ret = wm831x_reg_read(wm831x, WM831X_PARENT_ID);
> if (ret < 0) {
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mfd: max77843: Fix max77843_chg_init() return on error
On Tue, 15 Sep 2015, Krzysztof Kozlowski wrote:
> 2015-09-14 17:23 GMT+09:00 Javier Martinez Canillas :
> > If i2c_new_dummy() fails in max77843_chg_init(), an PTR_ERR(NULL) is
> > returned which is 0. So the function was wrongly returning a success
> > value instead of an error code.
> >
> > Fixes: c7f585fe46d8 ("mfd: max77843: Add max77843 MFD driver core driver")
> > Signed-off-by: Javier Martinez Canillas
> >
> > ---
> >
> > drivers/mfd/max77843.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Nice catch. I think this should go to stable. I did not try to
> reproduce it but looking at the code this should lead to NULL pointer
> exceptions on:
> 1. first access to max77843->regmap_chg (this won't actually happen
> because charger driver was not merged);
> 2. first dereference of pointer returned by i2c_get_clientdata() which
> will happen on first system suspend or device unbind/removal.
>
> Reviewed-by: Krzysztof Kozlowski
Please re-send this with stable Cc'ed and Krzysztof's RB applied.
> > diff --git a/drivers/mfd/max77843.c b/drivers/mfd/max77843.c
> > index c52162ea3d0a..586098f1b233 100644
> > --- a/drivers/mfd/max77843.c
> > +++ b/drivers/mfd/max77843.c
> > @@ -80,7 +80,7 @@ static int max77843_chg_init(struct max77693_dev
> > *max77843)
> > if (!max77843->i2c_chg) {
> > dev_err(>i2c->dev,
> > "Cannot allocate I2C device for Charger\n");
> > - return PTR_ERR(max77843->i2c_chg);
> > + return -ENODEV;
> > }
> > i2c_set_clientdata(max77843->i2c_chg, max77843);
> >
> >
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v6 1/3] regmap: add generic macro to define regmap_irq
On Tue, 15 Sep 2015, Qipeng Zha wrote:
> Add REGMAP_IRQ_REG macro in regmap.h to define regmap_irq
> structure easily for other driver module.
Couple of people requested this now:
Acked-by: Lee Jones
> Signed-off-by: Qipeng Zha
> ---
> include/linux/regmap.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/linux/regmap.h b/include/linux/regmap.h
> index 116655d..0d1ee0a 100644
> --- a/include/linux/regmap.h
> +++ b/include/linux/regmap.h
> @@ -517,6 +517,9 @@ struct regmap_irq {
> unsigned int mask;
> };
>
> +#define REGMAP_IRQ_REG(_irq, _off, _mask)\
> + [_irq] = { .reg_offset = (_off), .mask = (_mask) }
> +
> /**
> * Description of a generic regmap irq_chip. This is not intended to
> * handle every possible interrupt controller, but it should handle a
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO regulators
On Wed, 16 Sep 2015, Chen-Yu Tsai wrote:
> The DC1SW and DC5LDO regulators in the AXP221 are internally chained
> to DCDC1 and DCDC5, hence the names. The original bindings used the
> parent regulator names for the supply regulator property. This causes
> some confusion when we actually use it in the dts:
>
> axp221 {
> /* self supplying? */
> dcdc1-supply = <>;
> dcdc5-supply = <>;
>
> dcdc1: dcdc1 {
> ...
> };
>
> dcdc5: dcdc5 {
> ...
> };
> };
>
> Change them to the downstream regulator names, or "dc1sw" and "dc5ldo"
> respectively.
>
> Signed-off-by: Chen-Yu Tsai
> ---
> Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt
> b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 41811223e5be..8e79252b1e7c 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -60,8 +60,8 @@ DCDC2 : DC-DC buck: vin2-supply
> DCDC3: DC-DC buck: vin3-supply
> DCDC4: DC-DC buck: vin4-supply
> DCDC5: DC-DC buck: vin5-supply
> -DC1SW: On/Off Switch : dcdc1-supply : DCDC1
> secondary output
> -DC5LDO : LDO : dcdc5-supply : input from
> DCDC5
> +DC1SW: On/Off Switch : dc1sw-supply : DCDC1
> secondary output
> +DC5LDO : LDO : dc5ldo-supply : input from
> DCDC5
> ALDO1: LDO : aldoin-supply : shared supply
> ALDO2: LDO : aldoin-supply : shared supply
> ALDO3: LDO : aldoin-supply : shared supply
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND v2] mfd: s2mps11: Add manual shutdown method for Odroid XU3
On Mon, 14 Sep 2015, Krzysztof Kozlowski wrote:
> On Odroid XU3 board (with S2MPS11 PMIC) the PWRHOLD bit in CTRL1
> register must be manually set to 0 before initiating power off sequence.
>
> One of usual power down methods for Exynos based devices looks like:
> 1. PWRHOLD pin of PMIC is connected to PSHOLD of Exynos SoC.
> 2. Exynos holds up this pin during system operation.
> 3. ACOKB pin of PMIC is pulled up to VBATT and optionally to pin in
>other device.
> 4. When PWRHOLD/PSHOLD goes low, the PMIC will turn off the power if
>ACOKB goes high.
>
> On Odroid XU3 family the difference is in (3) - the ACOKB is grounded.
> This means that PMIC must manually set PWRHOLD field to low and then
> wait for signal from Application Processor (the usual change in
> PWRHOLD/PSHOLD pin will actually cut off the power).
>
> The patch adds respective binding allowing Odroid XU3 device to be
> powered off.
>
> Signed-off-by: Krzysztof Kozlowski
> Reported-by: Anand Moon
> Tested-by: Anand Moon
> Reviewed-by: Javier Martinez Canillas
> Acked-by: Lee Jones
>
> ---
>
> The rest of patchset was applied by Kukjin Kim:
> - dt-bindings documentation:
>
> https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/commit/?h=v4.3-next/dt-samsung-new-3=ff1020841cf0ff868d61d44169e7cc32f73599b8
> - DTS change:
>
> https://git.kernel.org/cgit/linux/kernel/git/kgene/linux-samsung.git/commit/?h=v4.3-next/dt-samsung-new-3=5bcbe4ba55bb0ad75c8495ee295bab036735483e
>
> Changes since v2:
> 1. Just rebase on current next.
>
> Changes since v1:
> 1. Split bindings documentation to separate patch (suggested by Lee).
> 2. Fix additional empty line (suggested by Lee).
> 3. Add Anand's tested-by, Javier's reviewed-by and Lee's acked-by.
>
> Patch is losely based on patch in Hardkernel repository and previous
> work of Anand Moon.
> ---
> drivers/mfd/sec-core.c | 30 ++
> include/linux/mfd/samsung/core.h| 2 ++
> include/linux/mfd/samsung/s2mps11.h | 1 +
> 3 files changed, 33 insertions(+)
Applied, thanks.
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index d206a3e8fe87..2d1137a7a0ee 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -278,6 +278,8 @@ static struct sec_platform_data
> *sec_pmic_i2c_parse_dt_pdata(
>* not parsed here.
>*/
>
> + pd->manual_poweroff = of_property_read_bool(dev->of_node,
> + "samsung,s2mps11-acokb-ground");
> return pd;
> }
> #else
> @@ -440,6 +442,33 @@ static int sec_pmic_remove(struct i2c_client *i2c)
> return 0;
> }
>
> +static void sec_pmic_shutdown(struct i2c_client *i2c)
> +{
> + struct sec_pmic_dev *sec_pmic = i2c_get_clientdata(i2c);
> + unsigned int reg, mask;
> +
> + if (!sec_pmic->pdata->manual_poweroff)
> + return;
> +
> + switch (sec_pmic->device_type) {
> + case S2MPS11X:
> + reg = S2MPS11_REG_CTRL1;
> + mask = S2MPS11_CTRL1_PWRHOLD_MASK;
> + break;
> + default:
> + /*
> + * Currently only one board with S2MPS11 needs this, so just
> + * ignore the rest.
> + */
> + dev_warn(sec_pmic->dev,
> + "Unsupported device %lu for manual power off\n",
> + sec_pmic->device_type);
> + return;
> + }
> +
> + regmap_update_bits(sec_pmic->regmap_pmic, reg, mask, 0);
> +}
> +
> #ifdef CONFIG_PM_SLEEP
> static int sec_pmic_suspend(struct device *dev)
> {
> @@ -491,6 +520,7 @@ static struct i2c_driver sec_pmic_driver = {
> },
> .probe = sec_pmic_probe,
> .remove = sec_pmic_remove,
> + .shutdown = sec_pmic_shutdown,
> .id_table = sec_pmic_id,
> };
>
> diff --git a/include/linux/mfd/samsung/core.h
> b/include/linux/mfd/samsung/core.h
> index 75115384f3fc..aa78957e092f 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -132,6 +132,8 @@ struct sec_platform_data {
> int buck2_init;
> int buck3_init;
> int buck4_init;
> + /* Whether or not manually set PWRHOLD to low during shutdown. */
> + boolmanual_poweroff;
> };
>
> /**
> diff --git a/include/linux/mfd/samsung/s2mps11.h
> b/include/linux/mfd/samsung/s2mps11.h
> index 7981a9d77d3f..b288965e8101 100644
> --- a/include/linux/mfd/samsung/s2mps11.h
> +++ b/include/linux/mfd/samsung/s2mps11.h
> @@ -179,6 +179,7 @@ enum s2mps11_regulators {
> #define S2MPS11_BUCK_N_VOLTAGES (S2MPS11_BUCK_VSEL_MASK + 1)
> #define S2MPS11_RAMP_DELAY 25000 /* uV/us */
>
> +#define S2MPS11_CTRL1_PWRHOLD_MASK BIT(4)
>
> #define S2MPS11_BUCK2_RAMP_SHIFT 6
> #define S2MPS11_BUCK34_RAMP_SHIFT4
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Re: [PATCH] mfd: arizona: Fix typo in arizona_irq_map
On Fri, 11 Sep 2015, Charles Keepax wrote:
> The type of the data for the main Arizona IRQ chip should be struct
> arizona not struct regmap_irq_chip_data. The bug is harmless but should
> probably be corrected anyway.
>
> Signed-off-by: Charles Keepax
> ---
> drivers/mfd/arizona-irq.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
> index 2cac4f4..3d425e9 100644
> --- a/drivers/mfd/arizona-irq.c
> +++ b/drivers/mfd/arizona-irq.c
> @@ -169,7 +169,7 @@ static struct irq_chip arizona_irq_chip = {
> static int arizona_irq_map(struct irq_domain *h, unsigned int virq,
> irq_hw_number_t hw)
> {
> - struct regmap_irq_chip_data *data = h->host_data;
> + struct arizona *data = h->host_data;
>
> irq_set_chip_data(virq, data);
> irq_set_chip_and_handler(virq, _irq_chip, handle_simple_irq);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Documentation: tps65912: Add DT bindings for the TPS65912 PMIC
On Tue, 15 Sep 2015, Andrew F. Davis wrote:
> The TPS65912 PMIC contains several regulators and a GPIO controller.
> Add bindings for the TPS65912 PMIC.
>
> Signed-off-by: Andrew F. Davis
> ---
> .../devicetree/bindings/gpio/gpio-tps65912.txt | 17 +
> Documentation/devicetree/bindings/mfd/tps65912.txt | 43
> ++
> .../bindings/regulator/tps65912-regulator.txt | 32
> 3 files changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
> create mode 100644 Documentation/devicetree/bindings/mfd/tps65912.txt
> create mode 100644
> Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
> b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
> new file mode 100644
> index 000..f65370b
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-tps65912.txt
> @@ -0,0 +1,17 @@
> +* TPS65912 GPIO controller bindings
Suggest s/controller/Controller/
> +Required properties:
> + - compatible : Should be "ti,tps65912-gpio".
> + - gpio-controller : Marks the device node as a gpio controller.
s/gpio/GPIO/
As above for controller.
> + - #gpio-cells : Should be two. The first cell is the pin number and
> + the second cell is used to specify the gpio polarity:
> + 0 = active high
> + 1 = active low
Best to use the #defines in include/dt-bindings/gpio.
> +Example:
> +
> + gpio4: tps65912_gpio {
> + compatible = "ti,tps65912-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> diff --git a/Documentation/devicetree/bindings/mfd/tps65912.txt
> b/Documentation/devicetree/bindings/mfd/tps65912.txt
> new file mode 100644
> index 000..081af66
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/tps65912.txt
> @@ -0,0 +1,43 @@
> +* TPS65912 Power Management Integrated Circuit bindings
> +
> +Required properties:
> + - compatible : Should be "ti,tps65912".
> + - reg : Slave address or chip select number (I2C / SPI).
> + - interrupt-parent : The parent interrupt controller.
> + - interrupts : The interrupt line the device is connected to.
> + - interrupt-controller : Marks the device node as an interrupt controller.
> + - #interrupt-cells: the number of cells to describe an IRQ, this should be
> 2.
s/the/The/
> + The first cell is the IRQ number.
> + The second cell is the flags, encoded as the trigger masks from
> + Documentation/devicetree/bindings/interrupts.txt
No such file.
> +Optional nodes:
> + - Regulators:
> Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> + - GPIO: Documentation/devicetree/bindings/gpio/gpio-tps65912.txt.
Better to use ../gpio, ../regulator, etc.
"Regulators" and "GPIO" aren't valid node names.
Please be more specific.
> +Example:
> +
> + pmic: tps65912@2d {
> + compatible = "ti,tps65912";
> + reg = <0x2d>;
> + interrupt-parent = <>;
> + interrupts = <28 IRQ_TYPE_LEVEL_LOW>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + dcdc1: regulator-dcdc1 {
> + compatible = "ti,tps65912-dcdc1";
> + regulator-name = "vdd_core";
> + regulator-min-microvolt = <912000>;
> + regulator-max-microvolt = <1144000>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> + ...
No need for this.
> + gpio4: tps65912_gpio {
> + compatible = "ti,tps65912-gpio";
> + gpio-controller;
> + #gpio-cells = <2>;
> + };
> + };
> diff --git
> a/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> new file mode 100644
> index 000..a417ff7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/regulator/tps65912-regulator.txt
> @@ -0,0 +1,32 @@
> +* TPS65912 regulator bindings
> +
> +Required properties:
> + - compatible: Should be:
> + - "ti,tps65912-dcdc1" for DCDC1
> + - "ti,tps65912-dcdc2" for DCDC2
> + - "ti,tps65912-dcdc3" for DCDC3
> + - "ti,tps65912-dcdc4" for DCDC4
> + - "ti,tps65912-ldo1" for LDO1
> + - "ti,tps65912-ldo2" for LDO2
> + - "ti,tps65912-ldo3" for LDO3
> + - "ti,tps65912-ldo4" for LDO4
> + - "ti,tps65912-ldo5" for LDO5
> + - "ti,tps65912-ldo6" for LDO6
> + - "ti,tps65912-ldo7" for LDO7
> + - "ti,tps65912-ldo8" for LDO8
> + - "ti,tps65912-ldo9" for LDO9
> + - "ti,tps65912-ldo10" for LDO10
> +
> +Optional properties:
> + - Any optional property defined in bindings/regulator/regulator.txt
../regulator/...
> +Example:
> +
> + xyz: regulator@0 {
> + compatible = "ti,tps65912-dcdc1";
> + regulator-name =
Re: [PATCH 5/6] mfd: arizona: Update DT binding documentation for mic detection
On Wed, 16 Sep 2015, Charles Keepax wrote: > Add additional bindings to allow configuration of the system specific > microphone detection settings. > > Signed-off-by: Charles Keepax > --- > Documentation/devicetree/bindings/mfd/arizona.txt | 21 > + > include/dt-bindings/mfd/arizona.h |5 + > 2 files changed, 26 insertions(+), 0 deletions(-) > > diff --git a/Documentation/devicetree/bindings/mfd/arizona.txt > b/Documentation/devicetree/bindings/mfd/arizona.txt > index a8fee60..b98a11b 100644 > --- a/Documentation/devicetree/bindings/mfd/arizona.txt > +++ b/Documentation/devicetree/bindings/mfd/arizona.txt > @@ -73,6 +73,27 @@ Optional properties: > If this node is not mentioned or if the value is unknown, then > headphone detection mode is set to HPDETL. > > + - wlf,micd-software-compare : Use a software comparison to determine mic > +presence > + - wlf,micd-detect-debounce : Additional software microphone detection > +debounce specified in milliseconds. > + - wlf,micd-pol-gpio : GPIO specifier for the GPIO controlling the headset > +polarity if one exists. > + - wlf,micd-bias-start-time : Time allowed for MICBIAS to startup prior to > +performing microphone detection, specified as per the > ARIZONA_MICD_TIME_XXX > +defines. > + - wlf,micd-rate : Delay between successive microphone detection > measurements, > +specified as per the ARIZONA_MICD_TIME_XXX defines. > + - wlf,micd-dbtime : Microphone detection hardware debounces specified as > the > +number of measurements to take, valid values being 2 and 4. > + - wlf,micd-timeout : Timeout for microphone detection, specified in > +milliseconds. > + - wlf,micd-force-micbias : Force MICBIAS continuously on during microphone > +detection. > + > + - wlf,gpsw : Settings for the general purpose switch, set as one of the > +ARIZONA_GPSW_XXX defines. I either need an Ack from the DT folks, or at least someone who knows about this stuff. Mark perhaps. >- DCVDD-supply, MICVDD-supply : Power supplies, only need to be specified > if > they are being externally supplied. As covered in > Documentation/devicetree/bindings/regulator/regulator.txt > diff --git a/include/dt-bindings/mfd/arizona.h > b/include/dt-bindings/mfd/arizona.h > index c40f665..dedf46f 100644 > --- a/include/dt-bindings/mfd/arizona.h > +++ b/include/dt-bindings/mfd/arizona.h > @@ -110,4 +110,9 @@ > #define ARIZONA_ACCDET_MODE_HPM 4 > #define ARIZONA_ACCDET_MODE_ADC 7 > > +#define ARIZONA_GPSW_OPEN 0 > +#define ARIZONA_GPSW_CLOSED 1 > +#define ARIZONA_GPSW_CLAMP_ENABLED 2 > +#define ARIZONA_GPSW_CLAMP_DISABLED 3 > + > #endif -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/2] mfd: intel-lpss: use writeq() helper
On Mon, 14 Sep 2015, Andy Shevchenko wrote:
> There are already helper functions to do 64-bit I/O on 32-bit machines, thus
> we
> don't need to reinvent the wheel. In our case we can't use readq() / writeq()
> even on 64-bit kernel since there is a hardware limitation (OCP bus is a
> 32-bit
> bus).
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/mfd/intel-lpss.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
Applied, thanks.
> diff --git a/drivers/mfd/intel-lpss.c b/drivers/mfd/intel-lpss.c
> index fdf4d5c..001a7d7 100644
> --- a/drivers/mfd/intel-lpss.c
> +++ b/drivers/mfd/intel-lpss.c
> @@ -26,6 +26,8 @@
> #include
> #include
>
> +#include
> +
> #include "intel-lpss.h"
>
> #define LPSS_DEV_OFFSET 0x000
> @@ -52,8 +54,7 @@
> #define LPSS_PRIV_SSP_REG0x20
> #define LPSS_PRIV_SSP_REG_DIS_DMA_FINBIT(0)
>
> -#define LPSS_PRIV_REMAP_ADDR_LO 0x40
> -#define LPSS_PRIV_REMAP_ADDR_HI 0x44
> +#define LPSS_PRIV_REMAP_ADDR 0x40
>
> #define LPSS_PRIV_CAPS 0xfc
> #define LPSS_PRIV_CAPS_NO_IDMA BIT(8)
> @@ -250,12 +251,7 @@ static void intel_lpss_set_remap_addr(const struct
> intel_lpss *lpss)
> {
> resource_size_t addr = lpss->info->mem->start;
>
> - writel(addr, lpss->priv + LPSS_PRIV_REMAP_ADDR_LO);
> -#if BITS_PER_LONG > 32
> - writel(addr >> 32, lpss->priv + LPSS_PRIV_REMAP_ADDR_HI);
> -#else
> - writel(0, lpss->priv + LPSS_PRIV_REMAP_ADDR_HI);
> -#endif
> + lo_hi_writeq(addr, lpss->priv + LPSS_PRIV_REMAP_ADDR);
> }
>
> static void intel_lpss_deassert_reset(const struct intel_lpss *lpss)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/2] mfd: intel-lpss: fix build error when !CONFIG_PM_SLEEP
On Mon, 14 Sep 2015, Andy Shevchenko wrote: > Jim Davis reported the compilation error with a random configuration which > apparently has CONFIG_PM=y and CONFIG_PM_SLEEP=n. With that conditions we have > missed definition of INTEL_LPSS_SLEEP_PM_OPS macro. Add it here. > > Reported-by: Jim Davis > Signed-off-by: Andy Shevchenko > --- > drivers/mfd/intel-lpss.h | 2 ++ > 1 file changed, 2 insertions(+) Applied for -fixes. > diff --git a/drivers/mfd/intel-lpss.h b/drivers/mfd/intel-lpss.h > index f28cb28a..2c7f8d7 100644 > --- a/drivers/mfd/intel-lpss.h > +++ b/drivers/mfd/intel-lpss.h > @@ -42,6 +42,8 @@ int intel_lpss_resume(struct device *dev); > .thaw = intel_lpss_resume, \ > .poweroff = intel_lpss_suspend, \ > .restore = intel_lpss_resume, > +#else > +#define INTEL_LPSS_SLEEP_PM_OPS > #endif > > #define INTEL_LPSS_RUNTIME_PM_OPS\ -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] mfd: tps65912: Rewrite driver adding DT support and using regmap
On Tue, 15 Sep 2015, Andrew F. Davis wrote:
> The old driver does not support DT. Rewrite the driver adding DT support
> and use modern kernel features such as regmap and related helpers.
>
> Signed-off-by: Andrew F. Davis
> ---
> drivers/gpio/gpio-tps65912.c | 291 ++--
> drivers/mfd/Kconfig| 20 +-
> drivers/mfd/Makefile | 3 +-
> drivers/mfd/tps65912-core.c| 288 +---
> drivers/mfd/tps65912-i2c.c | 233 --
> drivers/mfd/tps65912-irq.c | 217 -
> drivers/mfd/tps65912-spi.c | 236 --
> drivers/regulator/tps65912-regulator.c | 783
> ++---
> include/linux/mfd/tps65912.h | 256 +++
> 9 files changed, 854 insertions(+), 1473 deletions(-)
> rewrite drivers/gpio/gpio-tps65912.c (68%)
> rewrite drivers/mfd/tps65912-core.c (96%)
> rewrite drivers/mfd/tps65912-i2c.c (92%)
> delete mode 100644 drivers/mfd/tps65912-irq.c
> rewrite drivers/mfd/tps65912-spi.c (91%)
> rewrite drivers/regulator/tps65912-regulator.c (94%)
Is there really no other way to split this up?
> diff --git a/drivers/gpio/gpio-tps65912.c b/drivers/gpio/gpio-tps65912.c
> dissimilarity index 68%
> index 9cdbc0c..a15d4e7 100644
> --- a/drivers/gpio/gpio-tps65912.c
> +++ b/drivers/gpio/gpio-tps65912.c
> @@ -1,153 +1,138 @@
> -/*
> - * Copyright 2011 Texas Instruments Inc.
> - *
> - * Author: Margarita Olaya
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License as published by the
> - * Free Software Foundation; either version 2 of the License, or (at your
> - * option) any later version.
> - *
> - * This driver is based on wm8350 implementation.
> - */
> -
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -#include
> -
> -struct tps65912_gpio_data {
> - struct tps65912 *tps65912;
> - struct gpio_chip gpio_chip;
> -};
> -
> -#define to_tgd(gc) container_of(gc, struct tps65912_gpio_data, gpio_chip)
> -
> -static int tps65912_gpio_get(struct gpio_chip *gc, unsigned offset)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> - int val;
> -
> - val = tps65912_reg_read(tps65912, TPS65912_GPIO1 + offset);
> -
> - if (val & GPIO_STS_MASK)
> - return 1;
> -
> - return 0;
> -}
> -
> -static void tps65912_gpio_set(struct gpio_chip *gc, unsigned offset,
> - int value)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> -
> - if (value)
> - tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_SET_MASK);
> - else
> - tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_SET_MASK);
> -}
> -
> -static int tps65912_gpio_output(struct gpio_chip *gc, unsigned offset,
> - int value)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> -
> - /* Set the initial value */
> - tps65912_gpio_set(gc, offset, value);
> -
> - return tps65912_set_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_CFG_MASK);
> -}
> -
> -static int tps65912_gpio_input(struct gpio_chip *gc, unsigned offset)
> -{
> - struct tps65912_gpio_data *tps65912_gpio = to_tgd(gc);
> - struct tps65912 *tps65912 = tps65912_gpio->tps65912;
> -
> - return tps65912_clear_bits(tps65912, TPS65912_GPIO1 + offset,
> - GPIO_CFG_MASK);
> -}
> -
> -static struct gpio_chip template_chip = {
> - .label = "tps65912",
> - .owner = THIS_MODULE,
> - .direction_input= tps65912_gpio_input,
> - .direction_output = tps65912_gpio_output,
> - .get= tps65912_gpio_get,
> - .set= tps65912_gpio_set,
> - .can_sleep = true,
> - .ngpio = 5,
> - .base = -1,
> -};
> -
> -static int tps65912_gpio_probe(struct platform_device *pdev)
> -{
> - struct tps65912 *tps65912 = dev_get_drvdata(pdev->dev.parent);
> - struct tps65912_board *pdata = dev_get_platdata(tps65912->dev);
> - struct tps65912_gpio_data *tps65912_gpio;
> - int ret;
> -
> - tps65912_gpio = devm_kzalloc(>dev, sizeof(*tps65912_gpio),
> - GFP_KERNEL);
> - if (tps65912_gpio == NULL)
> - return -ENOMEM;
> -
> - tps65912_gpio->tps65912 = tps65912;
> - tps65912_gpio->gpio_chip =
Re: [RESEND PATCH v4 0/8] i2c: Relax mandatory I2C ID table passing
On Thu, 17 Sep 2015, Javier Martinez Canillas wrote: > Hello, > > On 09/11/2015 01:55 PM, Kieran Bingham wrote: > > Hi Wolfram, > > > > I have picked this patchset [0] up from Lee to rebase it, with an aim to > > get this series moving again. > > > > This resend fixes up my SoB's as highlighted by Lee > > > > A couple of minor issues were resolved in the rebase. As it stood, Javier > > proposed [1] to merge this series, and use a follow up series to make sure > > that all I2C drivers are using a MODLE_DEVICE_TABLE(of,...) > > > > I have prepared a Coccinelle patch to work through the bulk of the changes > > required for the conversion, which will assist the transition process. > > > > Once this patch set is accepted, I will commence converting the other > > drivers, and submitting with a per subsystem breakdown or simliar to > > reduce traffic. > > > > [0] https://lkml.org/lkml/2014/8/28/283 > > [1] https://lkml.org/lkml/2014/9/12/496 > > > > Lee's most recent cover-letter (from 12 months ago) follows: > > > > Hi Wolfram, > > > > Placing this firmly back on your plate. I truly hope we don't miss > > another merge-window. This patch-set has the support of some pretty > > senior kernel maintainers, so I hope acceptance shouldn't be too > > difficult. > > > > As previously discussed I believe it should be okay for an I2C device > > driver _not_ supply an I2C ID table to match to. The I2C subsystem > > should be able to match via other means, such as via OF tables. The > > blocking factor during our previous conversation was to keep > > registering via sysfs up and running. This set does that. > > > > After thinking more deeply about the problem, it occurred to me that > > any I2C device driver which uses the sysfs method and issues an > > of_match_device() would also fail their probe(). Bolted on to this > > set is a new, more generic way for these devices to match against > > either of the I2C/OF tables. > > > > I reviewed this series but wonder if we shouldn't take another approach. > > There are two reasons why a I2C device ID table is needed even when devices > are registered via OF: > > 1) Export the module aliases from the I2C device ID table so userspace >can auto-load the correct module. This is because i2c_device_uevent >always reports a MODALIAS of the form i2c:name>. > > 2) Match the I2C client with a I2C device ID so a struct i2c_device_id >is passed to the I2C driver probe() function. > > As Kieran mentioned I proposed a transition path to fix 1) and posted > these patches: https://lkml.org/lkml/2015/7/30/519 > > While this series are fixing 2) by changing the matching logic and adding > a second probe callback for drivers that don't need to get a i2c_device_id. > > Now, the problem I see with this approach is that drivers will likely want > to get the struct of_device_id .data field since that is the reason why > the I2C core pass a pointer to the struct i2c_device_id in the first place. > So drivers could get the .driver_data field and take decisions depending on > which device was registered / matched. > > If the parameter is removed from probe, it means that drivers will have to > to open code to get it. This is the same issue that exist with OF today, if > a driver needs the .data field from the of_device_id table, is has to do: > > struct of_device_id *match of_match_node(of_match_table, i2c->dev.of_node); > > to get the match->data. And a similar helper will be needed to get the > struct i2c_device_id since the core won't do it anymore. > > So what I propose is to change the probe callback signature instead to have > a const void *data as the second parameter and the core can either lookup > from the I2C device ID table or the OF device ID table depending on which > mechanism was used to register the I2C device. > > That way legacy drivers will only need a I2C device ID table and DT drivers > will only need a OF device ID table and drivers won't need to open code the > matching logic to get the data stored in the tables. > > Drivers that support both legacy platform and OF based registration, will > have both tables and the I2C core will lookup the data from the right table. > > An alternative is to keep this series but have a generic function that gets > a pointer to a struct i2c_client as parameter and returns the data from the > correct table so drivers that don't need that information won't get it at > probe time but drivers that need it, can get it easily assisted by the core. You mean like i2c_match_id()? ;) This patch already takes care of this issue. Please see: i2c: Export i2c_match_id() for direct use by device drivers Drivers will know if they either only supply an I2C or OF table, so they will know which call to use in order to obtain their .driver_data|.data. attributes. We can generify the call if you think that makes things easier, but I don't see a need for it ATM. > Both options are similar, the question is if the I2C
Re: [PATCH 00/14] ARM: dts: apq8064 dt cleanups and additions
On Fri, Sep 18, 2015 at 01:29:31PM +0100, Srinivas Kandagatla wrote: > Hi Andy, > > Here are few cleanup and additions to the existing APQ8064 device tree. > > Some of the patches are to do with princtrl cleanup which was always not > in the right place and some of the pinctrls were missing. > Other set of patches is to do with adding more devices like rtc rng > and pwr key for pmic 8921. > Last set of patches are related to pwrseq and SD card detect taking Stephens > comments into consideration. These all look fine. I tested in ifc6410 as well. I'll test on qs600 to be sure. -- Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: First kernel patch (optimization)
On Sat, Sep 19, 2015 at 07:47:22PM +0200, Alexander Holler wrote: > No. I don't want to lower the standards. Maybe in regard to silly style > stuff, but not in regard to code quality (and I mean real bugs like races, > deadlocks or such, and not if a line has more than 80 characters). I would > have liked some comments like "good or bad idea" but this list is imho the > wrong place to search for such useful comments. I haven't searched for > comments on the code, as I was FULLY aware that the code is ugly and NOT > ready for inclusion), That was asked and answered on the original thread, but perhaps it got lost amongst some of the noise --- some of which was contributed by yourself, but be that as it may. The *feature* is in and of itself not an insane idea. "Secure delete" is something that Linux has had before (in fact I did the original implementation for ext2 a decade+ ago), and indeed the interface, using the FS_SECRM_FL flag, is still present in Linux even if it is not supported by any of the file systems in the tree at the moment. It got ripped out because doing it right in the face of ongoing interface changes and performance improvements (going back to the pre-2.0, and possibly the pre-1.2 days), it was simpler to rip it out rather than to reimplement it. I wasn't responsible for ripping it out, back in mists of pre-history, but I didn't care enough to reimplement it --- or complain about it, either. And no one else cared enough to complain to Linus about this being a user-visible change that broke them. So it's a great example of how a feature and functionality that no one cares about *can* get ripped out of the kernel. Perhaps not so surprisingly, over a decade later, it is not currently at the top of the priority list of any of the current file system or VFS developers, as far as I know. One of the reasons for that is that there are a number of other ways of achieving the same functionality. These include using tmpfs, or using file system level encryption. They require a bit more system administrator setup than just being able to set the FS_SECR_FL flag, true, but just because it's more convenient doesn't mean that it's worth doing. So this is a feature request. It's a reasonable feature request, in that if someone would like to pay $$$ for some consultant to implement it in a way that is bug-free, I suspect it could go upstream. Someone who was very motivated and with the sufficient skills could also invest their own effort to make a patch that can go upstream too. You've elected not, to because you believe it would take you months of "unpaid time". That's purely within your rights to do. But you don't have the right to try to tell other people what work to do on their behalf --- not unless you are paying their salary. And of course, if you want to maintain an out-of-tree patch, there's nothing wrong with that. I've implemented code that has never gone upstream because the weight of the other file system developers were afraid that Enterise Linux customers would use the feature incorrectly, and it would cause potentially cause a security failure if used inappropriately, which would be a PR and support nightmare for them. Seeing that the weight of the other file system developers are against the patch, it's never gone into the mainline Linux kernel, even though I could have forced the feature into ext4. However, this patch is in active use in practically every single data center kernel for Google, and it's in use in at least one other very large publically traded company that uses cluster file systems such as Hadoopfs. And if someone wants a copy of the FALLOC_FL_NO_HIDE_STALE patch for ext4, I'm happy to give it to them. But it hasn't gone upstream, and I'm OK with that. As far as what you want to do next, you have a personal "proof of concept" patch that seems to work well enough for you. Great! I'm sure you can keep using it for your own purposes. If you can convince someone with the skills to get the patch to an upstreamable state, it is my judgement that this is doable, so this puts your feature in a much better state than the FALLOC_FL_NO_HIDE_STALE flag. However, there is still a non-trivial amount of work left to do to turn your "proof of concept" patch into something that is upstremable, including changing the interface to using the FS_SECRM_FL flag. And your whining that other people should change *their* priorities to match *yours* is not likely to help. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] iommu: enable the last bit in iommu_area_alloc()
In 'commit a66022c45775 ("iommu-helper: use bitmap library")',
iommu_area_alloc() uses bitmap_find_next_zero_area() to lookup available
iommu space.
When given "start, size, nr", bitmap_find_next_zero_area() is looking for a
range with nr zero bit in [start, size) instead of [start, size]. This
means the last bit is already excluded. By decrease size at the beginning,
the last iommu page will not be allocated.
This patch removes the decrease on size.
Signed-off-by: Wei Yang
---
I may missed something, while the code makes me a little confused.
I found two users of iommu_area_alloc(), one in powernv platform and one in
lib/iommu-common.c. The "limit", which is passed to
bitmap_find_next_zero_area() as the "size" are both set to pool->end in these
two cases. While the pool->end in these two cases are calculated differently.
On powernv platform, iommu_init_table() sets
p->end = p->start + tbl->poolsize;
While in iommu_tbl_pool_init(),
pools[i].end = pools[i].start + iommu->poolsize -1;
In both case, it will not do harm to system, except we have one more less
iommu page in the second case.
And then in current code, iommu_area_alloc() will decrease the size by one
again.
I may missed something, currently I think the implementation in powernv
platform is correct while iommu_area_alloc() eats the last iommu page.
Tests:
I have apply this on top of v4.2 and enforce to use dma_iommu_ops for each
device. Transfered on guest image with 4GB by scp and check the checksum are
the same.
---
lib/iommu-helper.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
index c27e269..2866004 100644
--- a/lib/iommu-helper.c
+++ b/lib/iommu-helper.c
@@ -23,8 +23,6 @@ unsigned long iommu_area_alloc(unsigned long *map, unsigned
long size,
{
unsigned long index;
- /* We don't want the last of the limit */
- size -= 1;
again:
index = bitmap_find_next_zero_area(map, size, start, nr, align_mask);
if (index < size) {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 02/26] clk: Replace __clk_get_num_parents with clk_hw_get_num_parents()
On Fri, 2015-09-18 at 16:18 -0700, Stephen Boyd wrote: > On 09/18, Scott Wood wrote: > > On Fri, 2015-09-18 at 08:56 -0700, Stephen Boyd wrote: > > > Is there any reason why we can't use DT OPPs for the code that > > > you're patching here? At a quick glance it looks like we could > > > leave this driver behind and move to cpufreq-dt.c and then use > > > OPPs to populate the possible frequencies and affinity. > > > > One reason is that I want to maintain compatibility with existing device > > trees. > > > > However, even ignoring that, cpufreq-dt doesn't seem like a good fit. It > > requires specifying voltage, which is beyond the scope of the DFS > > mechanism > > on these chips. > > Hm.. cpufreq-dt doesn't mandate voltage setting. Maybe I'm > reading the code wrong though. I was referring to the device tree binding, but didn't look far enough to see the v2 binding. > > It also requires assembling a list of valid frequencies in the device > > tree, > > which is not knowable at compile-time as it depends on how PLLs were > > configured in the reset control words, and in some cases the revision of > > the > > SoC due to errata -- and even if that information were constant, it would > > be > > extra maintenance work to keep the redundant information accurate, and if > > errors were introduced into the device tree we'd have the same sort of > > compatibility problems I'm trying to fix with > > http://patchwork.ozlabs.org/patch/507621/ > > > > Ok, fair enough. The v2 bindings for OPPs are still progressing > and they're moving towards a way to consolidate data that might > work here. I'm not sure though, Viresh is probably better to ask. If you mean operating-points-v2, based on the current binding document, I'm not sure how that addresses the above issues. > Just one more final thought, but what if the clock provider > populated the OPPs for the CPU devices and the cpufreq-dt was > used? I don't know how the code is structured or if this QorIQ > clock controller is used for more than just CPU clocks, but that > may be another option where provider APIs are available. I'm not sure how to do that, and it's not clear what the benefit would be on this hardware. Pretty much all we need the cpufreq driver to do is to look at a clock with multiple parents, and select from the options that are available. -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP
On Sat, Sep 19, 2015 at 10:21:45AM +0100, Lee Jones wrote: > > That's not how it works. It's helpful, more often than not, to submit > the entire set to each maintainer concerned so they can keep up with > the general conversation. By only sending specific patches to > maintainers you essentially blinker them to the bigger picture. > > As a maintainer you should _know_ that you can't apply patches from > other subsystems without appropriate Acks. I'm sure you'd take > exception to another maintainer who started accepting patches for > subsystems you are responsible for. This works both ways. No you are mistaken. You should only put patches which have dependencies on each other in a series. If the patches can be applied independently of each other there is no need to have them in a single series. Obviously if they can go into different trees then they cannot have dependencies. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: comedi: Fix coding style issues
On 09/19/2015 01:13 PM, punit vara wrote: [PATCH] Staging: comedi: Fix block comment warning [PATCH] Staging: comedi: Coding style warnings fix for block comments -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] char: ipmi: Move MODULE_DEVICE_TABLE() to follow struct
Ok, queued for 4.4.
Thanks,
-corey
On 09/19/2015 10:43 AM, Luis de Bethencourt wrote:
> The policy for drivers is to have MODULE_DEVICE_TABLE() just after the
> struct used in it. For clarity.
>
> Suggested-by: Corey Minyard
> Signed-off-by: Luis de Bethencourt
> ---
>
> Suggested in:
> https://lkml.org/lkml/2015/9/18/842
>
> Thanks Corey,
> Luis
>
> drivers/char/ipmi/ipmi_si_intf.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/char/ipmi/ipmi_si_intf.c
> b/drivers/char/ipmi/ipmi_si_intf.c
> index 654f6f3..061fef0 100644
> --- a/drivers/char/ipmi/ipmi_si_intf.c
> +++ b/drivers/char/ipmi/ipmi_si_intf.c
> @@ -2560,6 +2560,7 @@ static const struct of_device_id of_ipmi_match[] = {
> .data = (void *)(unsigned long) SI_BT },
> {},
> };
> +MODULE_DEVICE_TABLE(of, of_ipmi_match);
>
> static int of_ipmi_probe(struct platform_device *dev)
> {
> @@ -2646,7 +2647,6 @@ static int of_ipmi_probe(struct platform_device *dev)
> }
> return 0;
> }
> -MODULE_DEVICE_TABLE(of, of_ipmi_match);
> #else
> #define of_ipmi_match NULL
> static int of_ipmi_probe(struct platform_device *dev)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/5] regulator: smd: Add floor and corner operations
On Fri, Sep 18, 2015 at 05:52:05PM -0700, Stephen Boyd wrote: > +EXPORT_SYMBOL(qcom_rpm_set_floor); The entire regulator API is EXPORT_SYMBOL_GPL(), adding plain EXPORT_SYMBOL() exports is not good. signature.asc Description: Digital signature
Re: [PATCH 0/3] regulator: Fix module autoload for OF platform driver
On Fri, Sep 18, 2015 at 07:08:48PM +0200, Luis de Bethencourt wrote: > Hi, > > These patches add the missing MODULE_DEVICE_TABLE() for OF to export > the information so modules have the correct aliases built-in and > autoloading works correctly. As I am fairly sure has been suggested before please try to thread patch serieses into a single mail thread (git send-email handles this automatically). This makes things much easier to follow in mail readers. signature.asc Description: Digital signature
Re: [PATCH v2 0/5] Support CPR on MSM8916
On Fri, Sep 18, 2015 at 05:52:04PM -0700, Stephen Boyd wrote: > This patch series adds support for CPR on MSM8916. The first > patch exposes a corner voting API to the CPR driver so that we can You might want to expand on the acronym CPR since I'm reasonably sure that you don't in fact mean the normal expansion cardiopulmonary resuscitation. signature.asc Description: Digital signature
Re: [PATCH v6 1/3] regmap: add generic macro to define regmap_irq
On Tue, Sep 15, 2015 at 12:39:17AM +0800, Qipeng Zha wrote: > Add REGMAP_IRQ_REG macro in regmap.h to define regmap_irq > structure easily for other driver module. Acked-by: Mark Brown signature.asc Description: Digital signature
Re: [PATCH 1/3] ASoC: codecs: Add da7219 codec driver
On Thu, Sep 17, 2015 at 05:01:14PM +0100, Adam Thomson wrote:
> + do {
> + statusa = snd_soc_read(codec, DA7219_ACCDET_STATUS_A);
> + if (statusa & DA7219_MICBIAS_UP_STS_MASK)
> + micbias_up = true;
> + } while (!micbias_up);
This could go into an inifinite loop.
> +static void da7219_aad_hptest_work(struct work_struct *work)
> +{
> + struct da7219_aad_priv *da7219_aad =
> + container_of(work, struct da7219_aad_priv, hptest_work);
> + struct snd_soc_codec *codec = da7219_aad->codec;
> + struct da7219_priv *da7219 = snd_soc_codec_get_drvdata(codec);
> +
> + u8 tonegen_cfg1, tonegen_cfg2, tonegen_onper;
> + u16 tonegen_freq1, tonegen_freq_hptest;
> + u8 hpl_gain, hpr_gain, dacl_gain, dacr_gain, dac_filters1, dac_filters4;
> + u8 dac_filters5, cp_ctrl, routing_dac, dacl_ctrl, dacr_ctrl;
> + u8 mixoutl_sel, mixoutr_sel, st_outfilt_1l, st_outfilt_1r;
> + u8 mixoutl_ctrl, mixoutr_ctrl, hpl_ctrl, hpr_ctrl, accdet_cfg8;
> + int report = 0;
> +
> + /* Save current settings */
This is obviously a massive reconfiguration of the device. I'm not
seeing anything here which prevents userspace coming in and change the
configuration while we're in this function, that would obviously have
serious issues.
I'm also wondering if this might be more elegantly implemented by going
into cache bypass mode, doing the test and then using a cache resync to
restore the initial configuration. That will at least avoid issues with
updates adding a new register but not modifying it.
> + if (statusa & DA7219_JACK_TYPE_STS_MASK) {
> + report |= SND_JACK_HEADSET;
> + mask |= SND_JACK_HEADSET | SND_JACK_LINEOUT;
> + schedule_work(_aad->btn_det_work);
> + } else {
> + schedule_work(_aad->hptest_work);
> + }
Why are we scheduling work - we're already in thread context?
> + /* Un-drive headphones/lineout */
> + snd_soc_update_bits(codec, DA7219_HP_R_CTRL,
> + DA7219_HP_R_AMP_OE_MASK, 0);
> + snd_soc_update_bits(codec, DA7219_HP_L_CTRL,
> + DA7219_HP_L_AMP_OE_MASK, 0);
This looks like DAPM?
> +static enum da7219_aad_jack_ins_deb da7219_aad_of_jack_ins_deb(u32 val)
> +{
> + switch (val) {
> + case 5:
> + return DA7219_AAD_JACK_INS_DEB_5MS;
> + case 10:
> + return DA7219_AAD_JACK_INS_DEB_10MS;
> + case 20:
> + return DA7219_AAD_JACK_INS_DEB_20MS;
> + case 50:
> + return DA7219_AAD_JACK_INS_DEB_50MS;
> + case 100:
> + return DA7219_AAD_JACK_INS_DEB_100MS;
> + case 200:
> + return DA7219_AAD_JACK_INS_DEB_200MS;
> + case 500:
> + return DA7219_AAD_JACK_INS_DEB_500MS;
> + case 1000:
> + return DA7219_AAD_JACK_INS_DEB_1S;
> + default:
> + return DA7219_AAD_JACK_INS_DEB_20MS;
This isn't an error?
> +/* Input/Output Enums */
> +static const char * const da7219_gain_ramp_rate_txt[] = {
> + "nominal rate * 8", "nominal rate", "nominal rate / 8",
> + "nominal rate / 16"
> +};
The ALSA ABI generally capitalises words.
> +/* ToneGen */
> +static int da7219_tonegen_freq_get(struct snd_kcontrol *kcontrol,
> +struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
> + struct da7219_priv *da7219 = snd_soc_codec_get_drvdata(codec);
> + struct soc_mixer_control *mixer_ctrl =
> + (struct soc_mixer_control *) kcontrol->private_value;
> + unsigned int reg = mixer_ctrl->reg;
> + u16 val;
> + int ret;
> +
> + ret = regmap_bulk_read(da7219->regmap, reg, , sizeof(val));
> + if (ret)
> + return ret;
> +
> + ucontrol->value.integer.value[0] = le16_to_cpu(val);
This is *weird*. We do a bulk read for a single register using an API
that returns CPU endian data then make it CPU endian (without any
annotations on variables...). Why not use regmap_read()? Why swap?
Why not use raw I/O?
> +static int da7219_hpf_put(struct snd_kcontrol *kcontrol,
> + struct snd_ctl_elem_value *ucontrol)
> +{
> + struct snd_soc_codec *codec = snd_soc_kcontrol_codec(kcontrol);
> + struct soc_enum *enum_ctrl = (struct soc_enum *)kcontrol->private_value;
> + unsigned int reg = enum_ctrl->reg;
> + unsigned int sel = ucontrol->value.integer.value[0];
> + unsigned int bits;
> +
> + switch (sel) {
> + case DA7219_HPF_MODE_DISABLED:
> + bits = DA7219_HPF_DISABLED;
> + break;
> + case DA7219_HPF_MODE_AUDIO:
> + bits = DA7219_HPF_AUDIO_EN;
> + break;
> + case
Re: [alsa-devel] System with multiple arizona (wm5102) codecs
On Tue, Sep 15, 2015 at 08:26:36AM -0700, Caleb Crome wrote: > > Like Charles said earlier the Bells machine in mainline has multiple > > CODECs hooked up. Speyside too. To hook up multiple CODECs to a single > > DAI link see 88bd870f02dff5c94 (ASoC: core: Add initial support for DAI > > multicodec), sadly I don't think Benoit ever got round to submitting a > > machine. > Thanks Mark. > I've been staring at that diff for a a day or two, and I still can't > quite figure out how to use it. > I think I'm getting close: all codecs are registered, the DAPM stuff > seems to be connected (all with prefixed names), but the card won't > open more than a 2 channel interface. > For example, when I do aplay -l, I get this: > List of PLAYBACK Hardware Devices > card 0: PUPPYAUDIO [PUPPY-AUDIO], device 0: AIC3X tlv320aic3x-hifi-0 [] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: PUPPYAUDIO [PUPPY-AUDIO], device 1: AIC3X tlv320aic3x-hifi-1 [] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: PUPPYAUDIO [PUPPY-AUDIO], device 2: AIC3X tlv320aic3x-hifi-2 [] > Subdevices: 1/1 > Subdevice #0: subdevice #0 > card 0: PUPPYAUDIO [PUPPY-AUDIO], device 3: AIC3X tlv320aic3x-hifi-3 [] > Subdevices: 1/1 > Subdevice #0: subdevice #0 That doesn't look entirely like what I'd expect... I'd epect to see one DAI presented to userspace. Indeed looking through your diff I don't see any usage of struct snd_soc_dai_link_component as described in the changelog for the change I pointed you at. I'd expect to see one DAI link with a bunch of those hanging off it giving a single DAI to aplay. OTOH I'm not sure it's going to work as I'm not immediately seeing how we handle the ability to have more capabilities than an individual device (based on the changelog I suspect the original use case may have been two mono I2S devices which have stereo interfaces even if they only pay attention to one channel on themm). But let's at least get everything appearing as one DAI first before we move on to worrying about that, I didn't check thoroughly yet. signature.asc Description: Digital signature
Re: [PATCH 1/3] mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO regulators
On Wed, Sep 16, 2015 at 11:05:30AM +0800, Chen-Yu Tsai wrote: > The DC1SW and DC5LDO regulators in the AXP221 are internally chained > to DCDC1 and DCDC5, hence the names. The original bindings used the > parent regulator names for the supply regulator property. This causes > some confusion when we actually use it in the dts: If these regulators are internally always connected to other regulators in the same device why are we even representing their supplies in DT? signature.asc Description: Digital signature
[PATCH 3/3] regmap: debugfs: Remove scratch buffer for register length calculation
Now we no longer use the scratch buffer for register length calculation
there is no need for callers to supply one.
Signed-off-by: Mark Brown
---
drivers/base/regmap/regmap-debugfs.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 4c55cfb..4a47378 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -30,7 +30,7 @@ static LIST_HEAD(regmap_debugfs_early_list);
static DEFINE_MUTEX(regmap_debugfs_early_lock);
/* Calculate the length of a fixed format */
-static size_t regmap_calc_reg_len(int max_val, char *buf, size_t buf_size)
+static size_t regmap_calc_reg_len(int max_val)
{
return snprintf(NULL, 0, "%x", max_val);
}
@@ -173,8 +173,7 @@ static inline void regmap_calc_tot_len(struct regmap *map,
{
/* Calculate the length of a fixed format */
if (!map->debugfs_tot_len) {
- map->debugfs_reg_len = regmap_calc_reg_len(map->max_register,
- buf, count);
+ map->debugfs_reg_len = regmap_calc_reg_len(map->max_register),
map->debugfs_val_len = 2 * map->format.val_bytes;
map->debugfs_tot_len = map->debugfs_reg_len +
map->debugfs_val_len + 3; /* : \n */
@@ -420,7 +419,7 @@ static ssize_t regmap_access_read_file(struct file *file,
return -ENOMEM;
/* Calculate the length of a fixed format */
- reg_len = regmap_calc_reg_len(map->max_register, buf, count);
+ reg_len = regmap_calc_reg_len(map->max_register);
tot_len = reg_len + 10; /* ': R W V P\n' */
for (i = 0; i <= map->max_register; i += map->reg_stride) {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] regmap: debugfs: Ensure we don't underflow when printing access masks
If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.
Reported-by: Rasmus Villemoes
Signed-off-by: Mark Brown
Cc: sta...@vger.kernel.org
---
drivers/base/regmap/regmap-debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index f42f2ba..1f32789 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -432,7 +432,7 @@ static ssize_t regmap_access_read_file(struct file *file,
/* If we're in the region the user is trying to read */
if (p >= *ppos) {
/* ...but not beyond it */
- if (buf_pos >= count - 1 - tot_len)
+ if (buf_pos + tot_len + 1 >= count)
break;
/* Format the register */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: spi-imx: wait_for_completion should timeout even in non-DMA transfer cases
On Fri, Sep 18, 2015 at 02:38:27PM +0200, Jean-Michel Hautbois wrote: > Hi, > > I am wondering why in spi-imx the spi_imx_pio_transfer() function is > calling wait_for_completion() and not wait_for_completion_timeout() as > in the spi_imx_dma_transfer() one. > I can't see a good reason for this, maybe should it be calculated > based on the spi clock and transfer->len, or at least be the same as > IMX_DMA_TIMEOUT which is 3 seconds ? > If you want it, I have a patch, just tell me if you are interested and > if you prefer a calculated timeout or even something else ? A calculated timeout is probably best. signature.asc Description: Digital signature
Re: [PATCH 02/16] PM / OPP: Add 'opp-microvolt-triplets' binding
On Tue, Sep 15, 2015 at 09:00:27AM +0530, Viresh Kumar wrote:
> [+Cc Mark, I thought I cc'd him earlier, but no, I cc'd him only for
> the first patch]
I'm reading this on a plane so have no other context and to be honest
I'm struggling to understand what is being discussed here. It would be
really helpful if you were to describe in words what proposed bindings
are intended to do as well as presenting examples, the examples by
themselves require the reader to reverse engineer what the semantics are
intended to be.
> But if we can define something like:
> supply0: regulator@f800 {
> regulator-cells or microvolt-cells = 1 or 3;
> ...
> }
As far as I can tell this is proposing adding something to the regulator
binding specifying if users must present either a single value or a
min/target/max triplet. This is obviously problematic since regulators
can be shared - the needs of one user may not match the needs of another
user, and of course most users should not be specifying voltages at all
in the device tree in the first place.
signature.asc
Description: Digital signature
Re: [PATCH] ARM: pxa: Remove unused clock_enable field from struct pxa2xx_spi_master
On Fri, Sep 18, 2015 at 10:14:41AM +0300, Jarkko Nikula wrote:
> Use for struct pxa2xx_spi_master clock_enable field was removed years ago
> from the pxa2xx-spi driver by the commit 2f1a74e5a2de ("[ARM] pxa: make
> pxa2xx_spi driver use ssp_request()/ssp_free()").
Acked-by: Mark Brown
signature.asc
Description: Digital signature
Re: [PATCH v5 07/23] regulator: core: Remove regulator_list
On Thu, Sep 17, 2015 at 02:57:01PM +0200, Tomeu Vizoso wrote: > As we are already registering a device with regulator_class for each > regulator device, regulator_list is redundant and can be replaced with > calls to class_find_device() and class_for_each_device(). This appears to leak references to the struct devices returned by class_find_device() - it takes a reference before it returns so any device found using class_find_device() needs to be released with put_device() and I don't see any new put_device() calls in here. > Changes in v5: None > Changes in v4: None > Changes in v3: None > Changes in v2: None This is not the case at all, this patch was newly added. If you want to include changelogs like this in the patch description try to ensure that they bear some relationship to reality, if they don't they are actively harmful as they are likely to mislead or annoy the reader. signature.asc Description: Digital signature
[PATCH 2/3] regmap: debugfs: Don't bother actually printing when calculating max length
The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.
Reported-by: Rasmus Villemoes
Signed-off-by: Mark Brown
Cc: sta...@vger.kernel.org
---
drivers/base/regmap/regmap-debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 1f32789..4c55cfb 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -32,8 +32,7 @@ static DEFINE_MUTEX(regmap_debugfs_early_lock);
/* Calculate the length of a fixed format */
static size_t regmap_calc_reg_len(int max_val, char *buf, size_t buf_size)
{
- snprintf(buf, buf_size, "%x", max_val);
- return strlen(buf);
+ return snprintf(NULL, 0, "%x", max_val);
}
static ssize_t regmap_name_read_file(struct file *file,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ASoC: da7219: Add bindings documentation for DA7219 audio codec
On Thu, Sep 17, 2015 at 05:01:16PM +0100, Adam Thomson wrote: > +- dlg,io-lvl : Expected voltage level range for digital IO > + ["2.5V_3.6V", "1.2V_2.8V"] If the driver needs to read or set the voltage a supply is at it should do that via the regulator API. > +- dlg,cp-mchange : Charge pump voltage tracking mode > + ["largest_vol", "dac_vol", "sig_mag"] > +- dlg,cp-vol-thresh : Charge pump volume threshold value (6-bit value) > + [ 0 - 0x3F ] Why are these in the device tree rather than runtime parameters? > +Child node - 'da7219_aad': > + > +Required properties: > +- interrupt-parent : Specifies the phandle of the interrupt controller to > which > + the IRQs from DA7219 AAD block are delivered to. > +- interrupts : IRQ line info for DA7219 AAD block. > + (See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt > for > + further information relating to interrupt properties) Why is this not specified at the device level (the device does not appear to support other interrupts)? signature.asc Description: Digital signature
Re: [PATCH 2/3] mfd: tps65912: Rewrite driver adding DT support and using regmap
On Tue, Sep 15, 2015 at 12:57:40PM -0500, Andrew F. Davis wrote: > The old driver does not support DT. Rewrite the driver adding DT support > and use modern kernel features such as regmap and related helpers. > > Signed-off-by: Andrew F. Davis > --- > drivers/gpio/gpio-tps65912.c | 291 ++-- > drivers/mfd/Kconfig| 20 +- > drivers/mfd/Makefile | 3 +- > drivers/mfd/tps65912-core.c| 288 +--- > drivers/mfd/tps65912-i2c.c | 233 -- > drivers/mfd/tps65912-irq.c | 217 - > drivers/mfd/tps65912-spi.c | 236 -- > drivers/regulator/tps65912-regulator.c | 783 > ++--- > include/linux/mfd/tps65912.h | 256 +++ > 9 files changed, 854 insertions(+), 1473 deletions(-) It's not OK to have a single commit that rewrites multiple drivers over many subsystems, that's really not something that can be sensibly reviewed. You should split this into a patch series which makes one specific change at a time as covered in SubmittingPatches. That will allow the changes to be reviewed much more sensibly. signature.asc Description: Digital signature
Re: [PATCH 4.2 000/120] 4.2.1-stable review
On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.2.1 release. There are 120 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Sep 21 17:15:44 UTC 2015. Anything received after that time might be too late. Build results: total: 144 pass: 143 fail: 1 Failed builds: arm:allmodconfig Qemu test results: total: 93 pass: 83 fail: 10 Failed tests: arm:beagle:multi_v7_defconfig:omap3-beagle arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm arm:overo:multi_v7_defconfig:omap3-overo-tobi arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702 arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706 arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310 mips:fuloong2e_defconfig Same problems as with 4.1. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 000/102] 4.1.8-stable review
On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.1.8 release. There are 102 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Sep 21 17:15:55 UTC 2015. Anything received after that time might be too late. Build results: total: 137 pass: 136 fail: 1 Failed builds: arm:allmodconfig Qemu test results: total: 93 pass: 83 fail: 10 Failed tests: arm:beagle:multi_v7_defconfig:omap3-beagle arm:beaglexm:multi_v7_defconfig:omap3-beagle-xm arm:overo:multi_v7_defconfig:omap3-overo-tobi arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9 arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1 arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc702 arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zc706 arm:xilinx-zynq-a9:multi_v7_defconfig:zynq-zed arm:smdkc210:multi_v7_defconfig:exynos4210-smdkv310 mips:fuloong2e_defconfig The new failures are all caused by a single new build failure. arch/arm/mach-rockchip/platsmp.c: In function 'rockchip_boot_secondary': arch/arm/mach-rockchip/platsmp.c:155:3: error: 'rockchip_secondary_startup' undeclared Caused by 'ARM: rockchip: fix the CPU soft reset'. The qemu test problem with 'mips:fuloong2e_defconfig' has still not been fixed upstream. Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genirq: Fix bad IRQ_ONSHOT in forced IRQ setting
From: Thomas Gleixner Date: Sat, 19 Sep 2015 22:24:15 +0200 > No, we can't. We can only do that if the interrupt is not shared. > Assume the following scenario: >request_irq(irq, handler, IRQF_SHARED, "devA", devidA); > In case of force threading that sets the oneshot flag for the irq > descriptor. > Now the sdhci driver is initialized >request_thread_irq(irq, handler, thandler, IRQF_SHARED, > "sdhci", devidSDHCI); > The oneshot flag sticks and you run into exactly the same issue as > now. > Shared interrupts are a major pain, but we have to deal with them. > I'm working on a solution for that issue. > > Thanks, > tglx I understood. If you could prepare the patch, I can try it. Thanks, Kohji Okuno -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 00/29] 3.14.53-stable review
On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.53 release. There are 29 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Sep 21 17:18:53 UTC 2015. Anything received after that time might be too late. Build results: total: 127 pass: 127 fail: 0 Qemu test results: total: 80 pass: 80 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/20] 3.10.89-stable review
On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.89 release. There are 20 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Sep 21 17:16:03 UTC 2015. Anything received after that time might be too late. Build results: total: 121 pass: 121 fail: 0 Qemu test results: total: 70 pass: 70 fail: 0 Details are available at http://server.roeck-us.net:8010/builders. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] powerpc/device-tree: bindings for DSP cores/clusters for Freescale SOCs
On Sat, 2015-09-19 at 23:46 +0530, Poonam Aggrwal wrote: > From: poonam aggrwal > > Device Tree Bindings for DSP CPU clusters and DSP CPUs for Freescale PowerPC > SOCs which have DSP CPUs in addition to PowerPC CPUs. > For example B4860 has 3 DSP clusters which have 2 SC3900 cores each. > > Signed-off-by: Poonam Aggrwal > --- > - based of: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git > branch master > > This patch was sent earlier and some comments were received. Some have been > taken care; others we can further discuss. Apologize for not following up > on them in time. > .../devicetree/bindings/powerpc/fsl/dsp-cpus.txt | 78 > ++ > 1 file changed, 78 insertions(+) > create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/dsp- > cpus.txt > > diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > new file mode 100644 > index 000..6d901ef > --- /dev/null > +++ b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt > @@ -0,0 +1,78 @@ > +=== > +Binding for DSP CPU clusters and DSP CPUs for Freescale SOCs which > +have DSP CPUs in addition to PowerPC cpus. > +Copyright 2013 Freescale Semiconductor Inc. > + > +Power Architecture CPUs in Freescale SOCs are represented in device trees > as > +per the definition in ePAPR. > + > +Required properties for DSP CPU cluster: > +- compatible : should be "fsl,sc3900-cluster". > +- reg : should contain the cluster index > + > +Required properties for DSP CPU: > +- compatible : should be "fsl,sc3900". > +- reg : should contain index of DSP CPU within the DSP clsuter. > +- next-level-cache : should point to the phandle of the next-level L2 > cache. Why is the dsp-clusters container only shown in the example, not the binding itself? -Scott -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Applied "regmap: debugfs: Ensure we don't underflow when printing access masks" to the regmap tree
The patch
regmap: debugfs: Ensure we don't underflow when printing access masks
has been applied to the regmap tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From b763ec17ac762470eec5be8ebcc43e4f8b2c2b82 Mon Sep 17 00:00:00 2001
From: Mark Brown
Date: Sat, 19 Sep 2015 07:00:18 -0700
Subject: [PATCH] regmap: debugfs: Ensure we don't underflow when printing
access masks
If a read is attempted which is smaller than the line length then we may
underflow the subtraction we're doing with the unsigned size_t type so
move some of the calculation to be additions on the right hand side
instead in order to avoid this.
Reported-by: Rasmus Villemoes
Signed-off-by: Mark Brown
Cc: sta...@vger.kernel.org
---
drivers/base/regmap/regmap-debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index f42f2ba..1f32789 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -432,7 +432,7 @@ static ssize_t regmap_access_read_file(struct file *file,
/* If we're in the region the user is trying to read */
if (p >= *ppos) {
/* ...but not beyond it */
- if (buf_pos >= count - 1 - tot_len)
+ if (buf_pos + tot_len + 1 >= count)
break;
/* Format the register */
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Applied "regulator: gpio: Fix module autoload for OF platform driver" to the regulator tree
The patch
regulator: gpio: Fix module autoload for OF platform driver
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 2f9481e7dc0d3aacbaa07701f3ee2527f5d48301 Mon Sep 17 00:00:00 2001
From: Luis de Bethencourt
Date: Fri, 18 Sep 2015 19:09:24 +0200
Subject: [PATCH] regulator: gpio: Fix module autoload for OF platform driver
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt
Signed-off-by: Mark Brown
---
drivers/regulator/gpio-regulator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/gpio-regulator.c
b/drivers/regulator/gpio-regulator.c
index 464018d..7bba8b7 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -394,6 +394,7 @@ static const struct of_device_id regulator_gpio_of_match[]
= {
{ .compatible = "regulator-gpio", },
{},
};
+MODULE_DEVICE_TABLE(of, regulator_gpio_of_match);
#endif
static struct platform_driver gpio_regulator_driver = {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Applied "regmap: debugfs: Remove scratch buffer for register length calculation" to the regmap tree
The patch
regmap: debugfs: Remove scratch buffer for register length calculation
has been applied to the regmap tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 9ae3109d1d9ff367e0d0efa7073cc078edb9a372 Mon Sep 17 00:00:00 2001
From: Mark Brown
Date: Sat, 19 Sep 2015 07:31:47 -0700
Subject: [PATCH] regmap: debugfs: Remove scratch buffer for register length
calculation
Now we no longer use the scratch buffer for register length calculation
there is no need for callers to supply one.
Signed-off-by: Mark Brown
---
drivers/base/regmap/regmap-debugfs.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 4c55cfb..4a47378 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -30,7 +30,7 @@ static LIST_HEAD(regmap_debugfs_early_list);
static DEFINE_MUTEX(regmap_debugfs_early_lock);
/* Calculate the length of a fixed format */
-static size_t regmap_calc_reg_len(int max_val, char *buf, size_t buf_size)
+static size_t regmap_calc_reg_len(int max_val)
{
return snprintf(NULL, 0, "%x", max_val);
}
@@ -173,8 +173,7 @@ static inline void regmap_calc_tot_len(struct regmap *map,
{
/* Calculate the length of a fixed format */
if (!map->debugfs_tot_len) {
- map->debugfs_reg_len = regmap_calc_reg_len(map->max_register,
- buf, count);
+ map->debugfs_reg_len = regmap_calc_reg_len(map->max_register),
map->debugfs_val_len = 2 * map->format.val_bytes;
map->debugfs_tot_len = map->debugfs_reg_len +
map->debugfs_val_len + 3; /* : \n */
@@ -420,7 +419,7 @@ static ssize_t regmap_access_read_file(struct file *file,
return -ENOMEM;
/* Calculate the length of a fixed format */
- reg_len = regmap_calc_reg_len(map->max_register, buf, count);
+ reg_len = regmap_calc_reg_len(map->max_register);
tot_len = reg_len + 10; /* ': R W V P\n' */
for (i = 0; i <= map->max_register; i += map->reg_stride) {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Applied "regmap: debugfs: Don't bother actually printing when calculating max length" to the regmap tree
The patch
regmap: debugfs: Don't bother actually printing when calculating max length
has been applied to the regmap tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 176fc2d5770a0990eebff903ba680d2edd32e718 Mon Sep 17 00:00:00 2001
From: Mark Brown
Date: Sat, 19 Sep 2015 07:12:34 -0700
Subject: [PATCH] regmap: debugfs: Don't bother actually printing when
calculating max length
The in kernel snprintf() will conveniently return the actual length of
the printed string even if not given an output beffer at all so just do
that rather than relying on the user to pass in a suitable buffer,
ensuring that we don't need to worry if the buffer was truncated due to
the size of the buffer passed in.
Reported-by: Rasmus Villemoes
Signed-off-by: Mark Brown
Cc: sta...@vger.kernel.org
---
drivers/base/regmap/regmap-debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 1f32789..4c55cfb 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -32,8 +32,7 @@ static DEFINE_MUTEX(regmap_debugfs_early_lock);
/* Calculate the length of a fixed format */
static size_t regmap_calc_reg_len(int max_val, char *buf, size_t buf_size)
{
- snprintf(buf, buf_size, "%x", max_val);
- return strlen(buf);
+ return snprintf(NULL, 0, "%x", max_val);
}
static ssize_t regmap_name_read_file(struct file *file,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Applied "regulator: vexpress: Fix module autoload for OF platform driver" to the regulator tree
The patch
regulator: vexpress: Fix module autoload for OF platform driver
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7209fee89f435b69051bb6bffe7f191336ac2a5e Mon Sep 17 00:00:00 2001
From: Luis de Bethencourt
Date: Fri, 18 Sep 2015 19:09:51 +0200
Subject: [PATCH] regulator: vexpress: Fix module autoload for OF platform
driver
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt
Signed-off-by: Mark Brown
---
drivers/regulator/vexpress.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/vexpress.c b/drivers/regulator/vexpress.c
index bed9d3e..c810cbb 100644
--- a/drivers/regulator/vexpress.c
+++ b/drivers/regulator/vexpress.c
@@ -103,6 +103,7 @@ static const struct of_device_id
vexpress_regulator_of_match[] = {
{ .compatible = "arm,vexpress-volt", },
{ }
};
+MODULE_DEVICE_TABLE(of, vexpress_regulator_of_match);
static struct platform_driver vexpress_regulator_driver = {
.probe = vexpress_regulator_probe,
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Applied "regulator: anatop: Fix module autoload for OF platform driver" to the regulator tree
The patch
regulator: anatop: Fix module autoload for OF platform driver
has been applied to the regulator tree at
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d702ffd4d1df73b9c620af1654af42ff5b8d5c09 Mon Sep 17 00:00:00 2001
From: Luis de Bethencourt
Date: Fri, 18 Sep 2015 19:09:07 +0200
Subject: [PATCH] regulator: anatop: Fix module autoload for OF platform driver
This platform driver has a OF device ID table but the OF module
alias information is not created so module autoloading won't work.
Signed-off-by: Luis de Bethencourt
Signed-off-by: Mark Brown
---
drivers/regulator/anatop-regulator.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/regulator/anatop-regulator.c
b/drivers/regulator/anatop-regulator.c
index 738adfa..52ea605 100644
--- a/drivers/regulator/anatop-regulator.c
+++ b/drivers/regulator/anatop-regulator.c
@@ -318,6 +318,7 @@ static const struct of_device_id
of_anatop_regulator_match_tbl[] = {
{ .compatible = "fsl,anatop-regulator", },
{ /* end */ }
};
+MODULE_DEVICE_TABLE(of, of_anatop_regulator_match_tbl);
static struct platform_driver anatop_regulator_driver = {
.driver = {
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] drivers/crypto/nx: Add CRC and validation support for nx842
Hi,
This patch allows nx842 coprocessor to add CRC for compression and
check the computed CRC value for uncompression. Please let me know
if you have any comments.
Thanks
Haren
commit d0b34d2e3ed41e7ec2afdbd654f0dd7716e4d4c0
Author: Haren Myneni
Date: Sat Sep 12 01:20:51 2015 -0700
crypto/nx842: Add CRC and validation support
This patch adds CRC generation and validation support for nx-842.
Add CRC flag so that nx842 coprocessor includes CRC during
compression and validates during uncompression.
Signed-off-by: Haren Myneni
diff --git a/drivers/crypto/nx/nx-842-powernv.c
b/drivers/crypto/nx/nx-842-powernv.c
index 3750e13..9ef51fa 100644
--- a/drivers/crypto/nx/nx-842-powernv.c
+++ b/drivers/crypto/nx/nx-842-powernv.c
@@ -491,7 +491,7 @@ static int nx842_powernv_compress(const unsigned
char *in, unsigned int inlen,
void *wmem)
{
return nx842_powernv_function(in, inlen, out, outlenp,
- wmem, CCW_FC_842_COMP_NOCRC);
+ wmem, CCW_FC_842_COMP_CRC);
}
/**
@@ -519,7 +519,7 @@ static int nx842_powernv_decompress(const unsigned
char *in, unsigned int inlen,
void *wmem)
{
return nx842_powernv_function(in, inlen, out, outlenp,
- wmem, CCW_FC_842_DECOMP_NOCRC);
+ wmem, CCW_FC_842_DECOMP_CRC);
}
static int __init nx842_powernv_probe(struct device_node *dn)
diff --git a/drivers/crypto/nx/nx-842-pseries.c
b/drivers/crypto/nx/nx-842-pseries.c
index f4cbde0..5532dab 100644
--- a/drivers/crypto/nx/nx-842-pseries.c
+++ b/drivers/crypto/nx/nx-842-pseries.c
@@ -234,6 +234,9 @@ static int nx842_validate_result(struct device *dev,
dev_dbg(dev, "%s: Out of space in output buffer\n",
__func__);
return -ENOSPC;
+ case 65: /* Calculated CRC doesn't match the passed value */
+ dev_dbg(dev, "%s: CRC mismatch for decompression\n", __func__);
+ return -EINVAL;
case 66: /* Input data contains an illegal template field */
case 67: /* Template indicates data past the end of the input stream
*/
dev_dbg(dev, "%s: Bad data for decompression (code:%d)\n",
@@ -324,7 +327,7 @@ static int nx842_pseries_compress(const unsigned
char *in, unsigned int inlen,
slout.entries = (struct nx842_slentry *)workmem->slout;
/* Init operation */
- op.flags = NX842_OP_COMPRESS;
+ op.flags = NX842_OP_COMPRESS_CRC;
csbcpb = >csbcpb;
memset(csbcpb, 0, sizeof(*csbcpb));
op.csbcpb = nx842_get_pa(csbcpb);
@@ -457,7 +460,7 @@ static int nx842_pseries_decompress(const unsigned
char *in, unsigned int inlen,
slout.entries = (struct nx842_slentry *)workmem->slout;
/* Init operation */
- op.flags = NX842_OP_DECOMPRESS;
+ op.flags = NX842_OP_DECOMPRESS_CRC;
csbcpb = >csbcpb;
memset(csbcpb, 0, sizeof(*csbcpb));
op.csbcpb = nx842_get_pa(csbcpb);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: can't oom-kill zap the victim's memory?
On Sat, Sep 19, 2015 at 4:00 PM, Raymond Jennings wrote:
>
> Potentially stupid question that others may be asking: Is it legal to return
> EINTR from mmap() to let a SIGKILL from the OOM handler punch the task out
> of the kernel and back to userspace?
Yes. Note that mmap() itself seldom sleeps or allocates much memory
(yeah, there's the vma itself and soem minimal stuff), so it's mainly
an issue for things like MAP_POPULATE etc.
The more common situation is things like uninterruptible reads when a
device (or network) is not responding, and we have special support for
"killable" waits that act like normal uninterruptible waits but can be
interrupted by deadly signals, exactly because for those cases we
don't need to worry about things like POSIX return value guarantees
("all or nothing" for file reads) etc.
So you do generally have to write extra code for the "killable sleep".
But it's a good thing to do, if you notice that certain cases aren't
responding well to oom killing because they keep on waiting.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 01/15] RDS: use kfree_rcu in rds_ib_remove_ipaddr
synchronize_rcu() slowing down un-necessarily the socket shutdown
path. It is used just kfree() the ip addresses in rds_ib_remove_ipaddr()
which is perfect usecase for kfree_rcu();
So lets use that to gain some speedup.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib.h | 1 +
net/rds/ib_rdma.c | 6 ++
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/net/rds/ib.h b/net/rds/ib.h
index aae60fd..f1fd5ff 100644
--- a/net/rds/ib.h
+++ b/net/rds/ib.h
@@ -164,6 +164,7 @@ struct rds_ib_connection {
struct rds_ib_ipaddr {
struct list_headlist;
__be32 ipaddr;
+ struct rcu_head rcu;
};
struct rds_ib_device {
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 251d1ce..872f523 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -159,10 +159,8 @@ static void rds_ib_remove_ipaddr(struct rds_ib_device
*rds_ibdev, __be32 ipaddr)
}
spin_unlock_irq(_ibdev->spinlock);
- if (to_free) {
- synchronize_rcu();
- kfree(to_free);
- }
+ if (to_free)
+ kfree_rcu(to_free, rcu);
}
int rds_ib_update_ipaddr(struct rds_ib_device *rds_ibdev, __be32 ipaddr)
--
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 11/15] RDS: fix the rds_ib_fmr_wq kick call
RDS IB mr pool has its own workqueue 'rds_ib_fmr_wq', so we need
to use queue_delayed_work() to kick the work. This was hurting
the performance since pool maintenance was less often triggered
from other path.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib_rdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 872f523..b6644fa 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -319,7 +319,7 @@ static struct rds_ib_mr *rds_ib_alloc_fmr(struct
rds_ib_device *rds_ibdev)
int err = 0, iter = 0;
if (atomic_read(>dirty_count) >= pool->max_items / 10)
- schedule_delayed_work(>flush_worker, 10);
+ queue_delayed_work(rds_ib_fmr_wq, >flush_worker, 10);
while (1) {
ibmr = rds_ib_reuse_fmr(pool);
--
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 10/15] RDS: handle rds_ibdev release case instead of crashing the kernel
From: Santosh Shilimkar Just in case we are still handling the QP receive completion while the rds_ibdev is released, drop the connection instead of crashing the kernel. Signed-off-by: Santosh Shilimkar --- net/rds/ib_cm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c index 8f51d0d..2b2370e 100644 --- a/net/rds/ib_cm.c +++ b/net/rds/ib_cm.c @@ -285,7 +285,8 @@ static void rds_ib_tasklet_fn_recv(unsigned long data) struct rds_ib_device *rds_ibdev = ic->rds_ibdev; struct rds_ib_ack_state state; - BUG_ON(!rds_ibdev); + if (!rds_ibdev) + rds_conn_drop(conn); rds_ib_stats_inc(s_ib_tasklet_call); -- 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 12/15] RDS: use already available pool handle from ibmr
rds_ib_mr already keeps the pool handle which it associates
with. Lets use that instead of round about way of fetching
it from rds_ib_device.
No functional change.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib_rdma.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index b6644fa..52d889a 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -522,8 +522,7 @@ static void rds_ib_teardown_mr(struct rds_ib_mr *ibmr)
__rds_ib_teardown_mr(ibmr);
if (pinned) {
- struct rds_ib_device *rds_ibdev = ibmr->device;
- struct rds_ib_mr_pool *pool = rds_ibdev->mr_pool;
+ struct rds_ib_mr_pool *pool = ibmr->pool;
atomic_sub(pinned, >free_pinned);
}
@@ -717,8 +716,8 @@ static void rds_ib_mr_pool_flush_worker(struct work_struct
*work)
void rds_ib_free_mr(void *trans_private, int invalidate)
{
struct rds_ib_mr *ibmr = trans_private;
+ struct rds_ib_mr_pool *pool = ibmr->pool;
struct rds_ib_device *rds_ibdev = ibmr->device;
- struct rds_ib_mr_pool *pool = rds_ibdev->mr_pool;
rdsdebug("RDS/IB: free_mr nents %u\n", ibmr->sg_len);
--
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 09/15] RDS: split send completion handling and do batch ack
Similar to what we did with receive CQ completion handling, we split
the transmit completion handler so that it lets us implement batched
work completion handling.
We re-use the cq_poll routine and makes use of RDS_IB_SEND_OP to
identify the send vs receive completion event handler invocation.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib.h | 6 ++-
net/rds/ib_cm.c| 45 --
net/rds/ib_send.c | 110 +
net/rds/ib_stats.c | 1 -
net/rds/send.c | 1 +
5 files changed, 98 insertions(+), 65 deletions(-)
diff --git a/net/rds/ib.h b/net/rds/ib.h
index 727759b..3a8cd31 100644
--- a/net/rds/ib.h
+++ b/net/rds/ib.h
@@ -25,6 +25,7 @@
#define RDS_IB_RECYCLE_BATCH_COUNT 32
#define RDS_IB_WC_MAX 32
+#define RDS_IB_SEND_OP BIT_ULL(63)
extern struct rw_semaphore rds_ib_devices_lock;
extern struct list_head rds_ib_devices;
@@ -118,9 +119,11 @@ struct rds_ib_connection {
struct ib_pd*i_pd;
struct ib_cq*i_send_cq;
struct ib_cq*i_recv_cq;
+ struct ib_wci_send_wc[RDS_IB_WC_MAX];
struct ib_wci_recv_wc[RDS_IB_WC_MAX];
/* interrupt handling */
+ struct tasklet_struct i_send_tasklet;
struct tasklet_struct i_recv_tasklet;
/* tx */
@@ -217,7 +220,6 @@ struct rds_ib_device {
struct rds_ib_statistics {
uint64_ts_ib_connect_raced;
uint64_ts_ib_listen_closed_stale;
- uint64_ts_ib_tx_cq_call;
uint64_ts_ib_evt_handler_call;
uint64_ts_ib_tasklet_call;
uint64_ts_ib_tx_cq_event;
@@ -371,7 +373,7 @@ extern wait_queue_head_t rds_ib_ring_empty_wait;
void rds_ib_xmit_complete(struct rds_connection *conn);
int rds_ib_xmit(struct rds_connection *conn, struct rds_message *rm,
unsigned int hdr_off, unsigned int sg, unsigned int off);
-void rds_ib_send_cq_comp_handler(struct ib_cq *cq, void *context);
+void rds_ib_send_cqe_handler(struct rds_ib_connection *ic, struct ib_wc *wc);
void rds_ib_send_init_ring(struct rds_ib_connection *ic);
void rds_ib_send_clear_ring(struct rds_ib_connection *ic);
int rds_ib_xmit_rdma(struct rds_connection *conn, struct rm_rdma_op *op);
diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
index 28e0979..8f51d0d 100644
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -250,11 +250,34 @@ static void poll_cq(struct rds_ib_connection *ic, struct
ib_cq *cq,
rdsdebug("wc wr_id 0x%llx status %u byte_len %u
imm_data %u\n",
(unsigned long long)wc->wr_id, wc->status,
wc->byte_len, be32_to_cpu(wc->ex.imm_data));
- rds_ib_recv_cqe_handler(ic, wc, ack_state);
+
+ if (wc->wr_id & RDS_IB_SEND_OP)
+ rds_ib_send_cqe_handler(ic, wc);
+ else
+ rds_ib_recv_cqe_handler(ic, wc, ack_state);
}
}
}
+static void rds_ib_tasklet_fn_send(unsigned long data)
+{
+ struct rds_ib_connection *ic = (struct rds_ib_connection *)data;
+ struct rds_connection *conn = ic->conn;
+ struct rds_ib_ack_state state;
+
+ rds_ib_stats_inc(s_ib_tasklet_call);
+
+ memset(, 0, sizeof(state));
+ poll_cq(ic, ic->i_send_cq, ic->i_send_wc, );
+ ib_req_notify_cq(ic->i_send_cq, IB_CQ_NEXT_COMP);
+ poll_cq(ic, ic->i_send_cq, ic->i_send_wc, );
+
+ if (rds_conn_up(conn) &&
+ (!test_bit(RDS_LL_SEND_FULL, >c_flags) ||
+ test_bit(0, >c_map_queued)))
+ rds_send_xmit(ic->conn);
+}
+
static void rds_ib_tasklet_fn_recv(unsigned long data)
{
struct rds_ib_connection *ic = (struct rds_ib_connection *)data;
@@ -304,6 +327,18 @@ static void rds_ib_qp_event_handler(struct ib_event
*event, void *data)
}
}
+static void rds_ib_cq_comp_handler_send(struct ib_cq *cq, void *context)
+{
+ struct rds_connection *conn = context;
+ struct rds_ib_connection *ic = conn->c_transport_data;
+
+ rdsdebug("conn %p cq %p\n", conn, cq);
+
+ rds_ib_stats_inc(s_ib_evt_handler_call);
+
+ tasklet_schedule(>i_send_tasklet);
+}
+
/*
* This needs to be very careful to not leave IS_ERR pointers around for
* cleanup to trip over.
@@ -337,7 +372,8 @@ static int rds_ib_setup_qp(struct rds_connection *conn)
ic->i_pd = rds_ibdev->pd;
cq_attr.cqe = ic->i_send_ring.w_nr + 1;
- ic->i_send_cq = ib_create_cq(dev, rds_ib_send_cq_comp_handler,
+
+ ic->i_send_cq = ib_create_cq(dev, rds_ib_cq_comp_handler_send,
rds_ib_cq_event_handler, conn,
_attr);
if (IS_ERR(ic->i_send_cq)) {
@@ -703,6 +739,7 @@ void
[PATCH 13/15] RDS: mark rds_ib_fmr_wq static
Fix below warning by marking rds_ib_fmr_wq static
net/rds/ib_rdma.c:87:25: warning: symbol 'rds_ib_fmr_wq' was not declared.
Should it be static?
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib_rdma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rds/ib_rdma.c b/net/rds/ib_rdma.c
index 52d889a..bb62024 100644
--- a/net/rds/ib_rdma.c
+++ b/net/rds/ib_rdma.c
@@ -83,7 +83,7 @@ struct rds_ib_mr_pool {
struct ib_fmr_attr fmr_attr;
};
-struct workqueue_struct *rds_ib_fmr_wq;
+static struct workqueue_struct *rds_ib_fmr_wq;
int rds_ib_fmr_init(void)
{
--
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 14/15] RDS: use max_mr from HCA caps than max_fmr
From: Santosh Shilimkar All HCA drivers seems to popullate max_mr caps and few of them do both max_mr and max_fmr. Hence update RDS code to make use of max_mr. Signed-off-by: Santosh Shilimkar Signed-off-by: Santosh Shilimkar --- net/rds/ib.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/rds/ib.c b/net/rds/ib.c index 2d3f2ab..883813a 100644 --- a/net/rds/ib.c +++ b/net/rds/ib.c @@ -148,8 +148,8 @@ static void rds_ib_add_one(struct ib_device *device) rds_ibdev->max_sge = min(dev_attr->max_sge, RDS_IB_MAX_SGE); rds_ibdev->fmr_max_remaps = dev_attr->max_map_per_fmr?: 32; - rds_ibdev->max_fmrs = dev_attr->max_fmr ? - min_t(unsigned int, dev_attr->max_fmr, fmr_pool_size) : + rds_ibdev->max_fmrs = dev_attr->max_mr ? + min_t(unsigned int, dev_attr->max_mr, fmr_pool_size) : fmr_pool_size; rds_ibdev->max_initiator_depth = dev_attr->max_qp_init_rd_atom; -- 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 08/15] RDS: ack more receive completions to improve performance
For better performance, we split the receive completion IRQ handler. That
lets us acknowledge several WCE events in one call. We also limit the WC
to max 32 to avoid latency. Acknowledging several completions in one call
instead of several calls each time will provide better performance since
less mutual exclusion locks are being performed.
In next patch, send completion is also split which re-uses the poll_cq()
and hence the code is moved to ib_cm.c
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib.h | 28 +--
net/rds/ib_cm.c| 70 ++-
net/rds/ib_recv.c | 136 +++--
net/rds/ib_stats.c | 3 +-
4 files changed, 132 insertions(+), 105 deletions(-)
diff --git a/net/rds/ib.h b/net/rds/ib.h
index f1fd5ff..727759b 100644
--- a/net/rds/ib.h
+++ b/net/rds/ib.h
@@ -24,6 +24,8 @@
#define RDS_IB_RECYCLE_BATCH_COUNT 32
+#define RDS_IB_WC_MAX 32
+
extern struct rw_semaphore rds_ib_devices_lock;
extern struct list_head rds_ib_devices;
@@ -89,6 +91,20 @@ struct rds_ib_work_ring {
atomic_tw_free_ctr;
};
+/* Rings are posted with all the allocations they'll need to queue the
+ * incoming message to the receiving socket so this can't fail.
+ * All fragments start with a header, so we can make sure we're not receiving
+ * garbage, and we can tell a small 8 byte fragment from an ACK frame.
+ */
+struct rds_ib_ack_state {
+ u64 ack_next;
+ u64 ack_recv;
+ unsigned intack_required:1;
+ unsigned intack_next_valid:1;
+ unsigned intack_recv_valid:1;
+};
+
+
struct rds_ib_device;
struct rds_ib_connection {
@@ -102,6 +118,10 @@ struct rds_ib_connection {
struct ib_pd*i_pd;
struct ib_cq*i_send_cq;
struct ib_cq*i_recv_cq;
+ struct ib_wci_recv_wc[RDS_IB_WC_MAX];
+
+ /* interrupt handling */
+ struct tasklet_struct i_recv_tasklet;
/* tx */
struct rds_ib_work_ring i_send_ring;
@@ -112,7 +132,6 @@ struct rds_ib_connection {
atomic_ti_signaled_sends;
/* rx */
- struct tasklet_struct i_recv_tasklet;
struct mutexi_recv_mutex;
struct rds_ib_work_ring i_recv_ring;
struct rds_ib_incoming *i_ibinc;
@@ -199,13 +218,14 @@ struct rds_ib_statistics {
uint64_ts_ib_connect_raced;
uint64_ts_ib_listen_closed_stale;
uint64_ts_ib_tx_cq_call;
+ uint64_ts_ib_evt_handler_call;
+ uint64_ts_ib_tasklet_call;
uint64_ts_ib_tx_cq_event;
uint64_ts_ib_tx_ring_full;
uint64_ts_ib_tx_throttle;
uint64_ts_ib_tx_sg_mapping_failure;
uint64_ts_ib_tx_stalled;
uint64_ts_ib_tx_credit_updates;
- uint64_ts_ib_rx_cq_call;
uint64_ts_ib_rx_cq_event;
uint64_ts_ib_rx_ring_empty;
uint64_ts_ib_rx_refill_from_cq;
@@ -324,7 +344,8 @@ void rds_ib_recv_free_caches(struct rds_ib_connection *ic);
void rds_ib_recv_refill(struct rds_connection *conn, int prefill, gfp_t gfp);
void rds_ib_inc_free(struct rds_incoming *inc);
int rds_ib_inc_copy_to_user(struct rds_incoming *inc, struct iov_iter *to);
-void rds_ib_recv_cq_comp_handler(struct ib_cq *cq, void *context);
+void rds_ib_recv_cqe_handler(struct rds_ib_connection *ic, struct ib_wc *wc,
+struct rds_ib_ack_state *state);
void rds_ib_recv_tasklet_fn(unsigned long data);
void rds_ib_recv_init_ring(struct rds_ib_connection *ic);
void rds_ib_recv_clear_ring(struct rds_ib_connection *ic);
@@ -332,6 +353,7 @@ void rds_ib_recv_init_ack(struct rds_ib_connection *ic);
void rds_ib_attempt_ack(struct rds_ib_connection *ic);
void rds_ib_ack_send_complete(struct rds_ib_connection *ic);
u64 rds_ib_piggyb_ack(struct rds_ib_connection *ic);
+void rds_ib_set_ack(struct rds_ib_connection *ic, u64 seq, int ack_required);
/* ib_ring.c */
void rds_ib_ring_init(struct rds_ib_work_ring *ring, u32 nr);
diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
index 9043f5c..28e0979 100644
--- a/net/rds/ib_cm.c
+++ b/net/rds/ib_cm.c
@@ -216,6 +216,72 @@ static void rds_ib_cq_event_handler(struct ib_event
*event, void *data)
event->event, ib_event_msg(event->event), data);
}
+/* Plucking the oldest entry from the ring can be done concurrently with
+ * the thread refilling the ring. Each ring operation is protected by
+ * spinlocks and the transient state of refilling doesn't change the
+ * recording of which entry is oldest.
+ *
+ * This relies on IB only calling one cq comp_handler for each cq so that
+ * there will only be one caller of rds_recv_incoming() per RDS connection.
+ */
+static void rds_ib_cq_comp_handler_recv(struct ib_cq *cq, void *context)
[PATCH 07/15] RDS: use rds_send_xmit() state instead of RDS_LL_SEND_FULL
In Transport indepedent rds_sendmsg(), we shouldn't make decisions based
on RDS_LL_SEND_FULL which is used to manage the ring for RDMA based
transports. We can safely issue rds_send_xmit() and the using its
return value take decision on deferred work. This will also fix
the scenario where at times we are seeing connections stuck with
the LL_SEND_FULL bit getting set and never cleared.
We kick krdsd after any time we see -ENOMEM or -EAGAIN from the
ring allocation code.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/send.c| 10 ++
net/rds/threads.c | 2 ++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index f1e709c..9d8b52d 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -1122,8 +1122,9 @@ int rds_sendmsg(struct socket *sock, struct msghdr *msg,
size_t payload_len)
*/
rds_stats_inc(s_send_queued);
- if (!test_bit(RDS_LL_SEND_FULL, >c_flags))
- rds_send_xmit(conn);
+ ret = rds_send_xmit(conn);
+ if (ret == -ENOMEM || ret == -EAGAIN)
+ queue_delayed_work(rds_wq, >c_send_w, 1);
rds_message_put(rm);
return payload_len;
@@ -1179,8 +1180,9 @@ rds_send_pong(struct rds_connection *conn, __be16 dport)
rds_stats_inc(s_send_queued);
rds_stats_inc(s_send_pong);
- if (!test_bit(RDS_LL_SEND_FULL, >c_flags))
- queue_delayed_work(rds_wq, >c_send_w, 0);
+ ret = rds_send_xmit(conn);
+ if (ret == -ENOMEM || ret == -EAGAIN)
+ queue_delayed_work(rds_wq, >c_send_w, 1);
rds_message_put(rm);
return 0;
diff --git a/net/rds/threads.c b/net/rds/threads.c
index dc2402e..454aa6d 100644
--- a/net/rds/threads.c
+++ b/net/rds/threads.c
@@ -162,7 +162,9 @@ void rds_send_worker(struct work_struct *work)
int ret;
if (rds_conn_state(conn) == RDS_CONN_UP) {
+ clear_bit(RDS_LL_SEND_FULL, >c_flags);
ret = rds_send_xmit(conn);
+ cond_resched();
rdsdebug("conn %p ret %d\n", conn, ret);
switch (ret) {
case -EAGAIN:
--
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 15/15] RDS: split mr pool to improve 8K messages performance
8K message sizes are pretty important usecase for RDS current
workloads so we make provison to have 8K mrs available from the pool.
Based on number of SG's in the RDS message, we pick a pool to use.
Also to make sure that we don't under utlise mrs when say 8k messages
are dominating which could lead to 8k pull being exhausted, we fall-back
to 1m pool till 8k pool recovers for use.
This helps to at least push ~55 kB/s bidirectional data which
is a nice improvement.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/ib.c | 47 +
net/rds/ib.h | 43 ---
net/rds/ib_rdma.c | 101 +
net/rds/ib_stats.c | 18 ++
4 files changed, 147 insertions(+), 62 deletions(-)
diff --git a/net/rds/ib.c b/net/rds/ib.c
index 883813a..a833ab7 100644
--- a/net/rds/ib.c
+++ b/net/rds/ib.c
@@ -43,14 +43,14 @@
#include "rds.h"
#include "ib.h"
-static unsigned int fmr_pool_size = RDS_FMR_POOL_SIZE;
-unsigned int fmr_message_size = RDS_FMR_SIZE + 1; /* +1 allows for unaligned
MRs */
+unsigned int rds_ib_fmr_1m_pool_size = RDS_FMR_1M_POOL_SIZE;
+unsigned int rds_ib_fmr_8k_pool_size = RDS_FMR_8K_POOL_SIZE;
unsigned int rds_ib_retry_count = RDS_IB_DEFAULT_RETRY_COUNT;
-module_param(fmr_pool_size, int, 0444);
-MODULE_PARM_DESC(fmr_pool_size, " Max number of fmr per HCA");
-module_param(fmr_message_size, int, 0444);
-MODULE_PARM_DESC(fmr_message_size, " Max size of a RDMA transfer");
+module_param(rds_ib_fmr_1m_pool_size, int, 0444);
+MODULE_PARM_DESC(rds_ib_fmr_1m_pool_size, " Max number of 1M fmr per HCA");
+module_param(rds_ib_fmr_8k_pool_size, int, 0444);
+MODULE_PARM_DESC(rds_ib_fmr_8k_pool_size, " Max number of 8K fmr per HCA");
module_param(rds_ib_retry_count, int, 0444);
MODULE_PARM_DESC(rds_ib_retry_count, " Number of hw retries before reporting
an error");
@@ -97,8 +97,10 @@ static void rds_ib_dev_free(struct work_struct *work)
struct rds_ib_device *rds_ibdev = container_of(work,
struct rds_ib_device, free_work);
- if (rds_ibdev->mr_pool)
- rds_ib_destroy_mr_pool(rds_ibdev->mr_pool);
+ if (rds_ibdev->mr_8k_pool)
+ rds_ib_destroy_mr_pool(rds_ibdev->mr_8k_pool);
+ if (rds_ibdev->mr_1m_pool)
+ rds_ib_destroy_mr_pool(rds_ibdev->mr_1m_pool);
if (rds_ibdev->pd)
ib_dealloc_pd(rds_ibdev->pd);
@@ -148,9 +150,13 @@ static void rds_ib_add_one(struct ib_device *device)
rds_ibdev->max_sge = min(dev_attr->max_sge, RDS_IB_MAX_SGE);
rds_ibdev->fmr_max_remaps = dev_attr->max_map_per_fmr?: 32;
- rds_ibdev->max_fmrs = dev_attr->max_mr ?
- min_t(unsigned int, dev_attr->max_mr, fmr_pool_size) :
- fmr_pool_size;
+ rds_ibdev->max_1m_fmrs = dev_attr->max_mr ?
+ min_t(unsigned int, (dev_attr->max_mr / 2),
+ rds_ib_fmr_1m_pool_size) : rds_ib_fmr_1m_pool_size;
+
+ rds_ibdev->max_8k_fmrs = dev_attr->max_mr ?
+ min_t(unsigned int, ((dev_attr->max_mr / 2) * RDS_MR_8K_SCALE),
+ rds_ib_fmr_8k_pool_size) : rds_ib_fmr_8k_pool_size;
rds_ibdev->max_initiator_depth = dev_attr->max_qp_init_rd_atom;
rds_ibdev->max_responder_resources = dev_attr->max_qp_rd_atom;
@@ -162,12 +168,25 @@ static void rds_ib_add_one(struct ib_device *device)
goto put_dev;
}
- rds_ibdev->mr_pool = rds_ib_create_mr_pool(rds_ibdev);
- if (IS_ERR(rds_ibdev->mr_pool)) {
- rds_ibdev->mr_pool = NULL;
+ rds_ibdev->mr_1m_pool =
+ rds_ib_create_mr_pool(rds_ibdev, RDS_IB_MR_1M_POOL);
+ if (IS_ERR(rds_ibdev->mr_1m_pool)) {
+ rds_ibdev->mr_1m_pool = NULL;
goto put_dev;
}
+ rds_ibdev->mr_8k_pool =
+ rds_ib_create_mr_pool(rds_ibdev, RDS_IB_MR_8K_POOL);
+ if (IS_ERR(rds_ibdev->mr_8k_pool)) {
+ rds_ibdev->mr_8k_pool = NULL;
+ goto put_dev;
+ }
+
+ rdsdebug("RDS/IB: max_mr = %d, max_wrs = %d, max_sge = %d,
fmr_max_remaps = %d, max_1m_fmrs = %d, max_8k_fmrs = %d\n",
+dev_attr->max_fmr, rds_ibdev->max_wrs, rds_ibdev->max_sge,
+rds_ibdev->fmr_max_remaps, rds_ibdev->max_1m_fmrs,
+rds_ibdev->max_8k_fmrs);
+
INIT_LIST_HEAD(_ibdev->ipaddr_list);
INIT_LIST_HEAD(_ibdev->conn_list);
diff --git a/net/rds/ib.h b/net/rds/ib.h
index 3a8cd31..f17d095 100644
--- a/net/rds/ib.h
+++ b/net/rds/ib.h
@@ -9,8 +9,11 @@
#include "rds.h"
#include "rdma_transport.h"
-#define RDS_FMR_SIZE 256
-#define RDS_FMR_POOL_SIZE 8192
+#define RDS_FMR_1M_POOL_SIZE (8192 / 2)
+#define RDS_FMR_1M_MSG_SIZE256
+#define RDS_FMR_8K_MSG_SIZE2
+#define RDS_MR_8K_SCALE
[PATCH 06/15] RDS: defer the over_batch work to send worker
Current process gives up if its send work over the batch limit.
The work queue will get kicked to finish off any other requests.
This fixes remainder condition from commit 443be0e5affe ("RDS: make
sure not to loop forever inside rds_send_xmit").
The restart condition is only for the case where we reached to
over_batch code for some other reason so just retrying again
before giving up.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/send.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/net/rds/send.c b/net/rds/send.c
index 4df61a5..f1e709c 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -423,7 +423,9 @@ over_batch:
!list_empty(>c_send_queue)) &&
send_gen == conn->c_send_gen) {
rds_stats_inc(s_send_lock_queue_raced);
- goto restart;
+ if (batch_count < 1024)
+ goto restart;
+ queue_delayed_work(rds_wq, >c_send_w, 1);
}
}
out:
--
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 02/15] RDS: make socket bind/release locking scheme simple and more efficient
RDS bind and release locking scheme is very inefficient. It
uses RCU for maintaining the bind hash-table which is great but
it also needs to hold spinlock for [add/remove]_bound(). So
overall usecase, the hash-table concurrent speedup doesn't pay off.
In fact blocking nature of synchronize_rcu() makes the RDS
socket shutdown too slow which hurts RDS performance since
connection shutdown and re-connect happens quite often to
maintain the RC part of the protocol.
So we make the locking scheme simpler and more efficient by
replacing spin_locks with reader/writer locks and getting rid
off rcu for bind hash-table.
In subsequent patch, we also covert the global lock with per-bucket
lock to reduce the global lock contention.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/af_rds.c | 6 --
net/rds/bind.c | 35 +++
2 files changed, 15 insertions(+), 26 deletions(-)
diff --git a/net/rds/af_rds.c b/net/rds/af_rds.c
index a2f28a6..dc08766 100644
--- a/net/rds/af_rds.c
+++ b/net/rds/af_rds.c
@@ -72,13 +72,7 @@ static int rds_release(struct socket *sock)
rds_clear_recv_queue(rs);
rds_cong_remove_socket(rs);
- /*
-* the binding lookup hash uses rcu, we need to
-* make sure we synchronize_rcu before we free our
-* entry
-*/
rds_remove_bound(rs);
- synchronize_rcu();
rds_send_drop_to(rs, NULL);
rds_rdma_drop_keys(rs);
diff --git a/net/rds/bind.c b/net/rds/bind.c
index dd666fb..01989e2 100644
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -40,7 +40,7 @@
#define BIND_HASH_SIZE 1024
static struct hlist_head bind_hash_table[BIND_HASH_SIZE];
-static DEFINE_SPINLOCK(rds_bind_lock);
+static DEFINE_RWLOCK(rds_bind_lock);
static struct hlist_head *hash_to_bucket(__be32 addr, __be16 port)
{
@@ -48,6 +48,7 @@ static struct hlist_head *hash_to_bucket(__be32 addr, __be16
port)
(BIND_HASH_SIZE - 1));
}
+/* must hold either read or write lock (write lock for insert != NULL) */
static struct rds_sock *rds_bind_lookup(__be32 addr, __be16 port,
struct rds_sock *insert)
{
@@ -56,30 +57,24 @@ static struct rds_sock *rds_bind_lookup(__be32 addr, __be16
port,
u64 cmp;
u64 needle = ((u64)be32_to_cpu(addr) << 32) | be16_to_cpu(port);
- rcu_read_lock();
- hlist_for_each_entry_rcu(rs, head, rs_bound_node) {
+ hlist_for_each_entry(rs, head, rs_bound_node) {
cmp = ((u64)be32_to_cpu(rs->rs_bound_addr) << 32) |
be16_to_cpu(rs->rs_bound_port);
- if (cmp == needle) {
- rcu_read_unlock();
+ if (cmp == needle)
return rs;
- }
}
- rcu_read_unlock();
if (insert) {
/*
* make sure our addr and port are set before
-* we are added to the list, other people
-* in rcu will find us as soon as the
-* hlist_add_head_rcu is done
+* we are added to the list.
*/
insert->rs_bound_addr = addr;
insert->rs_bound_port = port;
rds_sock_addref(insert);
- hlist_add_head_rcu(>rs_bound_node, head);
+ hlist_add_head(>rs_bound_node, head);
}
return NULL;
}
@@ -93,8 +88,11 @@ static struct rds_sock *rds_bind_lookup(__be32 addr, __be16
port,
struct rds_sock *rds_find_bound(__be32 addr, __be16 port)
{
struct rds_sock *rs;
+ unsigned long flags;
+ read_lock_irqsave(_bind_lock, flags);
rs = rds_bind_lookup(addr, port, NULL);
+ read_unlock_irqrestore(_bind_lock, flags);
if (rs && !sock_flag(rds_rs_to_sk(rs), SOCK_DEAD))
rds_sock_addref(rs);
@@ -103,6 +101,7 @@ struct rds_sock *rds_find_bound(__be32 addr, __be16 port)
rdsdebug("returning rs %p for %pI4:%u\n", rs, ,
ntohs(port));
+
return rs;
}
@@ -121,7 +120,7 @@ static int rds_add_bound(struct rds_sock *rs, __be32 addr,
__be16 *port)
last = rover - 1;
}
- spin_lock_irqsave(_bind_lock, flags);
+ write_lock_irqsave(_bind_lock, flags);
do {
if (rover == 0)
@@ -135,7 +134,7 @@ static int rds_add_bound(struct rds_sock *rs, __be32 addr,
__be16 *port)
}
} while (rover++ != last);
- spin_unlock_irqrestore(_bind_lock, flags);
+ write_unlock_irqrestore(_bind_lock, flags);
return ret;
}
@@ -144,19 +143,19 @@ void rds_remove_bound(struct rds_sock *rs)
{
unsigned long flags;
- spin_lock_irqsave(_bind_lock, flags);
+ write_lock_irqsave(_bind_lock, flags);
if (rs->rs_bound_addr) {
rdsdebug("rs %p unbinding from %pI4:%d\n",
rs,
[PATCH 05/15] RDS: increase size of hash-table to 8K
Even with per bucket locking scheme, in a massive parallel
system with active rds sockets which could be in excess of multiple
of 10K, rds_bin_lookup() workload is siginificant because of smaller
hashtable size.
With some tests, it was found that we get modest but still nice
reduction in rds_bind_lookup with bigger bucket.
Hashtable Baseline(1k)Delta
2048: 8.28% -2.45%
4096: 8.28% -4.60%
8192: 8.28% -6.46%
16384: 8.28% -6.75%
Based on the data, we set 8K as the bind hash-table size.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/bind.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/rds/bind.c b/net/rds/bind.c
index bc6b93e..fb2d545 100644
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -43,7 +43,7 @@ struct bind_bucket {
struct hlist_head head;
};
-#define BIND_HASH_SIZE 1024
+#define BIND_HASH_SIZE 8192
static struct bind_bucket bind_hash_table[BIND_HASH_SIZE];
static struct bind_bucket *hash_to_bucket(__be32 addr, __be16 port)
--
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 04/15] RDS: Use per-bucket rw lock for bind hash-table
One global lock protecting hash-tables with 1024 buckets isn't
efficient and it shows up in a massive systems with truck
loads of RDS sockets serving multiple databases. The
perf data clearly highlights the contention on the rw
lock in these massive workloads.
When the contention gets worse, the code gets into a state where
it decides to back off on the lock. So while it has disabled interrupts,
it sits and backs off on this lock get. This causes the system to
become sluggish and eventually all sorts of bad things happen.
The simple fix is to move the lock into the hash bucket and
use per-bucket lock to improve the scalability.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/af_rds.c | 2 ++
net/rds/bind.c | 47 ---
net/rds/rds.h| 1 +
3 files changed, 35 insertions(+), 15 deletions(-)
diff --git a/net/rds/af_rds.c b/net/rds/af_rds.c
index dc08766..384ea1e 100644
--- a/net/rds/af_rds.c
+++ b/net/rds/af_rds.c
@@ -582,6 +582,8 @@ static int rds_init(void)
{
int ret;
+ rds_bind_lock_init();
+
ret = rds_conn_init();
if (ret)
goto out;
diff --git a/net/rds/bind.c b/net/rds/bind.c
index 166c605..bc6b93e 100644
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -38,22 +38,27 @@
#include
#include "rds.h"
+struct bind_bucket {
+ rwlock_tlock;
+ struct hlist_head head;
+};
+
#define BIND_HASH_SIZE 1024
-static struct hlist_head bind_hash_table[BIND_HASH_SIZE];
-static DEFINE_RWLOCK(rds_bind_lock);
+static struct bind_bucket bind_hash_table[BIND_HASH_SIZE];
-static struct hlist_head *hash_to_bucket(__be32 addr, __be16 port)
+static struct bind_bucket *hash_to_bucket(__be32 addr, __be16 port)
{
return bind_hash_table + (jhash_2words((u32)addr, (u32)port, 0) &
(BIND_HASH_SIZE - 1));
}
/* must hold either read or write lock (write lock for insert != NULL) */
-static struct rds_sock *rds_bind_lookup(__be32 addr, __be16 port,
+static struct rds_sock *rds_bind_lookup(struct bind_bucket *bucket,
+ __be32 addr, __be16 port,
struct rds_sock *insert)
{
struct rds_sock *rs;
- struct hlist_head *head = hash_to_bucket(addr, port);
+ struct hlist_head *head = >head;
u64 cmp;
u64 needle = ((u64)be32_to_cpu(addr) << 32) | be16_to_cpu(port);
@@ -91,10 +96,11 @@ struct rds_sock *rds_find_bound(__be32 addr, __be16 port)
{
struct rds_sock *rs;
unsigned long flags;
+ struct bind_bucket *bucket = hash_to_bucket(addr, port);
- read_lock_irqsave(_bind_lock, flags);
- rs = rds_bind_lookup(addr, port, NULL);
- read_unlock_irqrestore(_bind_lock, flags);
+ read_lock_irqsave(>lock, flags);
+ rs = rds_bind_lookup(bucket, addr, port, NULL);
+ read_unlock_irqrestore(>lock, flags);
if (rs && sock_flag(rds_rs_to_sk(rs), SOCK_DEAD)) {
rds_sock_put(rs);
@@ -113,6 +119,7 @@ static int rds_add_bound(struct rds_sock *rs, __be32 addr,
__be16 *port)
unsigned long flags;
int ret = -EADDRINUSE;
u16 rover, last;
+ struct bind_bucket *bucket;
if (*port != 0) {
rover = be16_to_cpu(*port);
@@ -122,13 +129,15 @@ static int rds_add_bound(struct rds_sock *rs, __be32
addr, __be16 *port)
last = rover - 1;
}
- write_lock_irqsave(_bind_lock, flags);
-
do {
struct rds_sock *rrs;
if (rover == 0)
rover++;
- rrs = rds_bind_lookup(addr, cpu_to_be16(rover), rs);
+
+ bucket = hash_to_bucket(addr, cpu_to_be16(rover));
+ write_lock_irqsave(>lock, flags);
+ rrs = rds_bind_lookup(bucket, addr, cpu_to_be16(rover), rs);
+ write_unlock_irqrestore(>lock, flags);
if (!rrs) {
*port = rs->rs_bound_port;
ret = 0;
@@ -140,16 +149,16 @@ static int rds_add_bound(struct rds_sock *rs, __be32
addr, __be16 *port)
}
} while (rover++ != last);
- write_unlock_irqrestore(_bind_lock, flags);
-
return ret;
}
void rds_remove_bound(struct rds_sock *rs)
{
unsigned long flags;
+ struct bind_bucket *bucket =
+ hash_to_bucket(rs->rs_bound_addr, rs->rs_bound_port);
- write_lock_irqsave(_bind_lock, flags);
+ write_lock_irqsave(>lock, flags);
if (rs->rs_bound_addr) {
rdsdebug("rs %p unbinding from %pI4:%d\n",
@@ -161,7 +170,7 @@ void rds_remove_bound(struct rds_sock *rs)
rs->rs_bound_addr = 0;
}
- write_unlock_irqrestore(_bind_lock, flags);
+ write_unlock_irqrestore(>lock, flags);
}
int rds_bind(struct socket *sock, struct sockaddr *uaddr, int addr_len)
@@
[PATCH 00/15] RDS: connection scalability and performance improvements
This series addresses RDS connection bottlenecks on massive workloads and improve the RDMA performance almost by 3X. RDS TCP also gets a small gain of about 12%. RDS is being used in massive systems with high scalability where several hundred thousand end points and tens of thousands of local processes are operating in tens of thousand sockets. Being RC(reliable connection), socket bind and release happens very often and any inefficiencies in bind hash look ups hurts the overall system performance. RDS bin hash-table uses global spin-lock which is the biggest bottleneck. To make matter worst, it uses rcu inside global lock for hash buckets. This is being addressed by simply using per bucket rw lock which makes the locking simple and very efficient. The hash table size is also scaled up accordingly. For RDS RDMA improvement, the completion handling is revamped so that we can do batch completions. Both send and receive completion handlers are split logically to achieve the same. RDS 8K messages being one of the key usecase, mr pool is adapted to have the 8K mrs along with default 1M mrs. And while doing this, few fixes and couple of bottlenecks seen with rds_sendmsg() are addressed. Series applies against 4.3-rc1 as well as net-next. Its tested on Oracle hardware with IB fabric for both bcopy as well as RDMA mode. RDS TCP is tested with iXGB NIC. Like last time, iWARP transport is untested with these changes. As a side note, the IB HCA driver I used for testing misses at least 3 important patches in upstream to see the full blown RDS IB performance and am hoping to get that in mainline with help of them. Santosh Shilimkar (15): RDS: use kfree_rcu in rds_ib_remove_ipaddr RDS: make socket bind/release locking scheme simple and more efficient RDS: fix rds_sock reference bug while doing bind RDS: Use per-bucket rw lock for bind hash-table RDS: increase size of hash-table to 8K RDS: defer the over_batch work to send worker RDS: use rds_send_xmit() state instead of RDS_LL_SEND_FULL RDS: ack more receive completions to improve performance RDS: split send completion handling and do batch ack RDS: handle rds_ibdev release case instead of crashing the kernel RDS: fix the rds_ib_fmr_wq kick call RDS: use already available pool handle from ibmr RDS: mark rds_ib_fmr_wq static RDS: use max_mr from HCA caps than max_fmr RDS: split mr pool to improve 8K messages performance net/rds/af_rds.c | 8 +--- net/rds/bind.c | 78 ++ net/rds/ib.c | 47 -- net/rds/ib.h | 78 +++--- net/rds/ib_cm.c| 114 ++-- net/rds/ib_rdma.c | 116 ++--- net/rds/ib_recv.c | 136 +++-- net/rds/ib_send.c | 110 --- net/rds/ib_stats.c | 22 + net/rds/rds.h | 1 + net/rds/send.c | 15 -- net/rds/threads.c | 2 + 12 files changed, 446 insertions(+), 281 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/
[PATCH 03/15] RDS: fix rds_sock reference bug while doing bind
One need to take rds socket reference while using it and release it
once done with it. rds_add_bind() code path does not do that so
lets fix it.
Signed-off-by: Santosh Shilimkar
Signed-off-by: Santosh Shilimkar
---
net/rds/bind.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/net/rds/bind.c b/net/rds/bind.c
index 01989e2..166c605 100644
--- a/net/rds/bind.c
+++ b/net/rds/bind.c
@@ -61,8 +61,10 @@ static struct rds_sock *rds_bind_lookup(__be32 addr, __be16
port,
cmp = ((u64)be32_to_cpu(rs->rs_bound_addr) << 32) |
be16_to_cpu(rs->rs_bound_port);
- if (cmp == needle)
+ if (cmp == needle) {
+ rds_sock_addref(rs);
return rs;
+ }
}
if (insert) {
@@ -94,10 +96,10 @@ struct rds_sock *rds_find_bound(__be32 addr, __be16 port)
rs = rds_bind_lookup(addr, port, NULL);
read_unlock_irqrestore(_bind_lock, flags);
- if (rs && !sock_flag(rds_rs_to_sk(rs), SOCK_DEAD))
- rds_sock_addref(rs);
- else
+ if (rs && sock_flag(rds_rs_to_sk(rs), SOCK_DEAD)) {
+ rds_sock_put(rs);
rs = NULL;
+ }
rdsdebug("returning rs %p for %pI4:%u\n", rs, ,
ntohs(port));
@@ -123,14 +125,18 @@ static int rds_add_bound(struct rds_sock *rs, __be32
addr, __be16 *port)
write_lock_irqsave(_bind_lock, flags);
do {
+ struct rds_sock *rrs;
if (rover == 0)
rover++;
- if (!rds_bind_lookup(addr, cpu_to_be16(rover), rs)) {
+ rrs = rds_bind_lookup(addr, cpu_to_be16(rover), rs);
+ if (!rrs) {
*port = rs->rs_bound_port;
ret = 0;
rdsdebug("rs %p binding to %pI4:%d\n",
rs, , (int)ntohs(*port));
break;
+ } else {
+ rds_sock_put(rrs);
}
} while (rover++ != last);
--
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: can't oom-kill zap the victim's memory?
On 09/19/15 15:24, Linus Torvalds wrote:
On Sat, Sep 19, 2015 at 8:03 AM, Oleg Nesterov wrote:
+
+static void oom_unmap_func(struct work_struct *work)
+{
+ struct mm_struct *mm = xchg(_unmap_mm, NULL);
+
+ if (!atomic_inc_not_zero(>mm_users))
+ return;
+
+ // If this is not safe we can do use_mm() + unuse_mm()
+ down_read(>mmap_sem);
I don't think this is safe.
What makes you sure that we might not deadlock on the mmap_sem here?
For all we know, the process that is going out of memory is in the
middle of a mmap(), and already holds the mmap_sem for writing. No?
Potentially stupid question that others may be asking: Is it legal to
return EINTR from mmap() to let a SIGKILL from the OOM handler punch the
task out of the kernel and back to userspace?
(sorry for the dupe btw, new email client snuck in html and I got bounced)
So at the very least that needs to be a trylock, I think. And I'm not
sure zap_page_range() is ok with the mmap_sem only held for reading.
Normally our rule is that you can *populate* the page tables
concurrently, but you can't tear the down.
Linus
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majord...@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: mailto:"d...@kvack.org;> em...@kvack.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: can't oom-kill zap the victim's memory?
On Sat, Sep 19, 2015 at 8:03 AM, Oleg Nesterov wrote:
> +
> +static void oom_unmap_func(struct work_struct *work)
> +{
> + struct mm_struct *mm = xchg(_unmap_mm, NULL);
> +
> + if (!atomic_inc_not_zero(>mm_users))
> + return;
> +
> + // If this is not safe we can do use_mm() + unuse_mm()
> + down_read(>mmap_sem);
I don't think this is safe.
What makes you sure that we might not deadlock on the mmap_sem here?
For all we know, the process that is going out of memory is in the
middle of a mmap(), and already holds the mmap_sem for writing. No?
So at the very least that needs to be a trylock, I think. And I'm not
sure zap_page_range() is ok with the mmap_sem only held for reading.
Normally our rule is that you can *populate* the page tables
concurrently, but you can't tear the down.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: of_property_count_u32_elems() can return errors
On 09/18, Viresh Kumar wrote:
> On 17-09-15, 11:13, Stephen Boyd wrote:
> > > + count = of_property_count_u32_elems(opp->np, "opp-microvolt");
> > > + if (count < 0) {
> >
> > We can't test count for -EINVAL to detect the missing property
> > because -EINVAL is also returned on a non-multiple of u32 length
> > property? Maybe we shouldn't worry about that case and turn
> > -EINVAL into 0.
>
> So you are saying that we go ahead without regulators if a incorrect
> values are present in opp-microvolt? i.e. even if the length property
> was invalid, we return 0 from this function.
>
> The problem here is that we will try changing the frequency without
> changing the regulator in that case, and it might not be safe for the
> platform, isn't it?
>
Do we care if a platform has changed the length of the property
to something that isn't a multiple of u32? That sounds very rare,
that's all. I agree it's a bug.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] clk: fixes for 4.3-rc2
The following changes since commit 3bba75a2ec32bd5fa7024a4de3b8cf9ee113a76a: clk: rockchip: Add pclk_peri to critical clocks on RK3066/RK3188 (2015-09-10 13:55:30 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git tags/clk-fixes-for-linus for you to fetch changes up to d34e210ed3a28050441f15228fd5ed929028d9cd: drivers: clk: st: Rename st_pll3200c32_407_c0_x into st_pll3200c32_cx_x (2015-09-17 11:51:43 -0700) A few driver fixes for tegra, rockchip, and st SoCs and a two-liner in the framework to avoid oops when get_parent ops return out of range values on tegra platforms. Gabriel Fernandez (1): drivers: clk: st: Rename st_pll3200c32_407_c0_x into st_pll3200c32_cx_x Heiko Stübner (1): clk: rockchip: add critical clock for rk3368 Mans Rullgard (1): clk: check for invalid parent index of orphans in __clk_init() Thierry Reding (1): clk: tegra: dfll: Properly protect OPP list drivers/clk/clk.c | 3 ++- drivers/clk/rockchip/clk-rk3368.c | 6 ++ drivers/clk/st/clkgen-fsyn.c | 8 drivers/clk/st/clkgen-pll.c | 12 ++-- drivers/clk/tegra/clk-dfll.c | 8 +++- 5 files changed, 25 insertions(+), 12 deletions(-) -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] power: charger-manager: comment spelling fixes
By accident I stumbled over a few misspelled words in the
charger-manager header file which this patch fixes. Namely:
- Extcon rather than Exton
- constraint rather than constratint
- existence rather than existance
- difference rather than diffential
While at it also add a missing space before a closing comment star
forward-slash.
Signed-off-by: Marcel Ziswiler
---
include/linux/power/charger-manager.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/linux/power/charger-manager.h
b/include/linux/power/charger-manager.h
index eadf28c..c4fa907 100644
--- a/include/linux/power/charger-manager.h
+++ b/include/linux/power/charger-manager.h
@@ -65,7 +65,7 @@ struct charger_cable {
const char *extcon_name;
const char *name;
- /* The charger-manager use Exton framework*/
+ /* The charger-manager use Extcon framework */
struct extcon_specific_cable_nb extcon_dev;
struct work_struct wq;
struct notifier_block nb;
@@ -94,7 +94,7 @@ struct charger_cable {
* the charger will be maintained with disabled state.
* @cables:
* the array of charger cables to enable/disable charger
- * and set current limit according to constratint data of
+ * and set current limit according to constraint data of
* struct charger_cable if only charger cable included
* in the array of charger cables is attached/detached.
* @num_cables: the number of charger cables.
@@ -148,7 +148,7 @@ struct charger_regulator {
* @polling_interval_ms: interval in millisecond at which
* charger manager will monitor battery health
* @battery_present:
- * Specify where information for existance of battery can be obtained
+ * Specify where information for existence of battery can be obtained
* @psy_charger_stat: the names of power-supply for chargers
* @num_charger_regulator: the number of entries in charger_regulators
* @charger_regulators: array of charger regulators
@@ -156,7 +156,7 @@ struct charger_regulator {
* @thermal_zone : the name of thermal zone for battery
* @temp_min : Minimum battery temperature for charging.
* @temp_max : Maximum battery temperature for charging.
- * @temp_diff : Temperature diffential to restart charging.
+ * @temp_diff : Temperature difference to restart charging.
* @measure_battery_temp:
* true: measure battery temperature
* false: measure ambient temperature
--
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/
[PATCH] fixup! audit: try harder to send to auditd upon netlink failure
A bug was introduced by "audit: try harder to send to auditd upon
netlink failure", caused by incomplete code and a function that expects
a string and does not accept a format plus arguments. Create a
temporary string variable to assemble the output text. It could be
merged as a fixup if it is not yet upstream.
Signed-off-by: Richard Guy Briggs
---
kernel/audit.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/kernel/audit.c b/kernel/audit.c
index 18cdfe2..9d32218 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -420,7 +420,10 @@ restart:
if (audit_pid) {
if (err == -ECONNREFUSED || err == -EPERM
|| ++attempts >= AUDITD_RETRIES) {
- audit_log_lost("audit_pid=%d reset");
+ char s[32];
+
+ snprintf(s, sizeof(s), "audit_pid=%d reset",
audit_pid);
+ audit_log_lost(s);
audit_pid = 0;
audit_sock = NULL;
} else {
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fixup! audit: try harder to send to auditd upon netlink failure
On 15/09/18, Paul Moore wrote:
> On Friday, September 18, 2015 03:52:43 AM Richard Guy Briggs wrote:
> > A bug was introduced by "audit: try harder to send to auditd upon
> > netlink failure", caused by incomplete code and a function that expects
> > a string and does not accept a format plus arguments. Create a
> > temporary string variable to assemble the output text. It could be
> > merged as a fixup if it is not yet upstream.
>
> Ungh, that's embarrassing; I really should have caught that in review. Sigh.
>
> At least it shouldn't cause anything to blow up, just a less than helpful
> message.
Yup, just useless noise.
> I pulled the original patch from linux-audit#next just now, I'll re-add it
> once we sort this out.
Ok...
> Comments below ...
Likewise...
> > Signed-off-by: Richard Guy Briggs
> > ---
> > kernel/audit.c |5 -
> > 1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/kernel/audit.c b/kernel/audit.c
> > index 18cdfe2..60913e6 100644
> > --- a/kernel/audit.c
> > +++ b/kernel/audit.c
> > @@ -420,7 +420,10 @@ restart:
> > if (audit_pid) {
> > if (err == -ECONNREFUSED || err == -EPERM
> >
> > || ++attempts >= AUDITD_RETRIES) {
> >
> > - audit_log_lost("audit_pid=%d reset");
> > + char s[32];
> > +
> > + sprintf(s, "audit_pid=%d reset", audit_pid);
> > + audit_log_lost(s);
>
> Granted 32 bytes should be big enough for the string, but I would feel better
> if we used snprintf() here; make the change and I'll merge the patch with the
> original and push it back to linux-audit#next.
Done...
> Normally I'm not a big fan of amending patches after they have been
> committed,
> but in this case it is in the next branch (doing this for upstream or
> stable-X
> is a big "no") and nothing sits on top of it.
That's the only reason I suggested it...
> > audit_pid = 0;
> > audit_sock = NULL;
> > } else {
>
> paul moore
- RGB
--
Richard Guy Briggs
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 3/4] ARM: dts: sun8i: Enable PWM controller on A23/A33 Q8 format tablets
Hi,
On 09/18/2015 12:25 PM, Chen-Yu Tsai wrote:
On Fri, Sep 18, 2015 at 11:32 PM, Hans de Goede wrote:
Hi,
On 09/18/2015 03:35 AM, Chen-Yu Tsai wrote:
A23/A33 based Q8 format tablets use channel 0 of the PWM controller for
backlight dimming.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-q8-common.dtsi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi
b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index 6f8a8bb4e9bb..4c2d0b459d6f 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -70,6 +70,12 @@
};
};
+ {
+ pinctrl-names = "default";
+ pinctrl-0 = <_pins>;
+ status = "okay";
+};
+
_uart {
pinctrl-names = "default";
pinctrl-0 = <_uart_pins_a>;
I've a feeling this should be in sunxi-q8-common.dtsi not
sun8i-q8-common.dtsi, which requires adding a pwm
node to sun5i.dtsi I'll look into this.
It probably should.
Which means the name of the pinctrl node should be the same
on both, hence my request to rename that. Anyways Maxime
has already merged that now, I'll workaround it and / or
do a followup patch.
IIRC sun5i PWM has only one channel as opposed to
2 on A10/A20.
Nope sun5i has 2 channels, but the second channel is
only routed to the outside on A10s, not on A13.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCIe bus (re-)numbering
On Sat, Sep 19, 2015 at 1:20 AM, Ruud wrote: > Hello all, > > Not a patch, not a complaint: a start of a discussion on PCIe bus > renumbering and bus numbering in general.. > > > The current algorithm seems to allocate 8 extra busnumbers at the > hotplug switch, but clearly 8 is not sufficient for the whole tree > when it is discovered after initial numbering has been assigned. As > the PCIe routing requires the bus numbers to be consecutive as it > describes ranges there are not that many allocation strategies for bus > numbers. It is impossible to predict at boot-time which switch will > require lots of busses and which do not. Well, if you need more than 8 bus number then practical way is booting with pcie switch and late only hot-remove and host-add instead of code hot-add. > > A solution is static assignment (e.g. as described by > http://article.gmane.org/gmane.linux.kernel.pci/45212), but it seems > not convenient to me. Interesting, one patch in that thread looks like try to use bus range blindly. so it is no go. > > I got the impression the most elegant way is to renumber, but at the > same time I doubt. Would the BIOS become confused? Currently the > kernel becomes confused as it renumbers the ethernet interfaces when > the bus-numbers change. Several drivers seem to be locked to the > device by its geographical routing (aka bus << 16 | device << 11 | > function << 8 ). I got the impression that this is the root of the > evil as the bus need not be as constant as expected. Do you mean changing bus number without unloading driver ? No, you can not do that. some device firmware like lsi cards, if you change it's primary bus number, the device will stop working, but that is another problem. For cold hot add several pcie switches, right way would be have a script: 1. remove related children devices. 2. use setpci to clear bus number register 3. remove bridge devices 4. do pci rescan. Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] Phy and mdiobus fixes
Le 09/18/15 02:46, Russell King - ARM Linux a écrit : > Hi, > > While looking at the phy code, I identified a number of weaknesses > where refcounting on device structures was being leaked, where > modules could be removed while in-use, and where the fixed-phy could > end up having unintended consequences caused by incorrect calls to > fixed_phy_update_state(). > > This patch series resolves those issues, some of which were discovered > with testing on an Armada 388 board. Not all patches are fully tested, > particularly the one which touches several network drivers. > > When resolving the struct device refcounting problems, several different > solutions were considered before settling on the implementation here - > one of the considerations was to avoid touching many network drivers. > The solution here is: > > phy_attach*() - takes a refcount > phy_detach*() - drops the phy_attach refcount > > Provided drivers always attach and detach their phys, which they should > already be doing, this should change nothing, even if they leak a refcount. > > of_phy_find_device() and of_* functions which use that take > a refcount. Arrange for this refcount to be dropped once > the phy is attached. > > This is the reason why the previous change is important - we can't drop > this refcount taken by of_phy_find_device() until something else holds > a reference on the device. This resolves the leaked refcount caused by > using of_phy_connect() or of_phy_attach(). > > Even without the above changes, these drivers are leaking by calling > of_phy_find_device(). These drivers are addressed by adding the > appropriate release of that refcount. > > The mdiobus code also suffered from the same kind of leak, but thankfully > this only happened in one place - the mdio-mux code. > > I also found that the try_module_get() in the phy layer code was utterly > useless: phydev->dev.driver was guaranteed to always be NULL, so > try_module_get() was always being called with a NULL argument. I proved > this with my SFP code, which declares its own MDIO bus - the module use > count was never incremented irrespective of how I set the MDIO bus up. > This allowed the MDIO bus code to be removed from the kernel while there > were still PHYs attached to it. > > One other bug was discovered: while using in-band-status with mvneta, it > was found that if a real phy is attached with in-band-status enabled, > and another ethernet interface is using the fixed-phy infrastructure, the > interface using the fixed-phy infrastructure is configured according to > the other interface using the in-band-status - which is caused by the > fixed-phy code not verifying that the phy_device passed in is actually > a fixed-phy device, rather than a real MDIO phy. > > Lastly, having mdio_bus reversing phy_device_register() internals seems > like a layering violation - it's trivial to move that code to the phy > device layer. Reviewed-by: Florian Fainelli Thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 000/102] 4.1.8-stable review
On 09/19/2015 10:27 AM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 4.1.8 release. There are 102 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon Sep 21 17:15:55 UTC 2015. Anything received after that time might be too late. Build is still going on. Early feedback: arm:allmodconfig, arm:multi_v7_defconfig: arch/arm/mach-rockchip/platsmp.c: In function 'rockchip_boot_secondary': arch/arm/mach-rockchip/platsmp.c:154:23: error: 'rockchip_secondary_startup' undeclared Seen (at least) in 4.1 and 4.2. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] genirq: Fix bad IRQ_ONSHOT in forced IRQ setting
On Sun, 20 Sep 2015, Kohji Okuno wrote: > From: Thomas Gleixner > Date: Fri, 18 Sep 2015 16:46:24 +0200 > > On Fri, 18 Sep 2015, Kohji Okuno wrote: > >> > >> irq thread(runs sdhci_thread_irq()) is waiting on > >> drivers/mmc/core/core.c:mmc_wait_for_req_done() in order to access > >> a SDIO register. And, this thread shoud be woken up from > >> sdhci_irq() after the completion of the register access. > >> But, since the IRQ is masked, sdhci_irq() is not called and irq > >> thread can not wake up. This is root cause, I think. > >> What do you think about this? > > > > Ah, that explains it. Let me think about it a bit. > > If something is not clear please let me know. > By the way, even if other issue exists, we should change > irq_setup_forced_threading() as my patch, I think. No, we can't. We can only do that if the interrupt is not shared. Assume the following scenario: request_irq(irq, handler, IRQF_SHARED, "devA", devidA); In case of force threading that sets the oneshot flag for the irq descriptor. Now the sdhci driver is initialized request_thread_irq(irq, handler, thandler, IRQF_SHARED, "sdhci", devidSDHCI); The oneshot flag sticks and you run into exactly the same issue as now. Shared interrupts are a major pain, but we have to deal with them. I'm working on a solution for that issue. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/3] Add __ioread32_copy() and use it
On Fri, Sep 18, 2015 at 12:19:19PM -0700, Andrew Morton wrote: > On Wed, 16 Sep 2015 04:55:46 +0200 Andi Kleen wrote: > > > > Under what circumstances will the compiler (or linker?) do this? > > > > Compiler. > > > > > LTO enabled? > > > > Yes it's for LTO. The optimization allows the compiler to drop unused > > functions, which is very popular with users (a lot use it to get smaller > > kernel images) > > > > Does this look truthful and complete? > > > --- a/include/linux/compiler-gcc.h~a > +++ a/include/linux/compiler-gcc.h > @@ -205,7 +205,10 @@ > > #if GCC_VERSION >= 40600 > /* > - * Tell the optimizer that something else uses this function or variable. > + * When used with Link Time Optimization, gcc can optimize away C functions > or > + * variables which are referenced only from assembly code. __visible tells > the > + * optimizer that something else uses this function or variable, thus > preventing > + * this. Yes, In a few cases I also used it to work around LTO bugs in older gcc releases. I don't think any of those fixes made it into mainline though, and they are not needed anymore with 5.x -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] USB: serial: add Moxa UPORT 11x0 driver
On Fri, Sep 04, 2015 at 07:23:29AM +0200, Mathieu OTHACEHE wrote:
> Add a driver which supports :
>
> - UPort 1110 : 1 port RS-232 USB to Serial Hub.
> - UPort 1130 : 1 port RS-422/485 USB to Serial Hub.
> - UPort 1130I : 1 port RS-422/485 USB to Serial Hub with Isolation.
> - UPort 1150 : 1 port RS-232/422/485 USB to Serial Hub.
> - UPort 1150I : 1 port RS-232/422/485 USB to Serial Hub with Isolation.
>
> This driver is based on GPL MOXA driver written by Hen Huang and available
> on MOXA website. The original driver was based on io_ti serial driver.
>
> Signed-off-by: Mathieu OTHACEHE
Thanks for submitting this driver. Code looks clean, but you should be
able to reuse a whole lot more of the generic usb-serial implementation,
something which should also give better throughput.
Specifically, most of the read and write code can simply be dropped in
favour of the generic implementation.
You must also get rid of the Moxa specific ioctl to set the port mode.
Have a look at the TIOCSRS485 ioctl as a basis for this change (but note
that we may need to extend that interface).
> ---
> drivers/usb/serial/Kconfig | 16 +
> drivers/usb/serial/Makefile |1 +
> drivers/usb/serial/mxu11x0.c | 1500
> ++
> drivers/usb/serial/mxu11x0.h | 199 ++
Just merge the header file with the implementation as it is not used
outside of it.
> +static int closing_wait = MXU1_DEFAULT_CLOSING_WAIT;
This should be configurable per device using TIOCSSERIAL, just drop the
module parameter.
> +static int mxu1_download_firmware(struct usb_serial *serial,
> + const struct firmware *fw_p)
> +{
> + int status = 0;
> + int buffer_size;
> + int pos;
> + int len;
> + int done;
> + __u8 cs = 0;
> + __u8 *buffer;
Only use __u8 when implementing a user-space API (use u8).
> + struct usb_device *dev = serial->dev;
> + struct mxu1_firmware_header *header;
> + unsigned int pipe = usb_sndbulkpipe(dev, serial->port[0]->
> + bulk_out_endpointAddress);
> +
> + buffer_size = fw_p->size +
> + sizeof(struct mxu1_firmware_header);
> + buffer = kmalloc(buffer_size, GFP_KERNEL);
> + if (!buffer)
> + return -ENOMEM;
> +
> + memcpy(buffer, fw_p->data, fw_p->size);
> + memset(buffer + fw_p->size, 0xff, buffer_size - fw_p->size);
> +
> + for (pos = sizeof(struct mxu1_firmware_header);
> + pos < buffer_size; pos++)
> + cs = (__u8)(cs + buffer[pos]);
> +
> + header = (struct mxu1_firmware_header *)buffer;
> + header->wLength = cpu_to_le16(
> + (__u16)(buffer_size - sizeof(struct mxu1_firmware_header)));
> + header->bCheckSum = cs;
> +
> + pr_debug("%s - downloading firmware", __func__);
Drop all pr_debug (and friends) in favour of the more descriptive
dev_dbg.
> +static int mxu1_startup(struct usb_serial *serial)
> +{
> + struct mxu1_device *mxdev;
> + struct usb_device *dev = serial->dev;
> + char fw_name[32];
> + const struct firmware *fw_p = NULL;
> + u16 product_id;
> + int err;
> +
> + pr_debug("%s - product 0x%4X, num configurations %d, configuration
> value %d",
> + __func__, le16_to_cpu(dev->descriptor.idProduct),
> + dev->descriptor.bNumConfigurations,
> + dev->actconfig->desc.bConfigurationValue);
> +
> + /* create device structure */
> + mxdev = kzalloc(sizeof(struct mxu1_device), GFP_KERNEL);
> + if (mxdev == NULL)
> + return -ENOMEM;
> +
> + mutex_init(>mxd_lock);
> + mxdev->mxd_serial = serial;
> + usb_set_serial_data(serial, mxdev);
> +
> + /* determine device type */
> + if (!usb_match_id(serial->interface, mxuport11_idtable))
> + return 0;
This would already have been taken care of by usb-serial core.
> +
> + product_id = dev->descriptor.idProduct;
Missing le16_to_cpu().
> +static int mxu1_set_mcr(struct mxu1_port *mxport, unsigned int mcr)
> +{
> + int status = 0;
> +
> + status = mxu1_write_byte(mxport->mxp_mxdev,
> + mxport->mxp_uart_base_addr +
> + MXU1_UART_OFFSET_MCR,
> + MXU1_MCR_RTS | MXU1_MCR_DTR | MXU1_MCR_LOOP,
> + mcr);
> +
> + if (!status)
> + mxport->mxp_shadow_mcr = mcr;
No locking?
> +static int mxu1_set_serial_info(struct mxu1_port *mxport,
> + struct serial_struct __user *new_arg)
> +{
> + struct serial_struct new_serial;
> +
> + if (copy_from_user(_serial, new_arg, sizeof(new_serial)))
> + return -EFAULT;
> +
> + mxport->mxp_flags = new_serial.flags & MXU1_SET_SERIAL_FLAGS;
> +
> + if (mxport->mxp_mxdev->mxd_model_name != MXU1_MODEL_1110) {
> + /* UPort 1130, 1150, 1150I */
> + switch (new_serial.port) {
Hmm,
[PATCH 2/4] powerpc/device-tree: bindings for DSP cores/clusters for Freescale SOCs
From: poonam aggrwal
Device Tree Bindings for DSP CPU clusters and DSP CPUs for Freescale PowerPC
SOCs which have DSP CPUs in addition to PowerPC CPUs.
For example B4860 has 3 DSP clusters which have 2 SC3900 cores each.
Signed-off-by: Poonam Aggrwal
---
- based of: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
branch master
This patch was sent earlier and some comments were received. Some have been
taken care; others we can further discuss. Apologize for not following up
on them in time.
.../devicetree/bindings/powerpc/fsl/dsp-cpus.txt | 78 ++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt
diff --git a/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt
b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt
new file mode 100644
index 000..6d901ef
--- /dev/null
+++ b/Documentation/devicetree/bindings/powerpc/fsl/dsp-cpus.txt
@@ -0,0 +1,78 @@
+===
+Binding for DSP CPU clusters and DSP CPUs for Freescale SOCs which
+have DSP CPUs in addition to PowerPC cpus.
+Copyright 2013 Freescale Semiconductor Inc.
+
+Power Architecture CPUs in Freescale SOCs are represented in device trees as
+per the definition in ePAPR.
+
+Required properties for DSP CPU cluster:
+- compatible : should be "fsl,sc3900-cluster".
+- reg : should contain the cluster index
+
+Required properties for DSP CPU:
+- compatible : should be "fsl,sc3900".
+- reg : should contain index of DSP CPU within the DSP clsuter.
+- next-level-cache : should point to the phandle of the next-level L2 cache.
+
+Example for B4860:
+B4860 SOC of Freescale has 3 DSP clusters. Each DSP cluster has 2 DSP CPUs
each.
+The DSP CPUs are SC3900. There is a shared L2 cache per DSP cluster.
+ dsp-clusters {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dsp-cluster0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,sc3900-cluster";
+ reg = <0>;
+
+ dsp0: dsp@0 {
+ compatible = "fsl,sc3900";
+ reg = <0>;
+ next-level-cache = <_2>;
+ };
+ dsp1: dsp@1 {
+ compatible = "fsl,sc3900";
+ reg = <1>;
+ next-level-cache = <_2>;
+ };
+ };
+
+ dsp-cluster1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,sc3900-cluster";
+ reg = <1>;
+
+ dsp2: dsp@2 {
+ compatible = "fsl,sc3900";
+ reg = <2>;
+ next-level-cache = <_3>;
+ };
+ dsp3: dsp@3 {
+ compatible = "fsl,sc3900";
+ reg = <3>;
+ next-level-cache = <_3>;
+ };
+ };
+
+ dsp-cluster2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "fsl,sc3900-cluster";
+ reg = <2>;
+
+ dsp4: dsp@4 {
+ compatible = "fsl,sc3900";
+ reg = <4>;
+ next-level-cache = <_4>;
+ };
+ dsp5: dsp@5 {
+ compatible = "fsl,sc3900";
+ reg = <5>;
+ next-level-cache = <_4>;
+ };
+ };
+ };
--
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 3.10 13/20] HID: usbhid: Fix the check for HID_RESET_PENDING in hid_io_error
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Don Zickus
commit 3af4e5a95184d6d3c1c6a065f163faa174a96a1d upstream.
It was reported that after 10-20 reboots, a usb keyboard plugged
into a docking station would not work unless it was replugged in.
Using usbmon, it turns out the interrupt URBs were streaming with
callback errors of -71 for some reason. The hid-core.c::hid_io_error was
supposed to retry and then reset, but the reset wasn't really happening.
The check for HID_NO_BANDWIDTH was inverted. Fix was simple.
Tested by reporter and locally by me by unplugging a keyboard halfway until I
could recreate a stream of errors but no disconnect.
Signed-off-by: Don Zickus
Signed-off-by: Jiri Kosina
Signed-off-by: Greg Kroah-Hartman
---
drivers/hid/usbhid/hid-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/hid/usbhid/hid-core.c
+++ b/drivers/hid/usbhid/hid-core.c
@@ -180,7 +180,7 @@ static void hid_io_error(struct hid_devi
if (time_after(jiffies, usbhid->stop_retry)) {
/* Retries failed, so do a port reset unless we lack bandwidth*/
- if (test_bit(HID_NO_BANDWIDTH, >iofl)
+ if (!test_bit(HID_NO_BANDWIDTH, >iofl)
&& !test_and_set_bit(HID_RESET_PENDING, >iofl)) {
schedule_work(>reset_work);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.10 01/20] DRM - radeon: Dont link train DisplayPort on HPD until we get the dpcd
3.10-stable review patch. If anyone has any objections, please let me know.
--
From: Stephen Chandler Paul
commit 924f92bf12bfbef3662619e3ed24a1cea7c1cbcd upstream.
Most of the time this isn't an issue since hotplugging an adaptor will
trigger a crtc mode change which in turn, causes the driver to probe
every DisplayPort for a dpcd. However, in cases where hotplugging
doesn't cause a mode change (specifically when one unplugs a monitor
from a DisplayPort connector, then plugs that same monitor back in
seconds later on the same port without any other monitors connected), we
never probe for the dpcd before starting the initial link training. What
happens from there looks like this:
- GPU has only one monitor connected. It's connected via
DisplayPort, and does not go through an adaptor of any sort.
- User unplugs DisplayPort connector from GPU.
- Change in HPD is detected by the driver, we probe every
DisplayPort for a possible connection.
- Probe the port the user originally had the monitor connected
on for it's dpcd. This fails, and we clear the first (and only
the first) byte of the dpcd to indicate we no longer have a
dpcd for this port.
- User plugs the previously disconnected monitor back into the
same DisplayPort.
- radeon_connector_hotplug() is called before everyone else,
and tries to handle the link training. Since only the first
byte of the dpcd is zeroed, the driver is able to complete
link training but does so against the wrong dpcd, causing it
to initialize the link with the wrong settings.
- Display stays blank (usually), dpcd is probed after the
initial link training, and the driver prints no obvious
messages to the log.
In theory, since only one byte of the dpcd is chopped off (specifically,
the byte that contains the revision information for DisplayPort), it's
not entirely impossible that this bug may not show on certain monitors.
For instance, the only reason this bug was visible on my ASUS PB238
monitor was due to the fact that this monitor using the enhanced framing
symbol sequence, the flag for which is ignored if the radeon driver
thinks that the DisplayPort version is below 1.1.
Signed-off-by: Stephen Chandler Paul
Reviewed-by: Jerome Glisse
Signed-off-by: Alex Deucher
Signed-off-by: Greg Kroah-Hartman
---
drivers/gpu/drm/radeon/radeon_connectors.c |5 +
1 file changed, 5 insertions(+)
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -78,6 +78,11 @@ void radeon_connector_hotplug(struct drm
if (!radeon_hpd_sense(rdev, radeon_connector->hpd.hpd))
{
drm_helper_connector_dpms(connector,
DRM_MODE_DPMS_OFF);
} else if
(radeon_dp_needs_link_train(radeon_connector)) {
+ /* Don't try to start link training before we
+* have the dpcd */
+ if (!radeon_dp_getdpcd(radeon_connector))
+ return;
+
/* set it to OFF so that
drm_helper_connector_dpms()
* won't return immediately since the current
state
* is ON at this point.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3.10 14/20] xtensa: fix threadptr reload on return to userspace
3.10-stable review patch. If anyone has any objections, please let me know. -- From: Max Filippov commit 4229fb12a03e5da5882b420b0aa4a02e77447b86 upstream. Userspace return code may skip restoring THREADPTR register if there are no registers that need to be zeroed. This leads to spurious failures in libc NPTL tests. Always restore THREADPTR on return to userspace. Signed-off-by: Max Filippov Signed-off-by: Greg Kroah-Hartman --- arch/xtensa/kernel/entry.S |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- a/arch/xtensa/kernel/entry.S +++ b/arch/xtensa/kernel/entry.S @@ -549,12 +549,13 @@ user_exception_exit: * (if we have restored WSBITS-1 frames). */ +2: #if XCHAL_HAVE_THREADPTR l32ia3, a1, PT_THREADPTR wur a3, threadptr #endif -2: j common_exception_exit + j common_exception_exit /* This is the kernel exception exit. * We avoided to do a MOVSP when we entered the exception, but we -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
