[RFC PATCH 2/2] lib: reset: thead: Correct the naming convention of dts

[Guo Ren]

On Wed, May 24, 2023 at 11:55 PM Jessica Clarke <jrtc27 at jrtc27.com> wrote:
>
> On 24 May 2023, at 15:46, Conor Dooley <conor at kernel.org> wrote:
> >
> > On Wed, May 24, 2023 at 06:39:47PM +0800, Guo Ren wrote:
> >
> >> We remove reset-ctrl-val, but still keep csr-copy. Because it contains
> >> the index, not value. It didn't viloate anything. okay?
> >
> > If it is set per-soc, which apparently it is, then you don't need to
> > fill the values into a property to communicate it to software because
> > you already have a compatible that tells you exactly what implementation
> > you have. Just like it is normal for a driver to use #defines etc for
> > register access, since it knows those registers exist on a particular
> > implementation. I don't know what OpenSBI calls this, but in Linux it
> > is called match_data.
> > Either way - we are just going around in circles here :)
>
> I don’t actually understand this opinion. As a driver author, I would
> much prefer to be able to write a single parameterised driver where the
> important parameters com from the FDT, rather than having to figure out
> all the parameters myself and put them in a table that gets looked up.
> Otherwise you could take this to the extreme and just have the
> compatible, with everything else hard-coded in the driver, which gets
> you much closer to ACPI’s model, which itself is borrowing from the FDT
> model and now adding key-value pairs to _DSD. Take something like
> gpio-restart, which has three configurable delays. Should those instead
> be done based on a per-SoC compatible? Or take syscon-reboot, which has
> configurable offset and mask. Should those be done based on a per-SoC
> compatible? Having just the one compatible means the driver can be
> written once and not need touching again as new SoCs appear, since the
> parameters themselves are in the FDT, but if you instead have a
> mycompany,mysoc-syscon-reboot for every SoC then each time a new SoC
> appears you need to go add the offset+mask values to your big lookup
> table in the driver and use a new kernel. This flexibility to put all
> the parameters in the FDT was always something I saw as an advantage of
> FDTs over ACPI.
I prefer FDTs to ACPI so much :)

>
> The SoC-specific compatible does have value in case the specific IP
> needs identifying to work around quirks, but IMO using that to derive
> all the parameters rather than having them in the FDT makes drivers
> worse.
Thx sincerely. You've said what I want.

>
> Jess

>


--
Best Regards
 Guo Ren