RE: [PATCH v2] pinctrl: samsung: Add support for pull-up and pull-down

["Vishnu Reddy" <vishnu.reddy@samsung.com>]

> -----Original Message-----
> From: Krzysztof Kozlowski [mailto:krzk@kernel.org]
> Sent: 27 June 2024 20:58
> To: Vishnu Reddy <vishnu.reddy@samsung.com>; 'Krzysztof Kozlowski'
> <krzysztof.kozlowski@linaro.org>; s.nawrocki@samsung.com;
> alim.akhtar@samsung.com; linus.walleij@linaro.org
> Cc: linux-arm-kernel@lists.infradead.org; linux-samsung-
> soc@vger.kernel.org; linux-gpio@vger.kernel.org; linux-
> kernel@vger.kernel.org; pankaj.dubey@samsung.com;
> ravi.patel@samsung.com; gost.dev@samsung.com
> Subject: Re: [PATCH v2] pinctrl: samsung: Add support for pull-up and pull-
> down
> 
> On 27/06/2024 17:22, Krzysztof Kozlowski wrote:
> > On 27/06/2024 15:35, Vishnu Reddy wrote:
> >>>
> >>> I don't remember the code used here, but usually such choices are
> >>> determined by driver match data (and flags or value customized per
> variant).
> >> Hi, Thanks for suggestion.
> >> I have gone through this and found that driver match data in this driver is
> stored in the __initconst section, which is freed up after kernel initialization.
> So we have two options:
> >> 1: Keep this platform specific data in driver match data and then populate
> driver_data field in probe function.
> >> 2: Use compatible matching and set different values during set_config.
> >>
> >> First approach will result in many changes, such as populating  driver
> match data for all platforms and then storing the same in driver_data in
> probe.
> >>
> >> In the second approach, we can handle this using simple if/else based on
> a compatible match.
> >>
> >> IMO, second approach would be simpler and introduce less changes. Any
> suggestions from your end?
> >
> > Please wrap your email according to mailing list style.
> >
> > Both options are not the way because you introduce a new, different
> > style of handling per-variant customization. The driver already parses
> > match data and stores such per-variant-details in different places, like
> > samsung_pin_bank or samsung_pinctrl_drv_data. This seems like a value
> > fixed per entire device, so could go to samsung_pinctrl_drv_data.
> 
> ... although maybe this matches your first option? Not sure.
My understanding is same that the value is fixed per entire device. We can
add the pud data into samsung_pinctrl_drv_data and then fetch the pud
values during probe.
I will test this and submit v3 soon.
> 
> Best regards,
> Krzysztof