linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 3195 bytes --]

Hi all,

Today's linux-next merge of the gpio-brgl tree got a conflict in:

  drivers/gpio/gpio-twl4030.c

between commit:

  d5f4fa60d63a ("ARM/gpio: Push OMAP2 quirk down into TWL4030 driver")

from the arm-soc tree and commit:

  fbc8ab2ccd85 ("gpio: twl4030: Use devm_gpiochip_add_data() to simplify remove path")

from the gpio-brgl tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpio/gpio-twl4030.c
index 446599ac234a,3708ed2314e8..000000000000
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@@ -490,30 -492,9 +490,18 @@@ static struct twl4030_gpio_platform_dat
  	return omap_twl_info;
  }
  
- /* Cannot use as gpio_twl4030_probe() calls us */
- static int gpio_twl4030_remove(struct platform_device *pdev)
- {
- 	struct gpio_twl4030_priv *priv = platform_get_drvdata(pdev);
- 
- 	gpiochip_remove(&priv->gpio_chip);
- 
- 	/* REVISIT no support yet for deregistering all the IRQs */
- 	WARN_ON(!is_module());
- 	return 0;
- }
- 
 +/* Called from the registered devm action */
 +static void gpio_twl4030_power_off_action(void *data)
 +{
 +	struct gpio_desc *d = data;
 +
 +	gpiod_unexport(d);
 +	gpiochip_free_own_desc(d);
 +}
 +
  static int gpio_twl4030_probe(struct platform_device *pdev)
  {
 -	struct twl4030_gpio_platform_data *pdata = dev_get_platdata(&pdev->dev);
 +	struct twl4030_gpio_platform_data *pdata;
  	struct device_node *node = pdev->dev.of_node;
  	struct gpio_twl4030_priv *priv;
  	int ret, irq_base;
@@@ -586,38 -569,19 +574,35 @@@ no_irqs
  	if (ret < 0) {
  		dev_err(&pdev->dev, "could not register gpiochip, %d\n", ret);
  		priv->gpio_chip.ngpio = 0;
- 		gpio_twl4030_remove(pdev);
- 		goto out;
+ 		return ret;
  	}
  
 -	if (pdata->setup) {
 -		int status;
 +	/*
 +	 * Special quirk for the OMAP3 to hog and export a WLAN power
 +	 * GPIO.
 +	 */
 +	if (IS_ENABLED(CONFIG_ARCH_OMAP3) &&
 +	    of_machine_is_compatible("compulab,omap3-sbc-t3730")) {
 +		struct gpio_desc *d;
 +
 +		d = gpiochip_request_own_desc(&priv->gpio_chip,
 +						 2, "wlan pwr",
 +						 GPIO_ACTIVE_HIGH,
 +						 GPIOD_OUT_HIGH);
 +		if (IS_ERR(d))
 +			return dev_err_probe(&pdev->dev, PTR_ERR(d),
 +					     "unable to hog wlan pwr GPIO\n");
 +
 +		gpiod_export(d, 0);
 +
 +		ret = devm_add_action_or_reset(&pdev->dev, gpio_twl4030_power_off_action, d);
 +		if (ret)
 +			return dev_err_probe(&pdev->dev, ret,
 +					     "failed to install power off handler\n");
  
 -		status = pdata->setup(&pdev->dev, priv->gpio_chip.base,
 -				      TWL4030_GPIO_MAX);
 -		if (status)
 -			dev_dbg(&pdev->dev, "setup --> %d\n", status);
  	}
  
- 	platform_set_drvdata(pdev, priv);
- out:
- 	return ret;
+ 	return 0;
  }
  
  static const struct of_device_id twl_gpio_match[] = {

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 3195 bytes --]

Hi all,

Today's linux-next merge of the gpio-brgl tree got a conflict in:

  drivers/gpio/gpio-twl4030.c

between commit:

  d5f4fa60d63a ("ARM/gpio: Push OMAP2 quirk down into TWL4030 driver")

from the arm-soc tree and commit:

  fbc8ab2ccd85 ("gpio: twl4030: Use devm_gpiochip_add_data() to simplify remove path")

from the gpio-brgl tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpio/gpio-twl4030.c
index 446599ac234a,3708ed2314e8..000000000000
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@@ -490,30 -492,9 +490,18 @@@ static struct twl4030_gpio_platform_dat
  	return omap_twl_info;
  }
  
