[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <CXT1WVQ3YTND.ICHBOMMNR837@bootlin.com>
Date: Wed, 20 Dec 2023 10:25:11 +0100
From: Théo Lebrun <theo.lebrun@...tlin.com>
To: "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>, "Vladimir
Kondratiev" <vladimir.kondratiev@...ileye.com>, "Gregory CLEMENT"
<gregory.clement@...tlin.com>, "Philipp Zabel" <p.zabel@...gutronix.de>,
"Rob Herring" <robh+dt@...nel.org>, "Krzysztof Kozlowski"
<krzysztof.kozlowski+dt@...aro.org>, "Conor Dooley" <conor+dt@...nel.org>,
"Thomas Bogendoerfer" <tsbogend@...ha.franken.de>
Cc: <linux-mips@...r.kernel.org>, <devicetree@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, "Thomas Petazzoni"
<thomas.petazzoni@...tlin.com>, "Tawfik Bayouk"
<tawfik.bayouk@...ileye.com>
Subject: Re: [PATCH 1/4] dt-bindings: reset: mobileye,eyeq5-reset: add
bindings
Hello,
Thanks for your comments. I have a question for one:
On Tue Dec 19, 2023 at 8:40 AM CET, Krzysztof Kozlowski wrote:
> On 18/12/2023 18:16, Théo Lebrun wrote:
> > Add DT-Schema bindings for the EyeQ5 reset controller.
> >
> > Signed-off-by: Théo Lebrun <theo.lebrun@...tlin.com>
> > ---
> > .../bindings/reset/mobileye,eyeq5-reset.yaml | 69 +++++++++++++++++++
> > MAINTAINERS | 2 +
> > include/dt-bindings/reset/mobileye,eyeq5-reset.h | 80 ++++++++++++++++++++++
> > 3 files changed, 151 insertions(+)
> >
[...]
> > diff --git a/include/dt-bindings/reset/mobileye,eyeq5-reset.h b/include/dt-bindings/reset/mobileye,eyeq5-reset.h
> > new file mode 100644
> > index 000000000000..ce59fe5409ac
> > --- /dev/null
> > +++ b/include/dt-bindings/reset/mobileye,eyeq5-reset.h
> > @@ -0,0 +1,80 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> > +/*
> > + * Copyright (C) 2023 Mobileye Vision Technologies Ltd.
> > + */
> > +
> > +#ifndef _DT_BINDINGS_RESET_MOBILEYE_EYEQ5_RESET_H
> > +#define _DT_BINDINGS_RESET_MOBILEYE_EYEQ5_RESET_H
> > +
> > +/* Domain 0 */
> > +
> > +/* 0..2 are reserved */
>
> No, they are not. IDs cannot be reserved. IDs start from 0 and are
> incremented by 1. Reserving an ID contradicts to entire point of that
> ID, so either drop entire file or make this proper IDs.
Those are hardware IDs. I get what you mean is that they should not leak
into bindings. That implies a mapping operation from bindings IDs to
understood-by-hardware IDs. Can you confirm this is what you expect?
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
Powered by blists - more mailing lists