[PATCH 0/2] Remove QDF2xxx pinctrl drivers

[PATCH 0/2] Remove QDF2xxx pinctrl drivers

[Konrad Dybcio]

The SoC line was never productized, remove the maintenance burden.

Compile-tested only.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
Konrad Dybcio (2):
      pinctrl: qcom: Remove QDF2xxx support
      arm64: defconfig: Remove QDF24XX pinctrl

 arch/arm64/configs/defconfig           |   1 -
 drivers/pinctrl/qcom/Kconfig.msm       |   7 --
 drivers/pinctrl/qcom/Makefile          |   1 -
 drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 164 ---------------------------------
 4 files changed, 173 deletions(-)
---
base-commit: 319fbd8fc6d339e0a1c7b067eed870c518a13a02
change-id: 20240122-topic-qdf_cleanup_pinctrl-98e17cdb375b

Best regards,
-- 
Konrad Dybcio <konrad.dybcio@linaro.org>

[PATCH 1/2] pinctrl: qcom: Remove QDF2xxx support

[Konrad Dybcio]

This SoC family was destined for server use, featuring Qualcomm's very
interesting Kryo cores (before "Kryo" became a marketing term for Arm
cores with small modifications). It did however not leave the labs of
Qualcomm and presumably some partners, nor was it ever productized.

Remove this driver, as it seems to be long obsolete.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
 drivers/pinctrl/qcom/Kconfig.msm       |   7 --
 drivers/pinctrl/qcom/Makefile          |   1 -
 drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 164 ---------------------------------
 3 files changed, 172 deletions(-)

diff --git a/drivers/pinctrl/qcom/Kconfig.msm b/drivers/pinctrl/qcom/Kconfig.msm
index 8fe459d082ed..57778590006f 100644
--- a/drivers/pinctrl/qcom/Kconfig.msm
+++ b/drivers/pinctrl/qcom/Kconfig.msm
@@ -182,13 +182,6 @@ config PINCTRL_QCS404
 	  This is the pinctrl, pinmux, pinconf and gpiolib driver for the
 	  TLMM block found in the Qualcomm QCS404 platform.
 
-config PINCTRL_QDF2XXX
-	tristate "Qualcomm Technologies QDF2xxx pin controller driver"
-	depends on ACPI
-	help
-	  This is the GPIO driver for the TLMM block found on the
-	  Qualcomm Technologies QDF2xxx SOCs.
-
 config PINCTRL_QDU1000
 	tristate "Qualcomm Technologies Inc QDU1000/QRU1000 pin controller driver"
 	depends on ARM64 || COMPILE_TEST
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index e2e76071d268..fa58af95a09d 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -23,7 +23,6 @@ obj-$(CONFIG_PINCTRL_MSM8996)   += pinctrl-msm8996.o
 obj-$(CONFIG_PINCTRL_MSM8998)   += pinctrl-msm8998.o
 obj-$(CONFIG_PINCTRL_QCM2290)	+= pinctrl-qcm2290.o
 obj-$(CONFIG_PINCTRL_QCS404)	+= pinctrl-qcs404.o
-obj-$(CONFIG_PINCTRL_QDF2XXX)	+= pinctrl-qdf2xxx.o
 obj-$(CONFIG_PINCTRL_MDM9607)	+= pinctrl-mdm9607.o
 obj-$(CONFIG_PINCTRL_MDM9615)	+= pinctrl-mdm9615.o
 obj-$(CONFIG_PINCTRL_QCOM_SPMI_PMIC) += pinctrl-spmi-gpio.o