- /* Cannot use as gpio_twl4030_probe() calls us */
- static int gpio_twl4030_remove(struct platform_device *pdev)
- {
- 	struct gpio_twl4030_priv *priv = platform_get_drvdata(pdev);
- 
- 	gpiochip_remove(&priv->gpio_chip);
- 
- 	/* REVISIT no support yet for deregistering all the IRQs */
- 	WARN_ON(!is_module());
- 	return 0;
- }
- 
 +/* Called from the registered devm action */
 +static void gpio_twl4030_power_off_action(void *data)
 +{
 +	struct gpio_desc *d = data;
 +
 +	gpiod_unexport(d);
 +	gpiochip_free_own_desc(d);
 +}
 +
  static int gpio_twl4030_probe(struct platform_device *pdev)
  {
 -	struct twl4030_gpio_platform_data *pdata = dev_get_platdata(&pdev->dev);
 +	struct twl4030_gpio_platform_data *pdata;
  	struct device_node *node = pdev->dev.of_node;
  	struct gpio_twl4030_priv *priv;
  	int ret, irq_base;
@@@ -586,38 -569,19 +574,35 @@@ no_irqs
  	if (ret < 0) {
  		dev_err(&pdev->dev, "could not register gpiochip, %d\n", ret);
  		priv->gpio_chip.ngpio = 0;
- 		gpio_twl4030_remove(pdev);
- 		goto out;
+ 		return ret;
  	}
  
 -	if (pdata->setup) {
 -		int status;
 +	/*
 +	 * Special quirk for the OMAP3 to hog and export a WLAN power
 +	 * GPIO.
 +	 */
 +	if (IS_ENABLED(CONFIG_ARCH_OMAP3) &&
 +	    of_machine_is_compatible("compulab,omap3-sbc-t3730")) {
 +		struct gpio_desc *d;
 +
 +		d = gpiochip_request_own_desc(&priv->gpio_chip,
 +						 2, "wlan pwr",
 +						 GPIO_ACTIVE_HIGH,
 +						 GPIOD_OUT_HIGH);
 +		if (IS_ERR(d))
 +			return dev_err_probe(&pdev->dev, PTR_ERR(d),
 +					     "unable to hog wlan pwr GPIO\n");
 +
 +		gpiod_export(d, 0);
 +
 +		ret = devm_add_action_or_reset(&pdev->dev, gpio_twl4030_power_off_action, d);
 +		if (ret)
 +			return dev_err_probe(&pdev->dev, ret,
 +					     "failed to install power off handler\n");
  
 -		status = pdata->setup(&pdev->dev, priv->gpio_chip.base,
 -				      TWL4030_GPIO_MAX);
 -		if (status)
 -			dev_dbg(&pdev->dev, "setup --> %d\n", status);
  	}
  
- 	platform_set_drvdata(pdev, priv);
- out:
- 	return ret;
+ 	return 0;
  }
  
  static const struct of_device_id twl_gpio_match[] = {

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Arnd Bergmann]

On Tue, May 30, 2023, at 06:19, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the gpio-brgl tree got a conflict in:
>
>   drivers/gpio/gpio-twl4030.c
>
> between commit:
>
>   d5f4fa60d63a ("ARM/gpio: Push OMAP2 quirk down into TWL4030 driver")
>
> from the arm-soc tree and commit:
>
>   fbc8ab2ccd85 ("gpio: twl4030: Use devm_gpiochip_add_data() to 
> simplify remove path")
>
> from the gpio-brgl tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Maybe Bartosz wants to merge Linus' gpio-omap-descriptors-v6.5 series
into the gpio/for-next branch as well? It touches both the
arch/arm/mach-omap and a lot of the drivers using the gpios, so we
could treat this as a shared immutable branch.

    Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Arnd Bergmann]

On Tue, May 30, 2023, at 06:19, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the gpio-brgl tree got a conflict in:
>
>   drivers/gpio/gpio-twl4030.c
>
> between commit:
>
>   d5f4fa60d63a ("ARM/gpio: Push OMAP2 quirk down into TWL4030 driver")
>
> from the arm-soc tree and commit:
>
>   fbc8ab2ccd85 ("gpio: twl4030: Use devm_gpiochip_add_data() to 
> simplify remove path")
>
> from the gpio-brgl tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Maybe Bartosz wants to merge Linus' gpio-omap-descriptors-v6.5 series
into the gpio/for-next branch as well? It touches both the
arch/arm/mach-omap and a lot of the drivers using the gpios, so we
could treat this as a shared immutable branch.

    Arnd

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Bartosz Golaszewski]

On Tue, 30 May 2023 at 11:29, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, May 30, 2023, at 06:19, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the gpio-brgl tree got a conflict in:
> >
> >   drivers/gpio/gpio-twl4030.c
> >
> > between commit:
> >
> >   d5f4fa60d63a ("ARM/gpio: Push OMAP2 quirk down into TWL4030 driver")
> >
> > from the arm-soc tree and commit:
> >
> >   fbc8ab2ccd85 ("gpio: twl4030: Use devm_gpiochip_add_data() to
> > simplify remove path")
> >
> > from the gpio-brgl tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> Maybe Bartosz wants to merge Linus' gpio-omap-descriptors-v6.5 series
> into the gpio/for-next branch as well? It touches both the
> arch/arm/mach-omap and a lot of the drivers using the gpios, so we
> could treat this as a shared immutable branch.
>
>     Arnd

I was about to ask for an immutable tag. :)

Linus, is this the right tag to pull from your tree?

Bart

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Bartosz Golaszewski]

