On Tue, Jan 23, 2024 at 01:06:45PM +0000, Mark Brown wrote: > On Tue, Jan 23, 2024 at 08:34:03AM +0000, Conor Dooley wrote: > > On Mon, Jan 22, 2024 at 07:40:51PM +0000, Mark Brown wrote: > > > On Mon, Jan 22, 2024 at 06:00:14PM +0000, Conor Dooley wrote: > > > > On Mon, Jan 22, 2024 at 05:56:49PM +0800, Seven Lee wrote: > > > > > > + enum: > > > > > + - 0 # VDDA > > > > > + - 1 # VDDA*1.5/1.8V > > > > > + - 2 # VDDA*1.6/1.8V > > > > > + - 3 # VDDA*1.7/1.8V > > > > > I would also rather than this enum was used to have sensible values for > > > > the enum itself (which I suppose means strings here), rather than the > > > > register values. Seeing "nuvoton,dac-vref = <2>" in a devicetree is not > > > > very meaningful IMO. > > > > Do you have a concrete suggestion for how to more clearly write these > > > directly? > > > I would use what's been given as the explanation comments for each of > > the current enum values in the patch. > > Given that none of *, / nor . are usable in defines that's going to need > a bit of massaging... At the end of the day, if it is too painful on the driver, then I'll live with another enum. This is one of the worse cases of this sort of enum that is clearly a bunch of register values, given there's not a "nice" explanation for them.
Attachment:
signature.asc
Description: PGP signature