diff --git a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c b/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
deleted file mode 100644
index 4d2f6f495163..000000000000
--- a/drivers/pinctrl/qcom/pinctrl-qdf2xxx.c
+++ /dev/null
@@ -1,164 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0-only
-/*
- * Copyright (c) 2015, The Linux Foundation. All rights reserved.
- *
- * GPIO and pin control functions on this SOC are handled by the "TLMM"
- * device.  The driver which controls this device is pinctrl-msm.c.  Each
- * SOC with a TLMM is expected to create a client driver that registers
- * with pinctrl-msm.c.  This means that all TLMM drivers are pin control
- * drivers.
- *
- * This pin control driver is intended to be used only an ACPI-enabled
- * system.  As such, UEFI will handle all pin control configuration, so
- * this driver does not provide pin control functions.  It is effectively
- * a GPIO-only driver.  The alternative is to duplicate the GPIO code of
- * pinctrl-msm.c into another driver.
- */
-
-#include <linux/module.h>
-#include <linux/platform_device.h>
-#include <linux/pinctrl/pinctrl.h>
-#include <linux/acpi.h>
-
-#include "pinctrl-msm.h"
-
-/* A maximum of 256 allows us to use a u8 array to hold the GPIO numbers */
-#define MAX_GPIOS	256
-
-/* maximum size of each gpio name (enough room for "gpioXXX" + null) */
-#define NAME_SIZE	8
-
-static int qdf2xxx_pinctrl_probe(struct platform_device *pdev)
-{
-	struct msm_pinctrl_soc_data *pinctrl;
-	struct pinctrl_pin_desc *pins;
-	struct msm_pingroup *groups;
-	char (*names)[NAME_SIZE];
-	unsigned int i;
-	u32 num_gpios;
-	unsigned int avail_gpios; /* The number of GPIOs we support */
-	u8 gpios[MAX_GPIOS];      /* An array of supported GPIOs */
-	int ret;
-
-	/* Query the number of GPIOs from ACPI */
-	ret = device_property_read_u32(&pdev->dev, "num-gpios", &num_gpios);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "missing 'num-gpios' property\n");
-		return ret;
-	}
-	if (!num_gpios || num_gpios > MAX_GPIOS) {
-		dev_err(&pdev->dev, "invalid 'num-gpios' property\n");
-		return -ENODEV;
-	}
-
-	/* The number of GPIOs in the approved list */
-	ret = device_property_count_u8(&pdev->dev, "gpios");
-	if (ret < 0) {
-		dev_err(&pdev->dev, "missing 'gpios' property\n");
-		return ret;
-	}
-	/*
-	 * The number of available GPIOs should be non-zero, and no
-	 * more than the total number of GPIOS.
-	 */
-	if (!ret || ret > num_gpios) {
-		dev_err(&pdev->dev, "invalid 'gpios' property\n");
-		return -ENODEV;
-	}
-	avail_gpios = ret;
-
-	ret = device_property_read_u8_array(&pdev->dev, "gpios", gpios,
-					    avail_gpios);
-	if (ret < 0) {
-		dev_err(&pdev->dev, "could not read list of GPIOs\n");
-		return ret;
-	}
-
-	pinctrl = devm_kzalloc(&pdev->dev, sizeof(*pinctrl), GFP_KERNEL);
-	pins = devm_kcalloc(&pdev->dev, num_gpios,
-		sizeof(struct pinctrl_pin_desc), GFP_KERNEL);
-	groups = devm_kcalloc(&pdev->dev, num_gpios,
-		sizeof(struct msm_pingroup), GFP_KERNEL);
-	names = devm_kcalloc(&pdev->dev, avail_gpios, NAME_SIZE, GFP_KERNEL);
-
-	if (!pinctrl || !pins || !groups || !names)
-		return -ENOMEM;
-
-	/*
-	 * Initialize the array.  GPIOs not listed in the 'gpios' array
-	 * still need a number, but nothing else.
-	 */
-	for (i = 0; i < num_gpios; i++) {
-		pins[i].number = i;
-		groups[i].grp.pins = &pins[i].number;
-	}
-
-	/* Populate the entries that are meant to be exposed as GPIOs. */
-	for (i = 0; i < avail_gpios; i++) {
-		unsigned int gpio = gpios[i];
-
-		groups[gpio].grp.npins = 1;
-		snprintf(names[i], NAME_SIZE, "gpio%u", gpio);
-		pins[gpio].name = names[i];
-		groups[gpio].grp.name = names[i];
-
-		groups[gpio].ctl_reg = 0x10000 * gpio;
-		groups[gpio].io_reg = 0x04 + 0x10000 * gpio;
-		groups[gpio].intr_cfg_reg = 0x08 + 0x10000 * gpio;
-		groups[gpio].intr_status_reg = 0x0c + 0x10000 * gpio;
-		groups[gpio].intr_target_reg = 0x08 + 0x10000 * gpio;
-
-		groups[gpio].mux_bit = 2;
-		groups[gpio].pull_bit = 0;
-		groups[gpio].drv_bit = 6;
-		groups[gpio].oe_bit = 9;
-		groups[gpio].in_bit = 0;
-		groups[gpio].out_bit = 1;
-		groups[gpio].intr_enable_bit = 0;
-		groups[gpio].intr_status_bit = 0;
-		groups[gpio].intr_target_bit = 5;
-		groups[gpio].intr_target_kpss_val = 1;
-		groups[gpio].intr_raw_status_bit = 4;
-		groups[gpio].intr_polarity_bit = 1;
-		groups[gpio].intr_detection_bit = 2;
-		groups[gpio].intr_detection_width = 2;
-	}
-
-	pinctrl->pins = pins;
-	pinctrl->groups = groups;
-	pinctrl->npins = num_gpios;
-	pinctrl->ngroups = num_gpios;
-	pinctrl->ngpios = num_gpios;
-
-	return msm_pinctrl_probe(pdev, pinctrl);
-}
-
-static const struct acpi_device_id qdf2xxx_acpi_ids[] = {
-	{"QCOM8002"},
-	{},
-};
-MODULE_DEVICE_TABLE(acpi, qdf2xxx_acpi_ids);
-
-static struct platform_driver qdf2xxx_pinctrl_driver = {
-	.driver = {
-		.name = "qdf2xxx-pinctrl",
-		.acpi_match_table = qdf2xxx_acpi_ids,
-	},
-	.probe = qdf2xxx_pinctrl_probe,
-	.remove_new = msm_pinctrl_remove,
-};
-
-static int __init qdf2xxx_pinctrl_init(void)
-{
-	return platform_driver_register(&qdf2xxx_pinctrl_driver);
-}
-arch_initcall(qdf2xxx_pinctrl_init);
-
-static void __exit qdf2xxx_pinctrl_exit(void)
-{
-	platform_driver_unregister(&qdf2xxx_pinctrl_driver);
-}
-module_exit(qdf2xxx_pinctrl_exit);
-
-MODULE_DESCRIPTION("Qualcomm Technologies QDF2xxx pin control driver");
-MODULE_LICENSE("GPL v2");