On Tue, 30 May 2023 at 11:29, Arnd Bergmann <arnd@arndb.de> wrote:
>
> On Tue, May 30, 2023, at 06:19, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the gpio-brgl tree got a conflict in:
> >
> >   drivers/gpio/gpio-twl4030.c
> >
> > between commit:
> >
> >   d5f4fa60d63a ("ARM/gpio: Push OMAP2 quirk down into TWL4030 driver")
> >
> > from the arm-soc tree and commit:
> >
> >   fbc8ab2ccd85 ("gpio: twl4030: Use devm_gpiochip_add_data() to
> > simplify remove path")
> >
> > from the gpio-brgl tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> > with the maintainer of the conflicting tree to minimise any particularly
> > complex conflicts.
>
> Maybe Bartosz wants to merge Linus' gpio-omap-descriptors-v6.5 series
> into the gpio/for-next branch as well? It touches both the
> arch/arm/mach-omap and a lot of the drivers using the gpios, so we
> could treat this as a shared immutable branch.
>
>     Arnd

I was about to ask for an immutable tag. :)

Linus, is this the right tag to pull from your tree?

Bart

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Linus Walleij]

On Tue, May 30, 2023 at 11:35 AM Bartosz Golaszewski
<bartosz.golaszewski@linaro.org> wrote:
> On Tue, 30 May 2023 at 11:29, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, May 30, 2023, at 06:19, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the gpio-brgl tree got a conflict in:
> > >
> > >   drivers/gpio/gpio-twl4030.c
> > >
> > > between commit:
> > >
> > >   d5f4fa60d63a ("ARM/gpio: Push OMAP2 quirk down into TWL4030 driver")
> > >
> > > from the arm-soc tree and commit:
> > >
> > >   fbc8ab2ccd85 ("gpio: twl4030: Use devm_gpiochip_add_data() to
> > > simplify remove path")
> > >
> > > from the gpio-brgl tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary. This
> > > is now fixed as far as linux-next is concerned, but any non trivial
> > > conflicts should be mentioned to your upstream maintainer when your tree
> > > is submitted for merging.  You may also want to consider cooperating
> > > with the maintainer of the conflicting tree to minimise any particularly
> > > complex conflicts.
> >
> > Maybe Bartosz wants to merge Linus' gpio-omap-descriptors-v6.5 series
> > into the gpio/for-next branch as well? It touches both the
> > arch/arm/mach-omap and a lot of the drivers using the gpios, so we
> > could treat this as a shared immutable branch.
> >
> >     Arnd
>
> I was about to ask for an immutable tag. :)
>
> Linus, is this the right tag to pull from your tree?

