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]
Date: Fri, 19 Jan 2024 09:20:01 +0100
From: Nuno Sá <noname.nuno@...il.com>
To: "Paller, Kim Seer" <KimSeer.Paller@...log.com>, Conor Dooley
	 <conor@...nel.org>
Cc: "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>, 
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Jonathan
 Cameron <jic23@...nel.org>,  Lars-Peter Clausen <lars@...afoo.de>,
 "Hennerich, Michael" <Michael.Hennerich@...log.com>, Rob Herring
 <robh+dt@...nel.org>, Krzysztof Kozlowski
 <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
 Crt Mori <cmo@...exis.com>, Linus Walleij <linus.walleij@...aro.org>, 
 Bartosz Golaszewski <brgl@...ev.pl>
Subject: Re: [PATCH v6 1/2] dt-bindings: iio: frequency: add admfm2000

Hi Kim,

On Fri, 2024-01-19 at 00:30 +0000, Paller, Kim Seer wrote:
> > -----Original Message-----
> > From: Conor Dooley <conor@...nel.org>
> > Sent: Friday, January 19, 2024 12:10 AM
> > To: Paller, Kim Seer <KimSeer.Paller@...log.com>
> > Cc: linux-iio@...r.kernel.org; devicetree@...r.kernel.org; linux-
> > kernel@...r.kernel.org; Jonathan Cameron <jic23@...nel.org>; Lars-Peter
> > Clausen <lars@...afoo.de>; Hennerich, Michael
> > <Michael.Hennerich@...log.com>; Rob Herring <robh+dt@...nel.org>;
> > Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>; Conor Dooley
> > <conor+dt@...nel.org>; Crt Mori <cmo@...exis.com>; Linus Walleij
> > <linus.walleij@...aro.org>; Bartosz Golaszewski <brgl@...ev.pl>
> > Subject: Re: [PATCH v6 1/2] dt-bindings: iio: frequency: add admfm2000
> > 
> > [External]
> > 
> > Hey,
> > 
> > On Thu, Jan 18, 2024 at 04:58:55PM +0800, Kim Seer Paller wrote:
> > > Dual microwave down converter module with input RF and LO frequency
> > > ranges from 0.5 to 32 GHz and an output IF frequency range from 0.1 to
> > > 8 GHz. It consists of a LNA, mixer, IF filter, DSA, and IF amplifier
> > > for each down conversion path.
> > > 
> > > Signed-off-by: Kim Seer Paller <kimseer.paller@...log.com>
> > > ---
> > > V5 -> V6: Moved array of switch and attenuation GPIOs to the channel node.
> > >           Changed pin coords with friendly names. Removed Reviewed-by tag.
> > > V4 -> V5: Added Reviewed-by tag.
> > > V3 -> V4: Updated the description of the properties with multiple entries and
> > >           defined the order.
> > > V2 -> V3: Adjusted indentation to resolve wrong indentation warning.
> > >           Changed node name to converter. Updated the descriptions to clarify
> > >           the properties.
> > > V1 -> V2: Removed '|' after description. Specified the pins connected to
> > >           the GPIOs. Added additionalProperties: false. Changed node name to
> > gpio.
> > >           Aligned < syntax with the previous syntax in the examples.
> > > 
> > >  .../bindings/iio/frequency/adi,admfm2000.yaml | 129 ++++++++++++++++++
> > >  MAINTAINERS                                   |   7 +
> > >  2 files changed, 136 insertions(+)
> > >  create mode 100644
> > Documentation/devicetree/bindings/iio/frequency/adi,admfm2000.yaml
> > > 
> > > diff --git
> > a/Documentation/devicetree/bindings/iio/frequency/adi,admfm2000.yaml
> > b/Documentation/devicetree/bindings/iio/frequency/adi,admfm2000.yaml
> > > new file mode 100644
> > > index 000000000000..6f2c91c38666
> > > --- /dev/null
> > > +++
> > b/Documentation/devicetree/bindings/iio/frequency/adi,admfm2000.yaml
> > > @@ -0,0 +1,129 @@
> > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > +# Copyright 2023 Analog Devices Inc.
> > > +%YAML 1.2
> > > +---
> > > +$id: http://devicetree.org/schemas/iio/frequency/adi,admfm2000.yaml#
> > > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > > +
> > > +title: ADMFM2000 Dual Microwave Down Converter
> > > +
> > > +maintainers:
> > > +  - Kim Seer Paller <kimseer.paller@...log.com>
> > > +
> > > +description:
> > > +  Dual microwave down converter module with input RF and LO frequency
> > ranges
> > > +  from 0.5 to 32 GHz and an output IF frequency range from 0.1 to 8 GHz.
> > > +  It consists of a LNA, mixer, IF filter, DSA, and IF amplifier for each down
> > > +  conversion path.
> > > +
> > > +properties:
> > > +  compatible:
> > > +    enum:
> > > +      - adi,admfm2000
> > > +
> > > +  '#address-cells':
> > > +    const: 1
> > > +
> > > +  '#size-cells':
> > > +    const: 0
> > > +
> > > +patternProperties:
> > > +  "^channel@[0-1]$":
> > > +    type: object
> > > +    description: Represents a channel of the device.
> > > +
> > > +    additionalProperties: false
> > > +
> > > +    properties:
> > > +      reg:
> > > +        description:
> > > +          The channel number.
> > > +        minimum: 0
> > > +        maximum: 1
> > > +
> > > +      adi,mode:
> > > +        description:
> > > +          RF path selected for the channel.
> > > +            0 - Direct IF mode
> > > +            1 - Mixer mode
> > > +        $ref: /schemas/types.yaml#/definitions/uint32
> > > +        enum: [0, 1]
> > 
> > How come this is an enum, rather than a boolean property such as
> > "adi,mixer-mode"?
> 
> I used an enum, perhaps because it was easier to implement. However, this
> could be changed if a boolean property might be more suitable in this case.
> Is that the preferred option?
> 

Hmmm, How is the enum easier than a boolean property :)? I guess the device has a
default mode. So, if it is Direct IF mode you have 'adi,mixer-mode' to enable that
mode and that's it. So the code is pretty much just:

if (device_property_read_bool()) {
	/* enable mixer mode */
}

Also remember that from a bindings point of view being easier to implement or not in
the driver does not matter much. Take for an example, properties with well know units
like 'microamp'. It would be much easier to just have an enum with the device
register values but that's not how we should do it since it wouldn't be intuitive at
all for people reading devicetrees.

- Nuno Sá


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