2024-01-22 11:57:31

by Konrad Dybcio

[permalink] [raw]
Subject: [PATCH 0/2] Remove QDF2xxx pinctrl drivers

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

Compile-tested only.

Signed-off-by: Konrad Dybcio <[email protected]>
---
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 <[email protected]>



2024-01-22 11:57:52

by Konrad Dybcio

[permalink] [raw]
Subject: [PATCH 2/2] arm64: defconfig: Remove QDF24XX pinctrl

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

Signed-off-by: Konrad Dybcio <[email protected]>
---
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


2024-01-22 11:57:55

by Konrad Dybcio

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

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 <[email protected]>
---
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


2024-01-22 17:37:36

by Bjorn Andersson

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

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 <[email protected]>

Reviewed-by: Bjorn Andersson <[email protected]>

Regards,
Bjorn

2024-01-22 17:49:13

by Jeffrey Hugo

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

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 <[email protected]>
> ---
> 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.

2024-01-22 18:30:38

by Dmitry Baryshkov

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

On Mon, 22 Jan 2024 at 19:43, Jeffrey Hugo <[email protected]> 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 <[email protected]>
> > ---
> > 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

2024-01-22 19:11:59

by Jeffrey Hugo

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

On 1/22/2024 10:56 AM, Dmitry Baryshkov wrote:
> On Mon, 22 Jan 2024 at 19:43, Jeffrey Hugo <[email protected]> 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 <[email protected]>
>>> ---
>>> 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

2024-01-22 19:38:44

by Dmitry Baryshkov

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

On Mon, 22 Jan 2024 at 20:44, Jeffrey Hugo <[email protected]> wrote:
>
> On 1/22/2024 10:56 AM, Dmitry Baryshkov wrote:
> > On Mon, 22 Jan 2024 at 19:43, Jeffrey Hugo <[email protected]> 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 <[email protected]>
> >>> ---
> >>> 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

2024-01-23 18:01:14

by Konrad Dybcio

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



On 1/22/24 20:23, Dmitry Baryshkov wrote:
> On Mon, 22 Jan 2024 at 20:44, Jeffrey Hugo <[email protected]> wrote:
>>
>> On 1/22/2024 10:56 AM, Dmitry Baryshkov wrote:
>>> On Mon, 22 Jan 2024 at 19:43, Jeffrey Hugo <[email protected]> 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 <[email protected]>
>>>>> ---
>>>>> 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