Yups go ahead, it's totally immutable!

Sorry for not thinking about it before.

Yours,
Linus Walleij

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Linus Walleij]

On Tue, May 30, 2023 at 11:35 AM Bartosz Golaszewski
<bartosz.golaszewski@linaro.org> wrote:
> On Tue, 30 May 2023 at 11:29, Arnd Bergmann <arnd@arndb.de> wrote:
> >
> > On Tue, May 30, 2023, at 06:19, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Today's linux-next merge of the gpio-brgl tree got a conflict in:
> > >
> > >   drivers/gpio/gpio-twl4030.c
> > >
> > > between commit:
> > >
> > >   d5f4fa60d63a ("ARM/gpio: Push OMAP2 quirk down into TWL4030 driver")
> > >
> > > from the arm-soc tree and commit:
> > >
> > >   fbc8ab2ccd85 ("gpio: twl4030: Use devm_gpiochip_add_data() to
> > > simplify remove path")
> > >
> > > from the gpio-brgl tree.
> > >
> > > I fixed it up (see below) and can carry the fix as necessary. This
> > > is now fixed as far as linux-next is concerned, but any non trivial
> > > conflicts should be mentioned to your upstream maintainer when your tree
> > > is submitted for merging.  You may also want to consider cooperating
> > > with the maintainer of the conflicting tree to minimise any particularly
> > > complex conflicts.
> >
> > Maybe Bartosz wants to merge Linus' gpio-omap-descriptors-v6.5 series
> > into the gpio/for-next branch as well? It touches both the
> > arch/arm/mach-omap and a lot of the drivers using the gpios, so we
> > could treat this as a shared immutable branch.
> >
> >     Arnd
>
> I was about to ask for an immutable tag. :)
>
> Linus, is this the right tag to pull from your tree?

Yups go ahead, it's totally immutable!

Sorry for not thinking about it before.

Yours,
Linus Walleij

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Hi all,

Today's linux-next merge of the gpio-brgl tree got a conflict in:

  arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts

between commit:

  4fd18fc38757 ("arm64: dts: visconti: Add watchdog support for TMPV7708 SoC")

from the arm-soc tree and commit:

  08bc3941b6a4 ("arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver")

from the gpio-brgl tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
index 37da418393e0,950010a290f0..000000000000
--- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
+++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
@@@ -42,7 -42,6 +42,11 @@@
  	clock-names = "apb_pclk";
  };
  
 +&wdt {
 +	status = "okay";
 +	clocks = <&wdt_clk>;
 +};
++
+ &gpio {
+ 	status = "okay";
+ };

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Stephen Rothwell]

[-- Attachment #1.1: Type: text/plain, Size: 1193 bytes --]

Hi all,

Today's linux-next merge of the gpio-brgl tree got a conflict in:

  arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts

between commit:

  4fd18fc38757 ("arm64: dts: visconti: Add watchdog support for TMPV7708 SoC")

from the arm-soc tree and commit:

  08bc3941b6a4 ("arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver")

from the gpio-brgl tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
index 37da418393e0,950010a290f0..000000000000
--- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
+++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
@@@ -42,7 -42,6 +42,11 @@@
  	clock-names = "apb_pclk";
  };
  
 +&wdt {
 +	status = "okay";
 +	clocks = <&wdt_clk>;
 +};
