linux-kernel - Re: [PATCH v2] pinctrl: samsung: Add support for pull-up and pull-down

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <dbe55275-a13e-46a3-8b45-b08c301088d4@kernel.org>
Date: Thu, 27 Jun 2024 17:22:27 +0200
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Vishnu Reddy <vishnu.reddy@...sung.com>,
 'Krzysztof Kozlowski' <krzysztof.kozlowski@...aro.org>,
 s.nawrocki@...sung.com, alim.akhtar@...sung.com, linus.walleij@...aro.org
Cc: linux-arm-kernel@...ts.infradead.org, linux-samsung-soc@...r.kernel.org,
 linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org,
 pankaj.dubey@...sung.com, ravi.patel@...sung.com, gost.dev@...sung.com
Subject: Re: [PATCH v2] pinctrl: samsung: Add support for pull-up and
 pull-down

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.

Best regards,
Krzysztof