* Re: [PATCH v2 1/2] extcon: cros-ec: Add extcon-cros-ec driver to support display out.
From: Lee Jones @ 2017-04-24 11:58 UTC (permalink / raw)
To: Enric Balletbo i Serra
Cc: Chanwoo Choi, MyungJoo Ham, Rob Herring, linux-kernel, devicetree,
Benson Leung
In-Reply-To: <cb06a494-3bce-0240-9a87-74a7942d4bf6@collabora.com>
On Mon, 10 Apr 2017, Enric Balletbo i Serra wrote:
>
>
> On 05/04/17 03:21, Chanwoo Choi wrote:
> > Hi Enric,
> >
> > On 2017년 03월 02일 16:29, Chanwoo Choi wrote:
> >> Hi,
> >>
> >> On 2017년 03월 01일 20:19, Enric Balletbo i Serra wrote:
> >>> From: Benson Leung <bleung@chromium.org>
> >>>
> >>> This is the driver for the USB Type C cable detection mechanism
> >>> built into the ChromeOS Embedded Controller on systems that
> >>> have USB Type-C ports.
> >>>
> >>> At present, this allows for the presence of display out, but in
> >>> future, it may also be used to notify host and device type cables
> >>> and the presence of power.
> >>>
> >>> Signed-off-by: Benson Leung <bleung@chromium.org>
> >>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
> >>> ---
> >>> Changes since v1:
> >>> Requested by Chanwoo Choi
> >>> - Rename files changing _ for -
> >>> - Remove the unneeded blank line on bottom of header.
> >>> - Remove kobject.h and cros_ec_commands.h includes.
> >>> - Remove the debug message as is not necessary.
> >>> - Use the tab for indentation instead of space for if sentence.
> >>> - Define each variable on different lines when the variables should be
> >>> initialized.
> >>> - Remove EXTCON_USB and EXTCON_USB_HOST as are not really used for now.
> >>> - Add one blank line to split out between state and property setting.
> >>> - Add the author information (header and module)
> >>>
> >>> Enric Balletbo
> >>> - As Rob suggested to rename the compatible name to something indicating that
> >>> is USB Type C related I also renamed the file names, extcon-cros-ec ->
> >>> extcon-usbc-cros-ec, I think it's more clear.
> >>>
> >>> drivers/extcon/Kconfig | 7 +
> >>> drivers/extcon/Makefile | 1 +
> >>> drivers/extcon/extcon-usbc-cros-ec.c | 415 +++++++++++++++++++++++++++++++++++
> >>> include/linux/mfd/cros_ec_commands.h | 75 +++++++
> >>> 4 files changed, 498 insertions(+)
> >>> create mode 100644 drivers/extcon/extcon-usbc-cros-ec.c
> >>>
> >>
> >> Looks good to me.
> >> Acked-by: Chanwoo Choi <cw00.chio@samsung.com>
> >>
> >> I think this patch should be handled with patches[1].
> >> [1] https://lkml.org/lkml/2017/2/14/655
> >>
> >> I think that one maintainer among following subsystems
> >> (mfd, chrome h/w platform, rtc and extcon)
> >> will apply their git repository, and then one maintainer
> >> will send the pull request of immutable branch for these patches.
> >>
> >
> > As I mentioned, these patch should be handled with related patches[1].
> > [1] https://lkml.org/lkml/2017/2/14/655
> >
> > So, I can't apply these patch on extcon git because there is a merge conflict
> > and we should handle these patches with immutable branch between subsystem maintainer.
> >
> > The v4.11-rc5 was released, if you want to apply this patch to the v4.12-rc1,
> > please take care of these patches.
> >
>
> Thanks, unfortunately the above patch dependency is not merged yet, I'll take
> care of these an resend this series rebased again once I have the confirmation
> of the above patch is merged or in a immutable branch.
I guess this patch will have to wait until v3.13 now.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v3 03/12] dt-bindings: make AXP20X compatible strings one per line
From: Lee Jones @ 2017-04-24 12:07 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-4-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> In the binding documentation of AXP20X mfd, the compatible strings used
> to be listed for three per line, which leads to some mess when trying to
> add AXP803 compatible string (as we have already AXP806 and AXP809
> compatibles, which is after AXP803 in ascending order).
>
> Make the compatible strings one per line, so that inserting a new
> compatible string will be directly a new line.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> New patch in v3.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index b41d2601c6ba..a3e813f6060a 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -9,9 +9,14 @@ axp223 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> -- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
> - "x-powers,axp221", "x-powers,axp223", "x-powers,axp806",
> - "x-powers,axp809"
> +- compatible: should be one of:
> + * "x-powers,axp152"
> + * "x-powers,axp202"
> + * "x-powers,axp209"
> + * "x-powers,axp221"
> + * "x-powers,axp223"
> + * "x-powers,axp806"
> + * "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
> - interrupt-parent: The parent interrupt controller
> - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 04/12] dt-bindings: add device tree binding for X-Powers AXP803 PMIC
From: Lee Jones @ 2017-04-24 12:08 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-5-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a PMIC produced by Shenzhen X-Powers, with either I2C or RSB
> bus.
>
> Add a compatible for it.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Changes in v3:
> - Make the compatible one-liner.
> Changes in v2:
> - Place AXP803 before AXP806/809.
> - Added Chen-Yu's ACK.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index a3e813f6060a..44df88be3c89 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -6,6 +6,7 @@ axp202 (X-Powers)
> axp209 (X-Powers)
> axp221 (X-Powers)
> axp223 (X-Powers)
> +axp803 (X-Powers)
> axp809 (X-Powers)
>
> Required properties:
> @@ -15,6 +16,7 @@ Required properties:
> * "x-powers,axp209"
> * "x-powers,axp221"
> * "x-powers,axp223"
> + * "x-powers,axp803"
> * "x-powers,axp806"
> * "x-powers,axp809"
> - reg: The I2C slave address or RSB hardware address for the AXP chip
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 05/12] mfd: axp20x: support AXP803 variant
From: Lee Jones @ 2017-04-24 12:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-6-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 is a new PMIC chip produced by X-Powers, usually paired with A64
> via RSB bus. The PMIC itself is like AXP288, but with RSB support and
> dedicated VBUS and ACIN.
>
> Add support for it in the axp20x mfd driver.
>
> Currently only power key function is supported.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> ---
> This patch is said to be applied by Lee Jones, however, I didn't see it
> in the linux-next, so I included it in the patchset now.
>
> Changes in v2:
> - Share regmap configs with AXP288.
> - Place AXP803 bits before AXP806/809.
>
> drivers/mfd/axp20x-rsb.c | 1 +
> drivers/mfd/axp20x.c | 79 ++++++++++++++++++++++++++++++++++++++++++++++
> include/linux/mfd/axp20x.h | 40 ++++++++++++++++++++++-
> 3 files changed, 119 insertions(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
> index a732cb50bcff..fd5c7267b136 100644
> --- a/drivers/mfd/axp20x-rsb.c
> +++ b/drivers/mfd/axp20x-rsb.c
> @@ -61,6 +61,7 @@ static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
>
> static const struct of_device_id axp20x_rsb_of_match[] = {
> { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
> + { .compatible = "x-powers,axp803", .data = (void *)AXP803_ID },
> { .compatible = "x-powers,axp806", .data = (void *)AXP806_ID },
> { .compatible = "x-powers,axp809", .data = (void *)AXP809_ID },
> { },
> diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
> index e6f55079876e..1dc6235778eb 100644
> --- a/drivers/mfd/axp20x.c
> +++ b/drivers/mfd/axp20x.c
> @@ -41,6 +41,7 @@ static const char * const axp20x_model_names[] = {
> "AXP221",
> "AXP223",
> "AXP288",
> + "AXP803",
> "AXP806",
> "AXP809",
> };
> @@ -117,6 +118,7 @@ static const struct regmap_access_table axp22x_volatile_table = {
> .n_yes_ranges = ARRAY_SIZE(axp22x_volatile_ranges),
> };
>
> +/* AXP288 ranges are shared with the AXP803, as they cover the same range */
> static const struct regmap_range axp288_writeable_ranges[] = {
> regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ6_STATE),
> regmap_reg_range(AXP20X_DCDC_MODE, AXP288_FG_TUNE5),
> @@ -264,6 +266,20 @@ static struct resource axp288_fuel_gauge_resources[] = {
> },
> };
>
> +static struct resource axp803_pek_resources[] = {
> + {
> + .name = "PEK_DBR",
> + .start = AXP803_IRQ_PEK_RIS_EDGE,
> + .end = AXP803_IRQ_PEK_RIS_EDGE,
> + .flags = IORESOURCE_IRQ,
> + }, {
> + .name = "PEK_DBF",
> + .start = AXP803_IRQ_PEK_FAL_EDGE,
> + .end = AXP803_IRQ_PEK_FAL_EDGE,
> + .flags = IORESOURCE_IRQ,
> + },
> +};
> +
> static struct resource axp809_pek_resources[] = {
> {
> .name = "PEK_DBR",
> @@ -457,6 +473,43 @@ static const struct regmap_irq axp288_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP288, BC_USB_CHNG, 5, 1),
> };
>
> +static const struct regmap_irq axp803_regmap_irqs[] = {
> + INIT_REGMAP_IRQ(AXP803, ACIN_OVER_V, 0, 7),
> + INIT_REGMAP_IRQ(AXP803, ACIN_PLUGIN, 0, 6),
> + INIT_REGMAP_IRQ(AXP803, ACIN_REMOVAL, 0, 5),
> + INIT_REGMAP_IRQ(AXP803, VBUS_OVER_V, 0, 4),
> + INIT_REGMAP_IRQ(AXP803, VBUS_PLUGIN, 0, 3),
> + INIT_REGMAP_IRQ(AXP803, VBUS_REMOVAL, 0, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_PLUGIN, 1, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_REMOVAL, 1, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_ENT_ACT_MODE, 1, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_EXIT_ACT_MODE, 1, 4),
> + INIT_REGMAP_IRQ(AXP803, CHARG, 1, 3),
> + INIT_REGMAP_IRQ(AXP803, CHARG_DONE, 1, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH, 2, 7),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_HIGH_END, 2, 6),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW, 2, 5),
> + INIT_REGMAP_IRQ(AXP803, BATT_CHG_TEMP_LOW_END, 2, 4),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH, 2, 3),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_HIGH_END, 2, 2),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW, 2, 1),
> + INIT_REGMAP_IRQ(AXP803, BATT_ACT_TEMP_LOW_END, 2, 0),
> + INIT_REGMAP_IRQ(AXP803, DIE_TEMP_HIGH, 3, 7),
> + INIT_REGMAP_IRQ(AXP803, GPADC, 3, 2),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL1, 3, 1),
> + INIT_REGMAP_IRQ(AXP803, LOW_PWR_LVL2, 3, 0),
> + INIT_REGMAP_IRQ(AXP803, TIMER, 4, 7),
> + INIT_REGMAP_IRQ(AXP803, PEK_RIS_EDGE, 4, 6),
> + INIT_REGMAP_IRQ(AXP803, PEK_FAL_EDGE, 4, 5),
> + INIT_REGMAP_IRQ(AXP803, PEK_SHORT, 4, 4),
> + INIT_REGMAP_IRQ(AXP803, PEK_LONG, 4, 3),
> + INIT_REGMAP_IRQ(AXP803, PEK_OVER_OFF, 4, 2),
> + INIT_REGMAP_IRQ(AXP803, GPIO1_INPUT, 4, 1),
> + INIT_REGMAP_IRQ(AXP803, GPIO0_INPUT, 4, 0),
> + INIT_REGMAP_IRQ(AXP803, BC_USB_CHNG, 5, 1),
> + INIT_REGMAP_IRQ(AXP803, MV_CHNG, 5, 0),
> +};
> +
> static const struct regmap_irq axp806_regmap_irqs[] = {
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV1, 0, 0),
> INIT_REGMAP_IRQ(AXP806, DIE_TEMP_HIGH_LV2, 0, 1),
> @@ -557,6 +610,18 @@ static const struct regmap_irq_chip axp288_regmap_irq_chip = {
>
> };
>
> +static const struct regmap_irq_chip axp803_regmap_irq_chip = {
> + .name = "axp803",
> + .status_base = AXP20X_IRQ1_STATE,
> + .ack_base = AXP20X_IRQ1_STATE,
> + .mask_base = AXP20X_IRQ1_EN,
> + .mask_invert = true,
> + .init_ack_masked = true,
> + .irqs = axp803_regmap_irqs,
> + .num_irqs = ARRAY_SIZE(axp803_regmap_irqs),
> + .num_regs = 6,
> +};
> +
> static const struct regmap_irq_chip axp806_regmap_irq_chip = {
> .name = "axp806",
> .status_base = AXP20X_IRQ1_STATE,
> @@ -778,6 +843,14 @@ static struct mfd_cell axp288_cells[] = {
> },
> };
>
> +static struct mfd_cell axp803_cells[] = {
> + {
> + .name = "axp20x-pek",
> + .num_resources = ARRAY_SIZE(axp803_pek_resources),
> + .resources = axp803_pek_resources,
> + }
> +};
> +
> static struct mfd_cell axp806_cells[] = {
> {
> .id = 2,
> @@ -864,6 +937,12 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
> axp20x->regmap_irq_chip = &axp288_regmap_irq_chip;
> axp20x->irq_flags = IRQF_TRIGGER_LOW;
> break;
> + case AXP803_ID:
> + axp20x->nr_cells = ARRAY_SIZE(axp803_cells);
> + axp20x->cells = axp803_cells;
> + axp20x->regmap_cfg = &axp288_regmap_config;
> + axp20x->regmap_irq_chip = &axp803_regmap_irq_chip;
> + break;
> case AXP806_ID:
> axp20x->nr_cells = ARRAY_SIZE(axp806_cells);
> axp20x->cells = axp806_cells;
> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> index dc8798cf2a24..cde56cfe8446 100644
> --- a/include/linux/mfd/axp20x.h
> +++ b/include/linux/mfd/axp20x.h
> @@ -20,6 +20,7 @@ enum axp20x_variants {
> AXP221_ID,
> AXP223_ID,
> AXP288_ID,
> + AXP803_ID,
> AXP806_ID,
> AXP809_ID,
> NR_AXP20X_VARIANTS,
> @@ -234,7 +235,7 @@ enum axp20x_variants {
> #define AXP22X_TS_ADC_L 0x59
> #define AXP22X_BATLOW_THRES1 0xe6
>
> -/* AXP288 specific registers */
> +/* AXP288/AXP803 specific registers */
> #define AXP288_POWER_REASON 0x02
> #define AXP288_BC_GLOBAL 0x2c
> #define AXP288_BC_VBUS_CNTL 0x2d
> @@ -475,6 +476,43 @@ enum axp288_irqs {
> AXP288_IRQ_BC_USB_CHNG,
> };
>
> +enum axp803_irqs {
> + AXP803_IRQ_ACIN_OVER_V = 1,
> + AXP803_IRQ_ACIN_PLUGIN,
> + AXP803_IRQ_ACIN_REMOVAL,
> + AXP803_IRQ_VBUS_OVER_V,
> + AXP803_IRQ_VBUS_PLUGIN,
> + AXP803_IRQ_VBUS_REMOVAL,
> + AXP803_IRQ_BATT_PLUGIN,
> + AXP803_IRQ_BATT_REMOVAL,
> + AXP803_IRQ_BATT_ENT_ACT_MODE,
> + AXP803_IRQ_BATT_EXIT_ACT_MODE,
> + AXP803_IRQ_CHARG,
> + AXP803_IRQ_CHARG_DONE,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH,
> + AXP803_IRQ_BATT_CHG_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW,
> + AXP803_IRQ_BATT_CHG_TEMP_LOW_END,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH,
> + AXP803_IRQ_BATT_ACT_TEMP_HIGH_END,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW,
> + AXP803_IRQ_BATT_ACT_TEMP_LOW_END,
> + AXP803_IRQ_DIE_TEMP_HIGH,
> + AXP803_IRQ_GPADC,
> + AXP803_IRQ_LOW_PWR_LVL1,
> + AXP803_IRQ_LOW_PWR_LVL2,
> + AXP803_IRQ_TIMER,
> + AXP803_IRQ_PEK_RIS_EDGE,
> + AXP803_IRQ_PEK_FAL_EDGE,
> + AXP803_IRQ_PEK_SHORT,
> + AXP803_IRQ_PEK_LONG,
> + AXP803_IRQ_PEK_OVER_OFF,
> + AXP803_IRQ_GPIO1_INPUT,
> + AXP803_IRQ_GPIO0_INPUT,
> + AXP803_IRQ_BC_USB_CHNG,
> + AXP803_IRQ_MV_CHNG,
> +};
> +
> enum axp806_irqs {
> AXP806_IRQ_DIE_TEMP_HIGH_LV1,
> AXP806_IRQ_DIE_TEMP_HIGH_LV2,
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v3 07/12] dt-bindings: add AXP803's regulator info
From: Lee Jones @ 2017-04-24 12:09 UTC (permalink / raw)
To: Icenowy Zheng
Cc: Rob Herring, Chen-Yu Tsai, Maxime Ripard, Liam Girdwood,
Mark Brown, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20170417115747.7300-8-icenowy-h8G6r0blFSE@public.gmane.org>
On Mon, 17 Apr 2017, Icenowy Zheng wrote:
> AXP803 have the most regulators in currently supported AXP PMICs.
>
> Add info for the regulators in the dt-bindings document.
>
> Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> Changes in v3:
> - Added Rob's ACK.
> Changes in v2:
> - Place AXP803 regulators before AXP806/809 ones.
>
> Documentation/devicetree/bindings/mfd/axp20x.txt | 27 ++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
> index 44df88be3c89..aca09af66514 100644
> --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
> +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
> @@ -96,6 +96,33 @@ LDO_IO1 : LDO : ips-supply : GPIO 1
> RTC_LDO : LDO : ips-supply : always on
> DRIVEVBUS : Enable output : drivevbus-supply : external regulator
>
> +AXP803 regulators, type, and corresponding input supply names:
> +
> +Regulator Type Supply Name Notes
> +--------- ---- ----------- -----
> +DCDC1 : DC-DC buck : vin1-supply
> +DCDC2 : DC-DC buck : vin2-supply : poly-phase capable
> +DCDC3 : DC-DC buck : vin3-supply : poly-phase capable
> +DCDC4 : DC-DC buck : vin4-supply
> +DCDC5 : DC-DC buck : vin5-supply : poly-phase capable
> +DCDC6 : DC-DC buck : vin6-supply : poly-phase capable
> +DC1SW : On/Off Switch : : DCDC1 secondary output
> +ALDO1 : LDO : aldoin-supply : shared supply
> +ALDO2 : LDO : aldoin-supply : shared supply
> +ALDO3 : LDO : aldoin-supply : shared supply
> +DLDO1 : LDO : dldoin-supply : shared supply
> +DLDO2 : LDO : dldoin-supply : shared supply
> +DLDO3 : LDO : dldoin-supply : shared supply
> +DLDO4 : LDO : dldoin-supply : shared supply
> +ELDO1 : LDO : eldoin-supply : shared supply
> +ELDO2 : LDO : eldoin-supply : shared supply
> +ELDO3 : LDO : eldoin-supply : shared supply
> +FLDO1 : LDO : fldoin-supply : shared supply
> +FLDO2 : LDO : fldoin-supply : shared supply
> +LDO_IO0 : LDO : ips-supply : GPIO 0
> +LDO_IO1 : LDO : ips-supply : GPIO 1
> +RTC_LDO : LDO : ips-supply : always on
> +
> AXP806 regulators, type, and corresponding input supply names:
>
> Regulator Type Supply Name Notes
--
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 devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:14 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio@vger.kernel.org, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Rob Herring,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <70ffe3343c13d01737bf74e5de4898d0c0be07a0.1491405475.git-series.gregory.clement@free-electrons.com>
On Wed, Apr 5, 2017 at 5:18 PM, Gregory CLEMENT
<gregory.clement@free-electrons.com> wrote:
> The Armada 37xx SoCs can handle interrupt through GPIO. However it can
> only manage the edge ones.
>
> The way the interrupt are managed are classical so we can use the generic
> interrupt chip model.
>
> The only unusual "feature" is that many interrupts are connected to the
> parent interrupt controller. But we do not take advantage of this and use
> the chained irq with all of them.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
There are some issues with this patch.
First:
You need to add
select GPIOLIB_IRQCHIP
to the Kconfig entry. It's only working in your setup
because something else is selecting this for you, probably.
At all places like this:
> + u32 mask = d->mask;
(...)
> + if (on)
> + val |= mask;
> + else
> + val &= ~mask;
Isn't it simpler to just use d->mask directly in the code and skip the local
variable?
if (on)
val |= d->mask;
(...)
> +static void armada_37xx_irq_handler(struct irq_desc *desc)
> +{
> + struct gpio_chip *gc = irq_desc_get_handler_data(desc);
> + struct irq_chip *chip = irq_desc_get_chip(desc);
> + struct armada_37xx_pinctrl *info = gpiochip_get_data(gc);
> + struct irq_domain *d = gc->irqdomain;
> + int i;
> +
> + chained_irq_enter(chip, desc);
> + for (i = 0; i <= d->revmap_size / GPIO_PER_REG; i++) {
> + u32 status;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&info->irq_lock, flags);
> + status = readl_relaxed(info->base + IRQ_STATUS + 4 * i);
> + /* Manage only the interrupt that was enabled */
> + status &= readl_relaxed(info->base + IRQ_EN + 4 * i);
> + spin_unlock_irqrestore(&info->irq_lock, flags);
> + while (status) {
> + u32 hwirq = ffs(status) - 1;
> + u32 virq = irq_find_mapping(d, hwirq +
> + i * GPIO_PER_REG);
> +
> + generic_handle_irq(virq);
> + status &= ~BIT(hwirq);
> + }
You hae a problem here is a new IRQ appears while you are inside
of this loop. You need to re-read the status register for each iteration
(and &= with the IRQ_EN I guess).
> +static int armada_37xx_irqchip_register(struct platform_device *pdev,
> + struct armada_37xx_pinctrl *info)
> +{
> + struct device_node *np = info->dev->of_node;
> + int nrirqs = info->data->nr_pins;
> + struct gpio_chip *gc = &info->gpio_chip;
> + struct irq_chip *irqchip = &info->irq_chip;
> + struct resource res;
> + int ret = -ENODEV, i, nr_irq_parent;
> +
This warrants a comment:
/* Check if we have at least one gpio-controller child node */
> + for_each_child_of_node(info->dev->of_node, np) {
> + if (of_find_property(np, "gpio-controller", NULL)) {
> + ret = 0;
> + break;
> + }
Rewrite:
if (of_property_read_bool(np, "gpio-controller"))
> + };
> + if (ret)
> + return ret;
> +
> + nr_irq_parent = of_irq_count(np);
> + spin_lock_init(&info->irq_lock);
> +
> + if (!nr_irq_parent) {
> + dev_err(&pdev->dev, "Invalid or no IRQ\n");
> + return 0;
> + }
> +
> + if (of_address_to_resource(info->dev->of_node, 1, &res)) {
> + dev_err(info->dev, "cannot find IO resource\n");
> + return -ENOENT;
> + }
> +
> + info->base = devm_ioremap_resource(info->dev, &res);
> + if (IS_ERR(info->base))
> + return PTR_ERR(info->base);
> +
> + irqchip->irq_ack = armada_37xx_irq_ack;
> + irqchip->irq_mask = armada_37xx_irq_mask;
> + irqchip->irq_unmask = armada_37xx_irq_unmask;
> + irqchip->irq_set_wake = armada_37xx_irq_set_wake;
> + irqchip->irq_set_type = armada_37xx_irq_set_type;
> + irqchip->name = info->data->name;
> +
> + ret = gpiochip_irqchip_add(gc, irqchip, 0,
> + handle_edge_irq, IRQ_TYPE_NONE);
> + if (ret) {
> + dev_info(&pdev->dev, "could not add irqchip\n");
> + return ret;
> + }
> +
> + /*
> + * Many interrupts are connected to the parent interrupt
> + * controller. But we do not take advantage of this and use
> + * the chained irq with all of them.
> + */
> + for (i = 0; i < nrirqs; i++) {
> + struct irq_data *d = irq_get_irq_data(gc->irq_base + i);
> +
> + /*
> + * The mask field is a "precomputed bitmask for
> + * accessing the chip registers" which was introduced
> + * for the generic irqchip framework. As we don't use
> + * this framework, we can reuse this field for our own
> + * usage.
> + */
> + d->mask = BIT(i % GPIO_PER_REG);
> + }
> +
> + for (i = 0; i < nr_irq_parent; i++) {
> + int irq = irq_of_parse_and_map(np, i);
> +
> + if (irq < 0)
> + continue;
> +
> + gpiochip_set_chained_irqchip(gc, irqchip, irq,
> + armada_37xx_irq_handler);
> + }
> +
> + return 0;
> +}
> +
> static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> struct armada_37xx_pinctrl *info)
> {
> @@ -496,6 +714,9 @@ static int armada_37xx_gpiochip_register(struct platform_device *pdev,
> ret = devm_gpiochip_add_data(&pdev->dev, gc, info);
> if (ret)
> return ret;
> + ret = armada_37xx_irqchip_register(pdev, info);
> + if (ret)
> + return ret;
>
> return 0;
> }
> --
> git-series 0.9.1
^ permalink raw reply
* Re: [PATCH v4 5/7] pinctrl: aramda-37xx: Add irqchip support
From: Linus Walleij @ 2017-04-24 12:16 UTC (permalink / raw)
To: Gregory CLEMENT
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jason Cooper,
Andrew Lunn, Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Nadav Haklai, Victor Gu, Marcin Wojtas, Wilson Ding, Hua Jing,
Neta Zur Hershkovits
In-Reply-To: <CACRpkdZ=mVXBbVf1iHg8nQ6pYUkvpB+egH+stoMrkD8V_vaYpg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
So I touched something in gmail and it shot off the mail prematurely.
My apologies.
But my review was done anyways.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 1/7] pinctrl: stm32: add possibility to use gpio-ranges to declare bank range
From: Linus Walleij @ 2017-04-24 12:20 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491568984-20169-2-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 7, 2017 at 2:42 PM, Alexandre TORGUE
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
> Use device tree entries to declare gpio range. It will allow to use
> no contiguous gpio bank and holes inside a bank.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/4] pinctrl: stm32: replace device_initcall() with arch_initcall()
From: Linus Walleij @ 2017-04-24 12:22 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <1491577811-26989-3-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Pinctrl has to be registered earlier. Mainly to register bank irqdomain
> earlier as other devices could use interrupts from those irqdomain.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Yeah I also see that a lot. I guess workarounds like this is
necessary.
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v4 13/18] arm64: allwinner: sun50i-a64: add dwmac-sun8i Ethernet driver
From: Corentin Labbe @ 2017-04-24 12:24 UTC (permalink / raw)
To: Maxime Ripard
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, linux-I+IVW8TIWO2tmTQ+vhA3Yw,
catalin.marinas-5wv7dgnIgG8, will.deacon-5wv7dgnIgG8,
peppe.cavallaro-qxv4g6HH51o, alexandre.torgue-qxv4g6HH51o,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20170412124153.q6zvdvqkroizaxgb@lukather>
On Wed, Apr 12, 2017 at 02:41:53PM +0200, Maxime Ripard wrote:
> On Wed, Apr 12, 2017 at 01:13:55PM +0200, Corentin Labbe wrote:
> > The dwmac-sun8i is an Ethernet MAC that supports 10/100/1000 Mbit
> > connections. It is very similar to the device found in the Allwinner
> > H3, but lacks the internal 100 Mbit PHY and its associated control
> > bits.
> > This adds the necessary bits to the Allwinner A64 SoC .dtsi, but keeps
> > it disabled at this level.
> >
> > Signed-off-by: Corentin Labbe <clabbe.montjoie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> > ---
> > arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 37 +++++++++++++++++++++++++++
> > 1 file changed, 37 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > index 0b0f4ab..2569827 100644
> > --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> > @@ -287,6 +287,23 @@
> > bias-pull-up;
> > };
> >
> > + rmii_pins: rmii_pins {
> > + pins = "PD10", "PD11", "PD13", "PD14",
> > + "PD17", "PD18", "PD19", "PD20",
> > + "PD22", "PD23";
>
> Please align the wrapped lines on the first pin.
>
OK
> > + function = "emac";
> > + drive-strength = <40>;
>
> Do you actually need that for all the boards, or only a few of them?
I have tried to use lower value without success on some boards. (opipc/pine64 in my memory)
Regards
Corentin Labbe
^ permalink raw reply
* Re: [PATCH v2 2/7] Documentation: dt: Remove bindings for STM32 pinctrl
From: Linus Walleij @ 2017-04-24 12:25 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-3-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:42 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Remove "ngpios" bindings definition as it is no more used in stm32 pinctrl
> driver.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Fixed up Subject and applied with Rob's ACK.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 4/7] pinctrl: stm32: Add STM32F469 MCU support
From: Linus Walleij @ 2017-04-24 12:27 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491568984-20169-5-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
> This patch which adds STM32F469 pinctrl and GPIO support, relies on the
> generic STM32 pinctrl driver.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Patch applied.
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 5/7] Documentation: dt: Add new compatible to STM32 pinctrl driver bindings
From: Linus Walleij @ 2017-04-24 12:29 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-6-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Add new compatible for stm32f469 MCU.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Fixed up subject and applied.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 6/7] ARM: Kconfig: Introduce MACH_STM32F469 flag
From: Linus Walleij @ 2017-04-24 12:30 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Rob Herring, Mark Rutland, Arnd Bergmann,
Russell King, Olof Johansson, Lee Jones, Jonathan Corbet,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <1491568984-20169-7-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 2:43 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch introduces the MACH_STM32F469 to make possible to only select
> STM32F469 pinctrl driver
>
> By default, all the MACH_STM32Fxxx flags will be set with STM32 defconfig.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Please funnel this through the ARM SoC tree.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 1/4] pinctrl: stm32: set pin to gpio input when used as interrupt
From: Linus Walleij @ 2017-04-24 12:36 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <1491577811-26989-2-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> This patch ensures that pin is correctly set as gpio input when it is used
> as an interrupt.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
(...)
> +static int stm32_gpio_irq_request_resources(struct irq_data *irq_data)
> +{
> + struct stm32_gpio_bank *bank = irq_data->domain->host_data;
> + u32 ret;
> +
> + if (!gpiochip_is_requested(&bank->gpio_chip, irq_data->hwirq)) {
> + ret = stm32_gpio_request(&bank->gpio_chip, irq_data->hwirq);
> + if (ret)
> + return ret;
> + }
This is wrong. You should only use gpiochip_lock_as_irq(), because of the
following in Documentation/gpio/driver.txt:
---------------
It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
irq_chip are orthogonal, and offering their services independent of each
other.
(...)
So always prepare the hardware and make it ready for action in respective
callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
been called first.
This orthogonality leads to ambiguities that we need to solve: if there is
competition inside the subsystem which side is using the resource (a certain
GPIO line and register for example) it needs to deny certain operations and
keep track of usage inside of the gpiolib subsystem. This is why the API
below exists.
Locking IRQ usage
-----------------
Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
to mark the GPIO as being used as an IRQ:
int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
is released:
void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
When implementing an irqchip inside a GPIO driver, these two functions should
typically be called in the .startup() and .shutdown() callbacks from the
irqchip.
When using the gpiolib irqchip helpers, these callback are automatically
assigned.
--------------
It is because of easy to make errors like this that I prefer that people try
to use GPIOLIB_IRQCHIP helpers insteaf of rolling their own irqchip code.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/4] pinctrl: stm32: Implement .get_direction gpio_chip callback
From: Linus Walleij @ 2017-04-24 12:37 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
In-Reply-To: <1491577811-26989-4-git-send-email-alexandre.torgue@st.com>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue@st.com> wrote:
> Add .get_direction() gpiochip callback in STM32 pinctrl driver.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue@st.com>
(...)
> +#include <linux/gpio.h>
No this is wrong, drivers should never include this file.
It is a deprecated consumer header.
> + if ((alt == 0) && (mode == 0))
> + ret = GPIOF_DIR_IN;
> + else if ((alt == 0) && (mode == 1))
> + ret = GPIOF_DIR_OUT;
Just return 0 or 1, that is the driver-internal API.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v14 00/11] mux controller abstraction and iio/i2c muxes
From: Philipp Zabel @ 2017-04-24 12:38 UTC (permalink / raw)
To: Peter Rosin
Cc: Jonathan Cameron, linux-kernel, Greg Kroah-Hartman, Wolfram Sang,
Rob Herring, Mark Rutland, Hartmut Knaack, Lars-Peter Clausen,
Peter Meerwald-Stadler, Jonathan Corbet, linux-i2c, devicetree,
linux-iio, linux-doc, Andrew Morton, Colin Ian King,
Paul Gortmaker, kernel
In-Reply-To: <2d978956-d247-917d-4150-a6723917a733@axentia.se>
On Mon, 2017-04-24 at 13:37 +0200, Peter Rosin wrote:
[...]
> Ok, so the difference is probably that the rwsem locking primitive
> don't have any lockdep checking hooked up. Because the rwsem was
> definitely held in the same way in v13 as the mutex is now held in
> v14, so there's no fundamental difference.
>
> So, yes, we can use some kind of refcount scheme to not hold an actual
> mutex for the duration of the mux select/deselect, but that doesn't
> really change anything. Userspace is still locking something, and that
> seems dangerous. How do you make sure that mux_control_deselect is
> called as it should?
My current video_mux link setup implementation looks like this (it is
called from userspace via the MEDIA_IOC_SETUP_LINK ioctl):
----------8<----------
static int video_mux_link_setup(struct media_entity *entity,
const struct media_pad *local,
const struct media_pad *remote, u32 flags)
{
struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
struct video_mux *video_mux = v4l2_subdev_to_video_mux(sd);
int ret;
/*
* The mux state is determined by the enabled sink pad link.
* Enabling or disabling the source pad link has no effect.
*/
if (!is_sink_pad(video_mux, local->index))
return 0;
dev_dbg(sd->dev, "link setup '%s':%d->'%s':%d[%d]", remote->entity->name,
remote->index, local->entity->name, local->index,
flags & MEDIA_LNK_FL_ENABLED);
if (flags & MEDIA_LNK_FL_ENABLED) {
if (video_mux->active == local->index)
return 0;
if (video_mux->active >= 0)
return -EBUSY;
dev_dbg(sd->dev, "setting %d active\n", local->index);
ret = mux_control_try_select(video_mux->mux, local->index);
if (ret < 0)
return ret;
video_mux->active = local->index;
} else {
if (video_mux->active != local->index)
return 0;
dev_dbg(sd->dev, "going inactive\n");
mux_control_deselect(video_mux->mux);
video_mux->active = -1;
}
return 0;
}
---------->8----------
If a mux state was already selected, this should return -EBUSY, until a
call to disable the active link deselects the mux.
> What I don't like about abandoning the lock is that there is still a
> need to support the multi-consumer case and then you need some way
> of keeping track of waiters. A lock does this, and any attempt to open
> code that will get messy.
>
> What might be better is to support some kind of exclusive mux, i.e. a
> mux that only allows one consumer per mux controller. Then the mux core
> could trust that exclusive consumer to not fuck things up for itself and
> thus have no lock at all for select/deselect for the exclusive case. Or
> perhaps keep a refcount (as you suggested) for the exclusive case so
> that mux_control_try_select still makes sense, because you still want
> that, right?
In the case of an exclusive mux without lock, I don't see any need for a
try_select call.
> The question then becomes how to best tell the mux core that you want
> an exclusive mux. I see two options. Either you declare a mux controller
> as exclusive up front somehow (in the device tree presumably), or you
> add a mux_control_get_exclusive call that makes further calls to
> mux_control_get{,_exclusive} fail with -EBUSY. I think I like the
> latter better, if that can be made to work...
There is a precedent for the latter in the reset controller framework
(reset_control_get_shared and reset_control_get_exclusive variants).
Since this distinction is a matter of usage, and not a hardware property
of the mux/reset controller itself, I'd also prefer that.
regards
Philipp
^ permalink raw reply
* Re: [PATCH V7 4/7] mfd: da9061: MFD core support
From: Lee Jones @ 2017-04-24 12:38 UTC (permalink / raw)
To: Steve Twiss
Cc: LINUX-KERNEL, DEVICETREE, Dmitry Torokhov, Eduardo Valentin,
Guenter Roeck, LINUX-INPUT, LINUX-PM, LINUX-WATCHDOG,
Liam Girdwood, Mark Brown, Mark Rutland, Rob Herring,
Support Opensource, Wim Van Sebroeck, Zhang Rui
In-Reply-To: <6ED8E3B22081A4459DAC7699F3695FB7018CD71434@SW-EX-MBX02.diasemi.com>
On Mon, 24 Apr 2017, Steve Twiss wrote:
> On 04 April 2017 09:39, Lee Jones wrote:
> > Subject: Re: [PATCH V7 4/7] mfd: da9061: MFD core support
> >
> > On Mon, 03 Apr 2017, Steve Twiss wrote:
> > > From: Steve Twiss <stwiss.opensource@diasemi.com>
> > > MFD support for DA9061 is provided as part of the DA9062 device driver.
> > >
> > > The registers header file adds two new chip variant IDs defined in DA9061
> > > and DA9062 hardware. The core header file adds new software enumerations
> > > for listing the valid DA9061 IRQs and a da9062_compatible_types enumeration
> > > for distinguishing between DA9061/62 devices in software.
> > >
> > > The core source code adds a new .compatible of_device_id entry. This is
> > > extended from DA9062 to support both "dlg,da9061" and "dlg,da9062". The
> > > .data entry now holds a reference to the enumerated device type.
> > >
> > > A new regmap_irq_chip model is added for DA9061 and this supports the new
> > > list of regmap_irq entries. A new mfd_cell da9061_devs[] array lists the
> > > new sub system components for DA9061. Support is added for a new DA9061
> > > regmap_config which lists the correct readable, writable and volatile
> > > ranges for this chip.
> > >
> > > The probe function uses the device tree compatible string to switch on the
> > > da9062_compatible_types and configure the correct mfd cells, irq chip and
> > > regmap config.
> > >
> > > Kconfig is updated to reflect support for DA9061 and DA9062 PMICs.
> > >
> > > Signed-off-by: Steve Twiss <stwiss.opensource@diasemi.com>
> >
> > Ah, here it is.
> >
> > Applied, thanks.
>
> Hi Lee,
>
> I noticed the DA9061 core support has been added into linux-next, however
> the commit message was changed from the original title:
>
> "mfd: da9061: MFD core support"
>
> to add the mistake:
>
> "mfd: Add suppfor for DA9061"
>
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d3fe0806025cacdab1462d5704e1c98ab9db4564
>
> Can this be fixed please?
> This patch has not been upstreamed into linux-mainline and is still in linux-next.
You're right, thanks for pointing that out.
Now fixed.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH 4/4] ARM: dts: stm32: Set gpio controller also as interrupt controller
From: Linus Walleij @ 2017-04-24 12:38 UTC (permalink / raw)
To: Alexandre TORGUE
Cc: Maxime Coquelin, Patrice Chotard, Paul Gortmaker, Rob Herring,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491577811-26989-5-git-send-email-alexandre.torgue-qxv4g6HH51o@public.gmane.org>
On Fri, Apr 7, 2017 at 5:10 PM, Alexandre TORGUE
<alexandre.torgue-qxv4g6HH51o@public.gmane.org> wrote:
> This patch set each gpio controller as a interrupt controller. User who
> wants to use gpio as interrupt will have choice to use either "gpiolib"
> interface or "common" interrupt interface.
>
> Signed-off-by: Alexandre TORGUE <alexandre.torgue-qxv4g6HH51o@public.gmane.org>
Acked-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 0/4] mtd: extend support for "fixed-partitions"
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170420135731.13272-2-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
My recent work on adding wide support for linux,part-probe was reviewed and
kind of Nack-ed, but fortunately I was pointed to the old (!) patchset from
Brian doing similar thing in a cleaner way.
This patchset picks the important changes from Brian, cleans them and rebases.
Original patches:
(not picked) [RFC PATCH 1/7] mtd: move partition parsers to drivers/mtd/partitions/
(not picked) [RFC PATCH 2/7] mtd: move partition parsers' Kconfig under a sub-menu
(partially) [RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
(picked) [RFC PATCH 4/7] mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers
(partially) [RFC PATCH 5/7] mtd: partitions: factor out "match by name" handling
(picked) [RFC PATCH 6/7] RFC: mtd: partitions: enable of_match_table matching
(not picked) [RFC PATCH 7/7] mtd: partitions: add Google's FMAP partition parser
At this point this simply adds a full support for "fixed-partitions" binding.
It should also make adding new bindings (like Google's FMAP) easier in the
future.
I've successfully tested this with bcm47xxsflash driver on Tenda AC9 device. I
used following DT node to get "ofpart" driver parse & register my partitions.
&bcma-sflash {
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "cfe";
reg = <0x0000000 0x40000>;
read-only;
};
firmware@40000 {
label = "firmware";
reg = <0x40000 0x7f0000>;
};
};
};
V2: Modify patch 1/4
Include list of original patches in 0/4
Include changelog in every patch
Add Brian's tags (Acked/Reviewed/Tested)
Brian Norris (3):
dt-bindings: mtd: make partitions doc a bit more generic
mtd: partitions: factor out code calling parser
mtd: partitions: add of_match_table parser matching
Rafał Miłecki (1):
mtd: ofpart: add of_match_table with "fixed-partitions"
.../devicetree/bindings/mtd/partition.txt | 30 ++++++--
drivers/mtd/mtdpart.c | 80 +++++++++++++++++++---
drivers/mtd/ofpart.c | 7 ++
include/linux/mtd/partitions.h | 1 +
4 files changed, 103 insertions(+), 15 deletions(-)
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH V2 1/4] dt-bindings: mtd: make partitions doc a bit more generic
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170424124120.31613-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Currently the only documented partitioning is "fixed-partitions" but
there are more methods in use that we may want to support in the future.
Mention them and make it clear Fixed Partitions are just a single case.
Signed-off-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
---
This is based on Brian's patch:
[RFC PATCH 3/7] doc: dt: mtd: partition: add on-flash format binding
V1: Dropped "Section B: On-Flash Partition Tables" with Google's FMAP as this
patchset doesn't add that new parser.
V2: Add "We currently only document a binding for fixed layouts." part
---
.../devicetree/bindings/mtd/partition.txt | 30 +++++++++++++++++-----
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/mtd/partition.txt b/Documentation/devicetree/bindings/mtd/partition.txt
index 81a224da63be..b5de311b967a 100644
--- a/Documentation/devicetree/bindings/mtd/partition.txt
+++ b/Documentation/devicetree/bindings/mtd/partition.txt
@@ -1,29 +1,47 @@
-Representing flash partitions in devicetree
+Flash partitions in device tree
+===============================
-Partitions can be represented by sub-nodes of an mtd device. This can be used
+Flash devices can be partitioned into one or more functional ranges (e.g. "boot
+code", "nvram", "kernel").
+
+Different devices may be partitioned in a different ways. Some may use a fixed
+flash layout set at production time. Some may use on-flash table that describes
+the geometry and naming/purpose of each functional region. It is also possible
+to see these methods mixed.
+
+To assist system software in locating partitions, we provide a binding to
+describe which method is used for a given flash.
+
+We currently only document a binding for fixed layouts.
+
+
+Fixed Partitions
+================
+
+Partitions can be represented by sub-nodes of a flash device. This can be used
on platforms which have strong conventions about which portions of a flash are
used for what purposes, but which don't use an on-flash partition table such
as RedBoot.
-The partition table should be a subnode of the mtd node and should be named
+The partition table should be a subnode of the flash node and should be named
'partitions'. This node should have the following property:
- compatible : (required) must be "fixed-partitions"
Partitions are then defined in subnodes of the partitions node.
-For backwards compatibility partitions as direct subnodes of the mtd device are
+For backwards compatibility partitions as direct subnodes of the flash device are
supported. This use is discouraged.
NOTE: also for backwards compatibility, direct subnodes that have a compatible
string are not considered partitions, as they may be used for other bindings.
#address-cells & #size-cells must both be present in the partitions subnode of the
-mtd device. There are two valid values for both:
+flash device. There are two valid values for both:
<1>: for partitions that require a single 32-bit cell to represent their
size/address (aka the value is below 4 GiB)
<2>: for partitions that require two 32-bit cells to represent their
size/address (aka the value is 4 GiB or greater).
Required properties:
-- reg : The partition's offset and size within the mtd bank.
+- reg : The partition's offset and size within the flash
Optional properties:
- label : The label / name for this partition. If omitted, the label is taken
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 2/4] mtd: partitions: factor out code calling parser
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170424124120.31613-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
This code is going to be reused for parsers matched using OF so let's
factor it out to make this easier.
Signed-off-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Acked-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
This is based on Brian's patch:
[RFC PATCH 5/7] mtd: partitions: factor out "match by name" handling
V1: Do not factor out mtd_part_parser_get_by_name as it's not required by this
patchset.
---
drivers/mtd/mtdpart.c | 33 ++++++++++++++++++++++++---------
1 file changed, 24 insertions(+), 9 deletions(-)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 81e0b80237df..73c52f1a2e4c 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -840,6 +840,27 @@ static const char * const default_mtd_part_types[] = {
NULL
};
+static int mtd_part_do_parse(struct mtd_part_parser *parser,
+ struct mtd_info *master,
+ struct mtd_partitions *pparts,
+ struct mtd_part_parser_data *data)
+{
+ int ret;
+
+ ret = (*parser->parse_fn)(master, &pparts->parts, data);
+ pr_debug("%s: parser %s: %i\n", master->name, parser->name, ret);
+ if (ret <= 0)
+ return ret;
+
+ pr_notice("%d %s partitions found on MTD device %s\n", ret,
+ parser->name, master->name);
+
+ pparts->nr_parts = ret;
+ pparts->parser = parser;
+
+ return ret;
+}
+
/**
* parse_mtd_partitions - parse MTD partitions
* @master: the master partition (describes whole MTD device)
@@ -880,16 +901,10 @@ int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
parser ? parser->name : NULL);
if (!parser)
continue;
- ret = (*parser->parse_fn)(master, &pparts->parts, data);
- pr_debug("%s: parser %s: %i\n",
- master->name, parser->name, ret);
- if (ret > 0) {
- printk(KERN_NOTICE "%d %s partitions found on MTD device %s\n",
- ret, parser->name, master->name);
- pparts->nr_parts = ret;
- pparts->parser = parser;
+ ret = mtd_part_do_parse(parser, master, pparts, data);
+ /* Found partitions! */
+ if (ret > 0)
return 0;
- }
mtd_part_parser_put(parser);
/*
* Stash the first error we see; only report it if no parser
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 3/4] mtd: partitions: add of_match_table parser matching
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170424124120.31613-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Partition parsers can now provide an of_match_table to enable
flash<-->parser matching via device tree.
This support is currently limited to built-in parsers as it uses
request_module() and friends. This should be sufficient for most cases
though as compiling parsers as modules isn't a common choice.
Signed-off-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Acked-by: Brian Norris <computersforpeac-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
This is based on Brian's patches:
[RFC PATCH 4/7] mtd: add of_match_mtd_parser() and of_mtd_match_mtd_parser() helpers
[RFC PATCH 6/7] RFC: mtd: partitions: enable of_match_table matching
V1: Put helpers in mtdpart.c instead of drivers/of/of_mtd.c
Merge helpers into a single of_mtd_match_mtd_parser
---
drivers/mtd/mtdpart.c | 47 ++++++++++++++++++++++++++++++++++++++++++
include/linux/mtd/partitions.h | 1 +
2 files changed, 48 insertions(+)
diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 73c52f1a2e4c..d0cb1a892ed2 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -861,6 +861,41 @@ static int mtd_part_do_parse(struct mtd_part_parser *parser,
return ret;
}
+static bool of_mtd_match_mtd_parser(struct mtd_info *mtd,
+ struct mtd_part_parser *parser)
+{
+ struct device_node *np;
+ bool ret;
+
+ np = mtd_get_of_node(mtd);
+ np = of_get_child_by_name(np, "partitions");
+
+ ret = !!of_match_node(parser->of_match_table, np);
+
+ of_node_put(np);
+
+ return ret;
+}
+
+static struct mtd_part_parser *mtd_part_get_parser_by_of(struct mtd_info *mtd)
+{
+ struct mtd_part_parser *p, *ret = NULL;
+
+ spin_lock(&part_parser_lock);
+
+ list_for_each_entry(p, &part_parsers, list) {
+ if (of_mtd_match_mtd_parser(mtd, p) &&
+ try_module_get(p->owner)) {
+ ret = p;
+ break;
+ }
+ }
+
+ spin_unlock(&part_parser_lock);
+
+ return ret;
+}
+
/**
* parse_mtd_partitions - parse MTD partitions
* @master: the master partition (describes whole MTD device)
@@ -913,6 +948,18 @@ int parse_mtd_partitions(struct mtd_info *master, const char *const *types,
if (ret < 0 && !err)
err = ret;
}
+
+ parser = mtd_part_get_parser_by_of(master);
+ if (!parser)
+ return err;
+
+ ret = mtd_part_do_parse(parser, master, pparts, data);
+ if (ret > 0)
+ return 0;
+ mtd_part_parser_put(parser);
+ if (ret < 0 && !err)
+ err = ret;
+
return err;
}
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 2787e76c030f..073e1d8d5d17 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -77,6 +77,7 @@ struct mtd_part_parser {
struct list_head list;
struct module *owner;
const char *name;
+ const struct of_device_id *of_match_table;
int (*parse_fn)(struct mtd_info *, const struct mtd_partition **,
struct mtd_part_parser_data *);
void (*cleanup)(const struct mtd_partition *pparts, int nr_parts);
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH V2 4/4] mtd: ofpart: add of_match_table with "fixed-partitions"
From: Rafał Miłecki @ 2017-04-24 12:41 UTC (permalink / raw)
To: David Woodhouse, Brian Norris, Boris Brezillon, Marek Vasut,
Richard Weinberger, Cyrille Pitchen
Cc: Rob Herring, Mark Rutland, Frank Rowand, Linus Walleij,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
devicetree-u79uwXL29TY76Z2rM5mHXA, Geert Uytterhoeven,
Jonas Gorski, Rafał Miłecki
In-Reply-To: <20170424124120.31613-1-zajec5-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
From: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
This allows using this parser with any flash driver that takes care of
setting of_node (using mtd_set_of_node helper) correctly. Up to now
support for "fixed-partitions" DT compatibility string was working only
with flash drivers that were specifying "ofpart" (manually or by letting
mtd use the default set of parsers).
This matches existing bindings documentation.
Signed-off-by: Rafał Miłecki <rafal-g1n6cQUeyibVItvQsEIGlw@public.gmane.org>
Reviewed-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Tested-by: Brian Norris <computersforpeace-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
drivers/mtd/ofpart.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/mtd/ofpart.c b/drivers/mtd/ofpart.c
index 2861c7079d7b..fb6f3df40e94 100644
--- a/drivers/mtd/ofpart.c
+++ b/drivers/mtd/ofpart.c
@@ -140,9 +140,16 @@ static int parse_ofpart_partitions(struct mtd_info *master,
return ret;
}
+static const struct of_device_id parse_ofpart_match_table[] = {
+ { .compatible = "fixed-partitions" },
+ {},
+};
+MODULE_DEVICE_TABLE(of, parse_ofpart_match_table);
+
static struct mtd_part_parser ofpart_parser = {
.parse_fn = parse_ofpart_partitions,
.name = "ofpart",
+ .of_match_table = parse_ofpart_match_table,
};
static int parse_ofoldpart_partitions(struct mtd_info *master,
--
2.11.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH v2 1/4] pinctrl: aspeed: Document pinconf in devicetree bindings
From: Linus Walleij @ 2017-04-24 12:42 UTC (permalink / raw)
To: Andrew Jeffery
Cc: Rob Herring, Joel Stanley, Benjamin Herrenschmidt,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, OpenBMC Maillist
In-Reply-To: <20170407125713.15678-2-andrew@aj.id.au>
On Fri, Apr 7, 2017 at 2:57 PM, Andrew Jeffery <andrew@aj.id.au> wrote:
> Signed-off-by: Andrew Jeffery <andrew@aj.id.au>
Patch applied with the ACKs.
Yours,
Linus Walleij
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox