> -----Original Message----- > From: Krzysztof Kozlowski [mailto:krzk@xxxxxxxxxx] > Sent: 27 June 2024 20:58 > To: Vishnu Reddy <vishnu.reddy@xxxxxxxxxxx>; 'Krzysztof Kozlowski' > <krzysztof.kozlowski@xxxxxxxxxx>; s.nawrocki@xxxxxxxxxxx; > alim.akhtar@xxxxxxxxxxx; linus.walleij@xxxxxxxxxx > Cc: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-samsung- > soc@xxxxxxxxxxxxxxx; linux-gpio@xxxxxxxxxxxxxxx; linux- > kernel@xxxxxxxxxxxxxxx; pankaj.dubey@xxxxxxxxxxx; > ravi.patel@xxxxxxxxxxx; gost.dev@xxxxxxxxxxx > 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