++
+ &gpio {
+ 	status = "okay";
+ };

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Geert Uytterhoeven]

On Thu, Jan 28, 2021 at 7:05 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the gpio-brgl tree got a conflict in:
>
>   arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
>
> between commit:
>
>   4fd18fc38757 ("arm64: dts: visconti: Add watchdog support for TMPV7708 SoC")
>
> from the arm-soc tree and commit:
>
>   08bc3941b6a4 ("arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver")
>
> from the gpio-brgl tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> index 37da418393e0,950010a290f0..000000000000
> --- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> +++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> @@@ -42,7 -42,6 +42,11 @@@
>         clock-names = "apb_pclk";
>   };
>
>  +&wdt {
>  +      status = "okay";
>  +      clocks = <&wdt_clk>;
>  +};
> ++
> + &gpio {
> +       status = "okay";
> + };

Probably some sort order should be taken into account (gpio before uart0),
also avoidng the conflict?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Geert Uytterhoeven]

On Thu, Jan 28, 2021 at 7:05 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Today's linux-next merge of the gpio-brgl tree got a conflict in:
>
>   arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
>
> between commit:
>
>   4fd18fc38757 ("arm64: dts: visconti: Add watchdog support for TMPV7708 SoC")
>
> from the arm-soc tree and commit:
>
>   08bc3941b6a4 ("arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver")
>
> from the gpio-brgl tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> index 37da418393e0,950010a290f0..000000000000
> --- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> +++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> @@@ -42,7 -42,6 +42,11 @@@
>         clock-names = "apb_pclk";
>   };
>
>  +&wdt {
>  +      status = "okay";
>  +      clocks = <&wdt_clk>;
>  +};
> ++
> + &gpio {
> +       status = "okay";
> + };

Probably some sort order should be taken into account (gpio before uart0),
also avoidng the conflict?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Arnd Bergmann]

On Tue, Feb 9, 2021 at 11:01 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Jan 28, 2021 at 7:05 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > index 37da418393e0,950010a290f0..000000000000
> > --- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > +++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > @@@ -42,7 -42,6 +42,11 @@@
> >         clock-names = "apb_pclk";
> >   };
> >
> >  +&wdt {
> >  +      status = "okay";
> >  +      clocks = <&wdt_clk>;
> >  +};
> > ++
> > + &gpio {
> > +       status = "okay";
> > + };
>
> Probably some sort order should be taken into account (gpio before uart0),
> also avoidng the conflict?
>

We normally do this by asking everyone to send the dts changes for
inclusion through the soc tree rather than the subsystem that contains
the driver. Why is this one in the gpio-brgl tree?

       Arnd

Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[Arnd Bergmann]

On Tue, Feb 9, 2021 at 11:01 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> On Thu, Jan 28, 2021 at 7:05 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > index 37da418393e0,950010a290f0..000000000000
> > --- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > +++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > @@@ -42,7 -42,6 +42,11 @@@
> >         clock-names = "apb_pclk";
> >   };
> >
> >  +&wdt {
> >  +      status = "okay";
> >  +      clocks = <&wdt_clk>;
> >  +};
> > ++
> > + &gpio {
> > +       status = "okay";
> > + };
>
> Probably some sort order should be taken into account (gpio before uart0),
> also avoidng the conflict?
>

We normally do this by asking everyone to send the dts changes for
inclusion through the soc tree rather than the subsystem that contains
the driver. Why is this one in the gpio-brgl tree?

       Arnd

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

RE: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[nobuhiro1.iwamatsu]

