Hi Krzysztof, On Fri, 12 Jul 2024 13:55:09 +0200, krzk@xxxxxxxxxx wrote: >On 12/07/2024 13:31, wangshuaijie@xxxxxxxxxx wrote: >> From: shuaijie wang <wangshuaijie@xxxxxxxxxx> >> >> Add the awinic,aw96xxx.yaml file to adapt to the awinic proximity sensor driver. >> Addressing the issues raised in the previous version. >> 1. Add a description about the hardware device. >> 2. Remove inappropriate configuration items. >> 3. Modify the formatting issues. > >That's commit msg or changelog? Don't mix both. Read submitting patches. > The patch for v4 will fix these issues. >> >> Signed-off-by: shuaijie wang <wangshuaijie@xxxxxxxxxx> >> --- >> .../iio/proximity/awinic,aw96xxx.yaml | 127 ++++++++++++++++++ >> 1 file changed, 127 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/iio/proximity/awinic,aw96xxx.yaml >> >> diff --git a/Documentation/devicetree/bindings/iio/proximity/awinic,aw96xxx.yaml b/Documentation/devicetree/bindings/iio/proximity/awinic,aw96xxx.yaml >> new file mode 100644 >> index 000000000000..459cb1644d3c >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/iio/proximity/awinic,aw96xxx.yaml >> @@ -0,0 +1,127 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/input/awinic,aw96xxx.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Awinic's AW96XXX capacitive proximity sensor >> + >> +maintainers: >> + - Shuaijie Wang <wangshuaijie@xxxxxxxxxx> >> + >> +description: | >> + Awinic's AW96XXX proximity sensor. >> + The specific absorption rate (SAR) is a metric that measures >> + the degree of absorption of electromagnetic radiation emitted by wireless >> + devices, such as mobile phones and tablets, by human tissue. >> + In mobile phone applications, the proximity sensor is primarily used to detect >> + the proximity of the human body to the phone. When the phone approaches the human body, >> + it will actively reduce the transmit power of the antenna to keep the SAR within a safe >> + range. Therefore, we also refer to the proximity sensor as a SAR sensor. > >Wrap at 80 (see Coding style). > The patch for v4 will fix these issues. >> + >> +properties: >> + compatible: >> + enum: >> + - awinic,aw96103 >> + - awinic,aw96105 >> + - awinic,aw96303 >> + - awinic,aw96305 >> + - awinic,aw96308 >> + >> + reg: >> + maxItems: 1 >> + >> + interrupts: >> + description: >> + Generated by the device to announce that a close/far >> + proximity event has happened. >> + maxItems: 1 >> + >> + awinic,sar-num: > >Drop the property. I already asked. > The patch for v4 will remove this property. >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + Set the number of the SAR(Specific Absorption Rate) sensor. >> + It is set to 0 if one awinic sar chip is used. >> + If two awinic sar chips are used, awinic,sar-label in the first >> + awinic-sar should be set to 0 and awinic,sar-label in the second >> + awinic-sar should be set to 1. >> + In an application where a device utilizes multiple proximity sensors, >> + it is used to retrieve the names of the register configuration files >> + that the drivers need to load. For example: aw963xx_reg_0.bin/aw963xx_reg_1.bin >> + >> + awinic,regulator-power-supply: > >It does not look like you tested the bindings, at least after quick >look. Please run `make dt_binding_check` (see >Documentation/devicetree/bindings/writing-schema.rst for instructions). >Maybe you need to update your dtschema and yamllint. > The patch for v4 will fix these issues. >> + description: >> + Choose if you want to use a regulator to power the chip. Then the >> + vccX-supply has to be set. >> + >> + vcc0-supply: >> + description: >> + Optional regulator for chip, 1.7V-3.6V. >> + If two awinic sar chips are used, the first regulator >> + should set the ID to vcc0-supply and the second regulator >> + should set the ID to vcc1-supply. >> + >> + awinic,channel-use-mask: > >Aren't there existing IIO properties like this? The patch for v4 will remove this property. > >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + description: >> + The mask of channels used. >> + Configure according to the specific chip channel used. >> + Bit[31:0] Each bit represents a channel. >> + If the customer uses ch0 and ch2, then channel_use_mask=<0x05> >> + For a 3-channel chip, the maximum value is 0x07; >> + For a 5-channel chip, the maximum value is 0x1F; >> + For a 8-channel chip, the maximum value is 0xFF; >> + >> + awinic,monitor-esd: >> + type: boolean >> + description: >> + Choose if you want to monitor ESD. > >Why this is a choice? How does this describe hardware. > The patch for v4 will remove this property. >> + >> + awinic,pin-set-inter-pull-up: >> + type: boolean >> + description: >> + Choose if you want to set the interrupt pin to internal pull-up. >> + >> + awinic,using-pm-ops: > >NAK, drop all such OS policies. > The patch for v4 will remove this property. >> + type: boolean >> + description: >> + Choose if you want to change the chip mode on suppend and resume. >> + >> + awinic,use-plug-cail:> + type: boolean >> + description: >> + Choose If you want to perform calibration when plugging and unplugging the charger. > >And why this is board dependent? > The patch for v4 will remove this property. >> + >> + awinic,irq-mux: >> + $ref: /schemas/types.yaml#/definitions/uint32 >> + enum: [2, 5] >> + description: >> + You only need to set this configuration item if you are using AW96308 adn AW96305BFOR. >> + If CS2 is used as the interrupt pin, this item should be set to 2. >> + If CS5 is used as the interrupt pin, this item should be set to 5. >> + > > >Best regards, >Krzysztof Thank you very much for your valuable advice. I will address these issues in the next version of the patch. Kind regards, Wang Shuaijie
