From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Use the existing infrastructure for storing and looking up pin functions
in pinctrl core. Remove hand-crafted callbacks.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
---
drivers/pinctrl/qcom/pinctrl-msm.c | 43 ++++++++++++--------------------------
1 file changed, 13 insertions(+), 30 deletions(-)
diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c b/drivers/pinctrl/qcom/pinctrl-msm.c
index f713c80d7f3eda06de027cd539e8decd4412876a..965f0cceac56697bc4cdb851c8201db7508c042e 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -31,6 +31,7 @@
#include "../core.h"
#include "../pinconf.h"
#include "../pinctrl-utils.h"
+#include "../pinmux.h"
#include "pinctrl-msm.h"
@@ -150,33 +151,6 @@ static int msm_pinmux_request(struct pinctrl_dev *pctldev, unsigned offset)
return gpiochip_line_is_valid(chip, offset) ? 0 : -EINVAL;
}
-static int msm_get_functions_count(struct pinctrl_dev *pctldev)
-{
- struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
-
- return pctrl->soc->nfunctions;
-}
-
-static const char *msm_get_function_name(struct pinctrl_dev *pctldev,
- unsigned function)
-{
- struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
-
- return pctrl->soc->functions[function].name;
-}
-
-static int msm_get_function_groups(struct pinctrl_dev *pctldev,
- unsigned function,
- const char * const **groups,
- unsigned * const num_groups)
-{
- struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
-
- *groups = pctrl->soc->functions[function].groups;
- *num_groups = pctrl->soc->functions[function].ngroups;
- return 0;
-}
-
static int msm_pinmux_set_mux(struct pinctrl_dev *pctldev,
unsigned function,
unsigned group)
@@ -288,9 +262,9 @@ static int msm_pinmux_request_gpio(struct pinctrl_dev *pctldev,
static const struct pinmux_ops msm_pinmux_ops = {
.request = msm_pinmux_request,
- .get_functions_count = msm_get_functions_count,
- .get_function_name = msm_get_function_name,
- .get_function_groups = msm_get_function_groups,
+ .get_functions_count = pinmux_generic_get_function_count,
+ .get_function_name = pinmux_generic_get_function_name,
+ .get_function_groups = pinmux_generic_get_function_groups,
.gpio_request_enable = msm_pinmux_request_gpio,
.set_mux = msm_pinmux_set_mux,
};
@@ -1552,6 +1526,7 @@ EXPORT_SYMBOL(msm_pinctrl_dev_pm_ops);
int msm_pinctrl_probe(struct platform_device *pdev,
const struct msm_pinctrl_soc_data *soc_data)
{
+ const struct pinfunction *func;
struct msm_pinctrl *pctrl;
struct resource *res;
int ret;
@@ -1606,6 +1581,14 @@ int msm_pinctrl_probe(struct platform_device *pdev,
return PTR_ERR(pctrl->pctrl);
}
+ for (i = 0; i < soc_data->nfunctions; i++) {
+ func = &soc_data->functions[i];
+
+ ret = pinmux_generic_add_pinfunction(pctrl->pctrl, func, NULL);
+ if (ret < 0)
+ return ret;
+ }
+
ret = msm_gpio_init(pctrl);
if (ret)
return ret;
--
2.48.1
On Wed, Jul 9, 2025 at 4:39 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Use the existing infrastructure for storing and looking up pin functions > in pinctrl core. Remove hand-crafted callbacks. > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> Needless to say I'm a big fan of this patch set and it seems only this patch 8/12 has outstanding comments. Do you think you can do a quick iteration of it or does it require a lot of time? I am tempted to simply apply patches 1-7 to make your life easier past v6.17, should I do this? Yours, Linus Walleij
On Fri, Jul 11, 2025 at 8:37 PM Linus Walleij <linus.walleij@linaro.org> wrote: > > On Wed, Jul 9, 2025 at 4:39 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > Use the existing infrastructure for storing and looking up pin functions > > in pinctrl core. Remove hand-crafted callbacks. > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Needless to say I'm a big fan of this patch set and it seems only > this patch 8/12 has outstanding comments. > > Do you think you can do a quick iteration of it or does it require > a lot of time? > I don't want to rush it. Let's make it v6.18 material as I want the changes to spend some more time in next and not break anything. It affects literally all qualcomm platforms after all. > I am tempted to simply apply patches 1-7 to make your life > easier past v6.17, should I do this? > Yes, please, they carry no functional change, it will be less baggage for the future. Bart
On 7/9/25 4:39 PM, Bartosz Golaszewski wrote: > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > Use the existing infrastructure for storing and looking up pin functions > in pinctrl core. Remove hand-crafted callbacks. > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > --- [...] > int msm_pinctrl_probe(struct platform_device *pdev, > const struct msm_pinctrl_soc_data *soc_data) > { > + const struct pinfunction *func; > struct msm_pinctrl *pctrl; > struct resource *res; > int ret; > @@ -1606,6 +1581,14 @@ int msm_pinctrl_probe(struct platform_device *pdev, > return PTR_ERR(pctrl->pctrl); > } > > + for (i = 0; i < soc_data->nfunctions; i++) { > + func = &soc_data->functions[i]; > + > + ret = pinmux_generic_add_pinfunction(pctrl->pctrl, func, NULL); > + if (ret < 0) > + return ret; > + } It's good in principle, but we're now going to house two copies of the function data in memory... Can we trust __initconst nowadays? Konrad
On Thu, Jul 10, 2025 at 2:25 PM Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> wrote: > > On 7/9/25 4:39 PM, Bartosz Golaszewski wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > > > Use the existing infrastructure for storing and looking up pin functions > > in pinctrl core. Remove hand-crafted callbacks. > > > > Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> > > --- > > [...] > > > int msm_pinctrl_probe(struct platform_device *pdev, > > const struct msm_pinctrl_soc_data *soc_data) > > { > > + const struct pinfunction *func; > > struct msm_pinctrl *pctrl; > > struct resource *res; > > int ret; > > @@ -1606,6 +1581,14 @@ int msm_pinctrl_probe(struct platform_device *pdev, > > return PTR_ERR(pctrl->pctrl); > > } > > > > + for (i = 0; i < soc_data->nfunctions; i++) { > > + func = &soc_data->functions[i]; > > + > > + ret = pinmux_generic_add_pinfunction(pctrl->pctrl, func, NULL); > > + if (ret < 0) > > + return ret; > > + } > > It's good in principle, but we're now going to house two copies of > the function data in memory... Can we trust __initconst nowadays? > Well, if I annotate the functions struct with __initconst, then it does indeed end up in the .init.rodata section if that's your question. Then the kernel seems to be freeing this in ./kernel/module/main.c so I sure hope we can trust it. Do I understand correctly that you're implicitly asking to also annotate all affected _functions structures across all tlmm drivers? Alternatively: we can provide another interface: pinmux_generic_add_const_pinfunction() which - instead of a deep-copy - would simply store addresses of existing pinfunction structures in the underlying radix tree. Bartosz
On 7/10/25 3:38 PM, Bartosz Golaszewski wrote: > On Thu, Jul 10, 2025 at 2:25 PM Konrad Dybcio > <konrad.dybcio@oss.qualcomm.com> wrote: >> >> On 7/9/25 4:39 PM, Bartosz Golaszewski wrote: >>> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>> >>> Use the existing infrastructure for storing and looking up pin functions >>> in pinctrl core. Remove hand-crafted callbacks. >>> >>> Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org> >>> --- >> >> [...] >> >>> int msm_pinctrl_probe(struct platform_device *pdev, >>> const struct msm_pinctrl_soc_data *soc_data) >>> { >>> + const struct pinfunction *func; >>> struct msm_pinctrl *pctrl; >>> struct resource *res; >>> int ret; >>> @@ -1606,6 +1581,14 @@ int msm_pinctrl_probe(struct platform_device *pdev, >>> return PTR_ERR(pctrl->pctrl); >>> } >>> >>> + for (i = 0; i < soc_data->nfunctions; i++) { >>> + func = &soc_data->functions[i]; >>> + >>> + ret = pinmux_generic_add_pinfunction(pctrl->pctrl, func, NULL); >>> + if (ret < 0) >>> + return ret; >>> + } >> >> It's good in principle, but we're now going to house two copies of >> the function data in memory... Can we trust __initconst nowadays? >> > > Well, if I annotate the functions struct with __initconst, then it > does indeed end up in the .init.rodata section if that's your > question. Then the kernel seems to be freeing this in > ./kernel/module/main.c so I sure hope we can trust it. > > Do I understand correctly that you're implicitly asking to also > annotate all affected _functions structures across all tlmm drivers? > > Alternatively: we can provide another interface: > pinmux_generic_add_const_pinfunction() which - instead of a deep-copy > - would simply store addresses of existing pinfunction structures in > the underlying radix tree. This option seems like less of a churn Konrad
© 2016 - 2025 Red Hat, Inc.