-- 
2.43.0

Re: [PATCH 1/2] pinctrl: qcom: Remove QDF2xxx support

[Bjorn Andersson]

On Mon, Jan 22, 2024 at 12:57:12PM +0100, Konrad Dybcio wrote:
> This SoC family was destined for server use, featuring Qualcomm's very
> interesting Kryo cores (before "Kryo" became a marketing term for Arm
> cores with small modifications). It did however not leave the labs of
> Qualcomm and presumably some partners, nor was it ever productized.
> 
> Remove this driver, as it seems to be long obsolete.
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>

Reviewed-by: Bjorn Andersson <andersson@kernel.org>

Regards,
Bjorn

[PATCH 2/2] arm64: defconfig: Remove QDF24XX pinctrl

[Konrad Dybcio]

The driver for is has been removed, clean up the config entry.

Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
---
 arch/arm64/configs/defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index e6cf3e5d63c3..55b8dab100bd 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -588,7 +588,6 @@ CONFIG_PINCTRL_MSM8996=y
 CONFIG_PINCTRL_MSM8998=y
 CONFIG_PINCTRL_QCM2290=y
 CONFIG_PINCTRL_QCS404=y
-CONFIG_PINCTRL_QDF2XXX=y
 CONFIG_PINCTRL_QDU1000=y
 CONFIG_PINCTRL_SA8775P=y
 CONFIG_PINCTRL_SC7180=y

-- 
2.43.0

Re: [PATCH 0/2] Remove QDF2xxx pinctrl drivers

[Jeffrey Hugo]

On 1/22/2024 4:57 AM, Konrad Dybcio wrote:
> The SoC line was never productized, remove the maintenance burden.
> 
> Compile-tested only.
> 
> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> ---
> Konrad Dybcio (2):
>        pinctrl: qcom: Remove QDF2xxx support
>        arm64: defconfig: Remove QDF24XX pinctrl
> 
>   arch/arm64/configs/defconfig           |   1 -
>   drivers/pinctrl/qcom/Kconfig.msm       |   7 --
>   drivers/pinctrl/qcom/Makefile          |   1 -
>   drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 164 ---------------------------------
>   4 files changed, 173 deletions(-)
> ---
> base-commit: 319fbd8fc6d339e0a1c7b067eed870c518a13a02
> change-id: 20240122-topic-qdf_cleanup_pinctrl-98e17cdb375b
> 
> Best regards,

NACK.

This was productized, there are some out in the wild, and the platform 
is still in (limited) use.

I'd like to see support hang around for a few more years yet.

Re: [PATCH 0/2] Remove QDF2xxx pinctrl drivers

[Dmitry Baryshkov]

