AR7 is going to be removed from the Kernel, so remove its support for
MTD.

Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Florian Fainelli <f.fainelli@gmail.com>
---
Changes since v1:
* added ack

 arch/arm/configs/pxa_defconfig |   1 -
 drivers/mtd/parsers/Kconfig    |   5 --
 drivers/mtd/parsers/Makefile   |   1 -
 drivers/mtd/parsers/ar7part.c  | 129 ---------------------------------
 4 files changed, 136 deletions(-)
 delete mode 100644 drivers/mtd/parsers/ar7part.c

diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index 23c131b0854b..9e81b1849e4c 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -100,7 +100,6 @@ CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
 CONFIG_CONNECTOR=y
 CONFIG_MTD=y
-CONFIG_MTD_AR7_PARTS=m
 CONFIG_MTD_CMDLINE_PARTS=m
 CONFIG_MTD_OF_PARTS=m
 CONFIG_MTD_AFS_PARTS=m
diff --git a/drivers/mtd/parsers/Kconfig b/drivers/mtd/parsers/Kconfig
index 60738edcd5d5..da03ab6efe04 100644
--- a/drivers/mtd/parsers/Kconfig
+++ b/drivers/mtd/parsers/Kconfig
@@ -1,9 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
-config MTD_AR7_PARTS
-	tristate "TI AR7 partitioning parser"
-	help
-	  TI AR7 partitioning parser support
-
 config MTD_BCM47XX_PARTS
 	tristate "BCM47XX partitioning parser"
 	depends on BCM47XX || ARCH_BCM_5301X
diff --git a/drivers/mtd/parsers/Makefile b/drivers/mtd/parsers/Makefile
index 0e70b621a1d8..9b00c62b837a 100644
--- a/drivers/mtd/parsers/Makefile
+++ b/drivers/mtd/parsers/Makefile
@@ -1,5 +1,4 @@
 # SPDX-License-Identifier: GPL-2.0-only
-obj-$(CONFIG_MTD_AR7_PARTS)		+= ar7part.o
 obj-$(CONFIG_MTD_BCM47XX_PARTS)		+= bcm47xxpart.o
 obj-$(CONFIG_MTD_BCM63XX_PARTS)		+= bcm63xxpart.o
 obj-$(CONFIG_MTD_BRCM_U_BOOT)		+= brcm_u-boot.o
diff --git a/drivers/mtd/parsers/ar7part.c b/drivers/mtd/parsers/ar7part.c
deleted file mode 100644
index 8cd683711ac6..000000000000
-- 
2.35.1

Hi Wolfram,

wsa+renesas@sang-engineering.com wrote on Fri, 22 Sep 2023 08:15:23
+0200:

> AR7 is going to be removed from the Kernel, so remove its support for
> MTD.
> 
> Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
> Acked-by: Florian Fainelli <f.fainelli@gmail.com>
> ---
> Changes since v1:
> * added ack
> 
>  arch/arm/configs/pxa_defconfig |   1 -

I'm not sure it is wise to merge defconfig changes through mtd. Would
you mind sending this change aside to avoid potential conflicts? Each
patch can live on their own anyway.

>  drivers/mtd/parsers/Kconfig    |   5 --
>  drivers/mtd/parsers/Makefile   |   1 -
>  drivers/mtd/parsers/ar7part.c  | 129 ---------------------------------

Do you have other changes related to this file in your tree? It failed
to apply on my side.

>  4 files changed, 136 deletions(-)
>  delete mode 100644 drivers/mtd/parsers/ar7part.c

Thanks,
Miquèl

> I'm not sure it is wise to merge defconfig changes through mtd. Would
> you mind sending this change aside to avoid potential conflicts? Each
> patch can live on their own anyway.

I checked pxa_defconfig history. Most commits in the last 7 years were
just removing outdated Kconfig symbols from all kind of subsystems. Like
what we want to do here. I think it is okay to keep it.

Hi Wolfram,

wsa+renesas@sang-engineering.com wrote on Thu, 28 Sep 2023 09:10:24
+0200:

> > I'm not sure it is wise to merge defconfig changes through mtd. Would
> > you mind sending this change aside to avoid potential conflicts? Each
> > patch can live on their own anyway.  
> 
> I checked pxa_defconfig history. Most commits in the last 7 years were
> just removing outdated Kconfig symbols from all kind of subsystems. Like
> what we want to do here. I think it is okay to keep it.
> 

Ok, I've acked the patch anyway, so now I expect it to be taken through
the mips tree as suggested earlier. Let me know if it's happening
differently.

Thanks,
Miquèl

> I'm not sure it is wise to merge defconfig changes through mtd. Would
> you mind sending this change aside to avoid potential conflicts? Each
> patch can live on their own anyway.

Yup, I can send a seperate patch for it.

> >  drivers/mtd/parsers/Kconfig    |   5 --
> >  drivers/mtd/parsers/Makefile   |   1 -
> >  drivers/mtd/parsers/ar7part.c  | 129 ---------------------------------
> 
> Do you have other changes related to this file in your tree? It failed
> to apply on my side.

No change. Plain v6.6-rc2. I used "--irreversible-delete", though. Maybe
this is causing issues? As I stated in the cover-letter, I wonder if all
this should go via MIPS. But there hasn't been any discussion about it
yet.

On 22/9/23 19:55, Wolfram Sang wrote:
> 
>> I'm not sure it is wise to merge defconfig changes through mtd. Would
>> you mind sending this change aside to avoid potential conflicts? Each
>> patch can live on their own anyway.
> 
> Yup, I can send a seperate patch for it.
> 
>>>   drivers/mtd/parsers/Kconfig    |   5 --
>>>   drivers/mtd/parsers/Makefile   |   1 -
>>>   drivers/mtd/parsers/ar7part.c  | 129 ---------------------------------
>>
>> Do you have other changes related to this file in your tree? It failed
>> to apply on my side.
> 
> No change. Plain v6.6-rc2. I used "--irreversible-delete", though. Maybe
> this is causing issues? As I stated in the cover-letter, I wonder if all
> this should go via MIPS. But there hasn't been any discussion about it
> yet.

MIPS tree for the whole series certainly makes sense.

Hi,

philmd@linaro.org wrote on Fri, 22 Sep 2023 20:35:16 +0200:

> On 22/9/23 19:55, Wolfram Sang wrote:
> >   
> >> I'm not sure it is wise to merge defconfig changes through mtd. Would
> >> you mind sending this change aside to avoid potential conflicts? Each
> >> patch can live on their own anyway.  
> > 
> > Yup, I can send a seperate patch for it.
> >   
> >>>   drivers/mtd/parsers/Kconfig    |   5 --
> >>>   drivers/mtd/parsers/Makefile   |   1 -
> >>>   drivers/mtd/parsers/ar7part.c  | 129 ---------------------------------  
> >>
> >> Do you have other changes related to this file in your tree? It failed
> >> to apply on my side.  
> > 
> > No change. Plain v6.6-rc2. I used "--irreversible-delete", though. Maybe
> > this is causing issues? As I stated in the cover-letter, I wonder if all
> > this should go via MIPS. But there hasn't been any discussion about it
> > yet.  
> 
> MIPS tree for the whole series certainly makes sense.

Then:

Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>

Thanks,
Miquèl