Re: [PATCH v3 2/3] dt-bindings: iio: adc: Add support for QCOM PMIC5 Gen3 ADC

[Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>]

On 16/02/2024 11:39, Jishnu Prakash wrote:
> Hi Krzysztof,
> 
> On 1/4/2024 1:48 PM, Krzysztof Kozlowski wrote:
>> On 31/12/2023 18:12, Jishnu Prakash wrote:
>>> For the PMIC5-Gen3 type PMICs, ADC peripheral is present in HW for the
>>> following PMICs: PMK8550, PM8550, PM8550B and PM8550VX PMICs.
>>>
>>> It is similar to PMIC5-Gen2, with SW communication to ADCs on all PMICs
>>> going through PBS(Programmable Boot Sequence) firmware through a single
>>> register interface. This interface is implemented on an SDAM (Shared
>>> Direct Access Memory) peripheral on the master PMIC PMK8550 rather
>>> than a dedicated ADC peripheral.
>>>
>>> Add documentation for PMIC5 Gen3 ADC and macro definitions for ADC
>>> channels and virtual channels (combination of ADC channel number and
>>> PMIC SID number) per PMIC, to be used by clients of this device.
>>>
>>> Changes since v2:
>>> - Moved ADC5 Gen3 documentation into a separate new file.
>> Changelog goes under ---.
>>
>> Why did you do this? What is the rationale? Sorry, this patchset goes
>> nowhere.
> 
> 
> I'll elaborate this more in the next patchset. There are two main 
> reasons for adding this documentation in a new file:

This was more than a month ago? You reply to my comment with 1.5 months
delay?

Sorry, I am not in the context and I am not going back to it. I have
many other emails where my questions are addressed faster than 1.5 months.

The patch is not even in my mailbox, long gone.
Why you are making it so difficult for reviewers?

You will get answers like I am not in context, sorry. Next time don't
respond after 1.5 months.


> 
> 1.This device is not exactly like the existing QCOM VADC drivers as it 
> now combines VADC functionality (reading ADC channel on client request) 
> with ADC_TM functionality (thermal threshold monitoring).

Does no explain touching bindings. Your drivers don't matter for bindings.

> 
> 2.Adding this device's bindings in the existing qcom,spmi-vadc.yaml file 

No rationale was provided in commit msg.

> is not possible as it would require updating some of the existing 
> top-level constraints. (for the older devices in that file, "reg" and 
> "interrupts" can have at most one item, while this device can have more 
> than one item under these properties.)

How is this a problem?


Best regards,
Krzysztof