On Mon, 22 Jan 2024 at 19:43, Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
>
> On 1/22/2024 4:57 AM, Konrad Dybcio wrote:
> > The SoC line was never productized, remove the maintenance burden.
> >
> > Compile-tested only.
> >
> > Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> > ---
> > Konrad Dybcio (2):
> >        pinctrl: qcom: Remove QDF2xxx support
> >        arm64: defconfig: Remove QDF24XX pinctrl
> >
> >   arch/arm64/configs/defconfig           |   1 -
> >   drivers/pinctrl/qcom/Kconfig.msm       |   7 --
> >   drivers/pinctrl/qcom/Makefile          |   1 -
> >   drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 164 ---------------------------------
> >   4 files changed, 173 deletions(-)
> > ---
> > base-commit: 319fbd8fc6d339e0a1c7b067eed870c518a13a02
> > change-id: 20240122-topic-qdf_cleanup_pinctrl-98e17cdb375b
> >
> > Best regards,
>
> NACK.
>
> This was productized, there are some out in the wild, and the platform
> is still in (limited) use.
>
> I'd like to see support hang around for a few more years yet.

The problem is that... its support is pretty strange. I can see
pinctrl, ethernet and quirks for the platform in GIC-ITS and PL011
drivers. Is this enough to get the platform into the useful state? I
can imagine that "QCOM2430" ACPI handle was used for USB hosts on that
platform, but I don't remember when we last tested DWC3 with the ACPI.

So, all this boils down to the question whether mainline (or something
close by, LTS for example) is actually used and tested on these
devices?

-- 
With best wishes
Dmitry

Re: [PATCH 0/2] Remove QDF2xxx pinctrl drivers

[Jeffrey Hugo]

On 1/22/2024 10:56 AM, Dmitry Baryshkov wrote:
> On Mon, 22 Jan 2024 at 19:43, Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
>>
>> On 1/22/2024 4:57 AM, Konrad Dybcio wrote:
>>> The SoC line was never productized, remove the maintenance burden.
>>>
>>> Compile-tested only.
>>>
>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>> ---
>>> Konrad Dybcio (2):
>>>         pinctrl: qcom: Remove QDF2xxx support
>>>         arm64: defconfig: Remove QDF24XX pinctrl
>>>
>>>    arch/arm64/configs/defconfig           |   1 -
>>>    drivers/pinctrl/qcom/Kconfig.msm       |   7 --
>>>    drivers/pinctrl/qcom/Makefile          |   1 -
>>>    drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 164 ---------------------------------
>>>    4 files changed, 173 deletions(-)
>>> ---
>>> base-commit: 319fbd8fc6d339e0a1c7b067eed870c518a13a02
>>> change-id: 20240122-topic-qdf_cleanup_pinctrl-98e17cdb375b
>>>
>>> Best regards,
>>
>> NACK.
>>
>> This was productized, there are some out in the wild, and the platform
>> is still in (limited) use.
>>
>> I'd like to see support hang around for a few more years yet.
> 
> The problem is that... its support is pretty strange. I can see
> pinctrl, ethernet and quirks for the platform in GIC-ITS and PL011
> drivers. Is this enough to get the platform into the useful state? I
> can imagine that "QCOM2430" ACPI handle was used for USB hosts on that
> platform, but I don't remember when we last tested DWC3 with the ACPI.
> 
> So, all this boils down to the question whether mainline (or something
> close by, LTS for example) is actually used and tested on these
> devices?

Its an ACPI system, so you won't see all of the fun DTisms of a MSM chip.

The platform was fully functional upstream, and had an Ubuntu 
certification.  I run Ubuntu on the two that I have in my office.  I 
haven't strictly checked out mainline in a while, but I could.  I still 
have access to the documentation.

There is a small, but active set of users including myself.  From what 
I've seen, they've been happy with things.

-Jeff

Re: [PATCH 0/2] Remove QDF2xxx pinctrl drivers

[Dmitry Baryshkov]

