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] [day] [month] [year] [list]
Message-ID: <7dd0607c-cbe4-e763-03a0-5f9a5db9d6db@9elements.com>
Date:   Mon, 31 Jul 2023 20:59:00 +0530
From:   Naresh Solanki <naresh.solanki@...ements.com>
To:     Peter Rosin <peda@...ntia.se>,
        Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Patrick Rudolph <patrick.rudolph@...ements.com>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-i2c@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v14 2/4] dt-bindings: i2c: Add Maxim MAX735x/MAX736x
 variants

Hi Peter,

On 02-05-2023 16:06, Peter Rosin wrote:
> Hi!
>
> 2023-05-02 at 10:46, Krzysztof Kozlowski wrote:
>> On 02/05/2023 08:52, Patrick Rudolph wrote:
>>> Hi Peter,
>>> it could indeed cause problems when VDD1 != VDD2 and at both needs to
>>> be enabled.
>>> The pca9846 datasheet seems to refer to VDD1 as VDD. Thus I could add
>>> an optional "vdd2" regulator to the binding and driver.
>>>
>>> Please let me know if that's what you had in mind.
>> Don't top post.
>>
>> In such case vdd-supply should not be used for VDD2.
> When reading the data sheet [1], I get the feeling that the instances
> of VDD are either copy-paste errors from data sheets from chip with a
> single VDD, or a reference to either of VDD1 or VDD2. It is thus not
> super clear to me that VDD should be the same thing as VDD1.
>
> Sure, there is section 6.5 "Power-on reset", which mentions VDD and
> VDD2 (but not VDD1), but that seems like a simply typo and that it
> should really have been VDD1 instead of an unqualified VDD.
>
> There are also various timings "glitch supply voltage difference"
> (delta VDD(gl)) and "supply voltage glitch pulse width" (t w(gl)VDD)
> with notes that refer to VDD2, which *could* indicate that the
> glitch in VDD is about a glitch VDD1. But it could also mean glitches
> on any of VDD1 and VDD2?
>
> The general description of the chip indicates that VDD1 is there
> mainly to allow different bus voltages on each of the channels.
> Which is not at all the function of VDD on the other chips. Meanwhile
> VDD2 "is the core logic supply from which most of the PCA9846
> circuitry runs", and seems like it is a better match for plain VDD?
Yes, based on Figure 14 in datasheet, VDD2 seems to be better match
for plain VDD.
Also VDD1 is I2C bus voltage on micro-controller side so the best
match I can think of is VBUS.
>
> Maybe one can find out more by reading the spec more carefully, but
> as I said, it is not clear to me that either of VDD1 or VDD2 can be
> matched to VDD.
>
> Perhaps it is best to not mix things at all?
Yes. For designs with same voltage rails, "VDD" can serve the purpose.
For designs with different voltage rail, VBUS would be needed to
identify micro-controller side bus supply.
Let me know your thoughts.

Regards,
Naresh
>
> [1] https://www.nxp.com/docs/en/data-sheet/PCA9846.pdf
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