[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20240131202239.GA2222869-robh@kernel.org>
Date: Wed, 31 Jan 2024 14:22:39 -0600
From: Rob Herring <robh@...nel.org>
To: Johan Hovold <johan@...nel.org>
Cc: Bjorn Andersson <quic_bjorande@...cinc.com>,
Dmitry Torokhov <dmitry.torokhov@...il.com>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Benjamin Tissoires <benjamin.tissoires@...hat.com>,
Jiri Kosina <jikos@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Johan Hovold <johan+linaro@...nel.org>,
linux-arm-msm@...r.kernel.org, linux-input@...r.kernel.org,
devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
Konrad Dybcio <konrad.dybcio@...ainline.org>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Subject: Re: [PATCH v3 1/2] dt-bindings: HID: i2c-hid: Document reset-related
properties
On Mon, Jan 29, 2024 at 05:56:47PM +0100, Johan Hovold wrote:
> On Mon, Jan 29, 2024 at 08:47:47AM -0800, Bjorn Andersson wrote:
> > Some I2C HID devices has a reset pin and requires that some specified
> > time elapses after this reset pin is deasserted, before communication
> > with the device is attempted.
> >
> > The Linux implementation is looking for these in the "reset-gpios" and
> > "post-reset-deassert-delay-ms" properties already, so use these property
> > names.
>
> > + post-reset-deassert-delay-ms:
> > + description: Time required by the device after reset has been deasserted,
> > + before it is ready for communication.
> > +
> > + reset-gpios: true
>
> Hmm, for the third time, it seems you ignored my comment that you need
> to remove the comment about these properties from the driver as part of
> this series.
>
> /*
> * Note this is a kernel internal device-property set by x86 platform code,
> * this MUST not be used in devicetree files without first adding it to
> * the DT bindings.
> */
> if (!device_property_read_u32(dev, "post-reset-deassert-delay-ms", &val))
> ihid_of->post_reset_delay_ms = val;
DT devices should have a specific compatible that gives enough detail to
handle this delay or *any* other power sequencing requirement.
OTOH, we've already got one other delay property, what's one more. Sigh.
Acked-by: Rob Herring <robh@...nel.org>
Rob
Powered by blists - more mailing lists