On Mon, 22 Jan 2024 at 20:44, Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
>
> On 1/22/2024 10:56 AM, Dmitry Baryshkov wrote:
> > On Mon, 22 Jan 2024 at 19:43, Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
> >>
> >> On 1/22/2024 4:57 AM, Konrad Dybcio wrote:
> >>> The SoC line was never productized, remove the maintenance burden.
> >>>
> >>> Compile-tested only.
> >>>
> >>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
> >>> ---
> >>> Konrad Dybcio (2):
> >>>         pinctrl: qcom: Remove QDF2xxx support
> >>>         arm64: defconfig: Remove QDF24XX pinctrl
> >>>
> >>>    arch/arm64/configs/defconfig           |   1 -
> >>>    drivers/pinctrl/qcom/Kconfig.msm       |   7 --
> >>>    drivers/pinctrl/qcom/Makefile          |   1 -
> >>>    drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 164 ---------------------------------
> >>>    4 files changed, 173 deletions(-)
> >>> ---
> >>> base-commit: 319fbd8fc6d339e0a1c7b067eed870c518a13a02
> >>> change-id: 20240122-topic-qdf_cleanup_pinctrl-98e17cdb375b
> >>>
> >>> Best regards,
> >>
> >> NACK.
> >>
> >> This was productized, there are some out in the wild, and the platform
> >> is still in (limited) use.
> >>
> >> I'd like to see support hang around for a few more years yet.
> >
> > The problem is that... its support is pretty strange. I can see
> > pinctrl, ethernet and quirks for the platform in GIC-ITS and PL011
> > drivers. Is this enough to get the platform into the useful state? I
> > can imagine that "QCOM2430" ACPI handle was used for USB hosts on that
> > platform, but I don't remember when we last tested DWC3 with the ACPI.
> >
> > So, all this boils down to the question whether mainline (or something
> > close by, LTS for example) is actually used and tested on these
> > devices?
>
> Its an ACPI system, so you won't see all of the fun DTisms of a MSM chip.
>
> The platform was fully functional upstream, and had an Ubuntu
> certification.  I run Ubuntu on the two that I have in my office.  I
> haven't strictly checked out mainline in a while, but I could.  I still
> have access to the documentation.
>
> There is a small, but active set of users including myself.  From what
> I've seen, they've been happy with things.

Thanks for the information! It looks like it has a small but stable
user base. I think we should keep it, maybe ensuring that we are able
to test the kernel.

-- 
With best wishes
Dmitry

Re: [PATCH 0/2] Remove QDF2xxx pinctrl drivers

[Konrad Dybcio]

On 1/22/24 20:23, Dmitry Baryshkov wrote:
> On Mon, 22 Jan 2024 at 20:44, Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
>>
>> On 1/22/2024 10:56 AM, Dmitry Baryshkov wrote:
>>> On Mon, 22 Jan 2024 at 19:43, Jeffrey Hugo <quic_jhugo@quicinc.com> wrote:
>>>>
>>>> On 1/22/2024 4:57 AM, Konrad Dybcio wrote:
>>>>> The SoC line was never productized, remove the maintenance burden.
>>>>>
>>>>> Compile-tested only.
>>>>>
>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
>>>>> ---
>>>>> Konrad Dybcio (2):
>>>>>          pinctrl: qcom: Remove QDF2xxx support
>>>>>          arm64: defconfig: Remove QDF24XX pinctrl
>>>>>
>>>>>     arch/arm64/configs/defconfig           |   1 -
>>>>>     drivers/pinctrl/qcom/Kconfig.msm       |   7 --
>>>>>     drivers/pinctrl/qcom/Makefile          |   1 -
>>>>>     drivers/pinctrl/qcom/pinctrl-qdf2xxx.c | 164 ---------------------------------
>>>>>     4 files changed, 173 deletions(-)
>>>>> ---
>>>>> base-commit: 319fbd8fc6d339e0a1c7b067eed870c518a13a02
>>>>> change-id: 20240122-topic-qdf_cleanup_pinctrl-98e17cdb375b
>>>>>
>>>>> Best regards,
>>>>
>>>> NACK.
>>>>
>>>> This was productized, there are some out in the wild, and the platform
>>>> is still in (limited) use.
>>>>
>>>> I'd like to see support hang around for a few more years yet.
>>>
>>> The problem is that... its support is pretty strange. I can see
>>> pinctrl, ethernet and quirks for the platform in GIC-ITS and PL011
>>> drivers. Is this enough to get the platform into the useful state? I
>>> can imagine that "QCOM2430" ACPI handle was used for USB hosts on that
>>> platform, but I don't remember when we last tested DWC3 with the ACPI.
>>>
>>> So, all this boils down to the question whether mainline (or something
>>> close by, LTS for example) is actually used and tested on these
>>> devices?
>>
>> Its an ACPI system, so you won't see all of the fun DTisms of a MSM chip.
>>
>> The platform was fully functional upstream, and had an Ubuntu
>> certification.  I run Ubuntu on the two that I have in my office.  I
>> haven't strictly checked out mainline in a while, but I could.  I still
>> have access to the documentation.
>>
>> There is a small, but active set of users including myself.  From what
>> I've seen, they've been happy with things.
> 
> Thanks for the information! It looks like it has a small but stable
> user base. I think we should keep it, maybe ensuring that we are able
> to test the kernel.

Alright, please make sure it still boots etc. then!

Konrad