Hi all,

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@kernel.org]
> Sent: Tuesday, February 9, 2021 8:36 PM
> To: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>; Bartosz Golaszewski <brgl@bgdev.pl>; Olof Johansson <olof@lixom.net>;
> Arnd Bergmann <arnd@arndb.de>; ARM <linux-arm-kernel@lists.infradead.org>; Bartosz Golaszewski
> <bgolaszewski@baylibre.com>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Linux Next Mailing List
> <linux-next@vger.kernel.org>; iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <nobuhiro1.iwamatsu@toshiba.co.jp>
> Subject: Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree
> 
> On Tue, Feb 9, 2021 at 11:01 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Jan 28, 2021 at 7:05 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > > diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > index 37da418393e0,950010a290f0..000000000000
> > > --- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > +++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > @@@ -42,7 -42,6 +42,11 @@@
> > >         clock-names = "apb_pclk";
> > >   };
> > >
> > >  +&wdt {
> > >  +      status = "okay";
> > >  +      clocks = <&wdt_clk>;
> > >  +};
> > > ++
> > > + &gpio {
> > > +       status = "okay";
> > > + };
> >
> > Probably some sort order should be taken into account (gpio before uart0),
> > also avoidng the conflict?
> >
> 
> We normally do this by asking everyone to send the dts changes for
> inclusion through the soc tree rather than the subsystem that contains
> the driver. Why is this one in the gpio-brgl tree?

Perhaps this is Bartosz's mistake.
Linus has commented that gpio ml is captured via the soc tree.
  https://lore.kernel.org/linux-gpio/CACRpkdb--GSy-0vnAFS9Pik4TjrNRTrYeZr2RBZD6SFM8zotyQ@mail.gmail.com/

Bartosz, could you remove commit " arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver" from
your tree?

Best regards,
  Nobuhiro

RE: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree

[nobuhiro1.iwamatsu]

Hi all,

> -----Original Message-----
> From: Arnd Bergmann [mailto:arnd@kernel.org]
> Sent: Tuesday, February 9, 2021 8:36 PM
> To: Geert Uytterhoeven <geert@linux-m68k.org>
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>; Bartosz Golaszewski <brgl@bgdev.pl>; Olof Johansson <olof@lixom.net>;
> Arnd Bergmann <arnd@arndb.de>; ARM <linux-arm-kernel@lists.infradead.org>; Bartosz Golaszewski
> <bgolaszewski@baylibre.com>; Linux Kernel Mailing List <linux-kernel@vger.kernel.org>; Linux Next Mailing List
> <linux-next@vger.kernel.org>; iwamatsu nobuhiro(岩松 信洋 □ＳＷＣ◯ＡＣＴ) <nobuhiro1.iwamatsu@toshiba.co.jp>
> Subject: Re: linux-next: manual merge of the gpio-brgl tree with the arm-soc tree
> 
> On Tue, Feb 9, 2021 at 11:01 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> > On Thu, Jan 28, 2021 at 7:05 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> > > diff --cc arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > index 37da418393e0,950010a290f0..000000000000
> > > --- a/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > +++ b/arch/arm64/boot/dts/toshiba/tmpv7708-rm-mbrc.dts
> > > @@@ -42,7 -42,6 +42,11 @@@
> > >         clock-names = "apb_pclk";
> > >   };
> > >
> > >  +&wdt {
> > >  +      status = "okay";
> > >  +      clocks = <&wdt_clk>;
> > >  +};
> > > ++
> > > + &gpio {
> > > +       status = "okay";
> > > + };
> >
> > Probably some sort order should be taken into account (gpio before uart0),
> > also avoidng the conflict?
> >
> 
> We normally do this by asking everyone to send the dts changes for
> inclusion through the soc tree rather than the subsystem that contains
> the driver. Why is this one in the gpio-brgl tree?

Perhaps this is Bartosz's mistake.
Linus has commented that gpio ml is captured via the soc tree.
  https://lore.kernel.org/linux-gpio/CACRpkdb--GSy-0vnAFS9Pik4TjrNRTrYeZr2RBZD6SFM8zotyQ@mail.gmail.com/

Bartosz, could you remove commit " arm: dts: visconti: Add DT support for Toshiba Visconti5 GPIO driver" from
your tree?

Best regards,
  Nobuhiro
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel