All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Hauer <s.hauer@pengutronix.de>
To: Stephen Boyd <sboyd@kernel.org>
Cc: "Conor Dooley" <conor+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Rob Herring" <robh@kernel.org>,
	linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
	devicetree@vger.kernel.org, kernel@pengutronix.de,
	"Alvin Šipraga" <alsi@bang-olufsen.dk>
Subject: Re: [PATCH v4 2/3] dt-bindings: clock: add TI CDCE6214 binding
Date: Thu, 8 May 2025 09:22:23 +0200	[thread overview]
Message-ID: <aBxbr8CyKmdZQobS@pengutronix.de> (raw)
In-Reply-To: <1f072e2e02bb6a66d10c50177e5c69a6@kernel.org>

On Wed, May 07, 2025 at 01:11:31PM -0700, Stephen Boyd wrote:
> Quoting Sascha Hauer (2025-05-07 01:05:13)
> > On Mon, May 05, 2025 at 10:50:49AM -0700, Stephen Boyd wrote:
> > > Quoting Sascha Hauer (2025-04-30 02:01:35)
> > > > diff --git a/Documentation/devicetree/bindings/clock/ti,cdce6214.yaml b/Documentation/devicetree/bindings/clock/ti,cdce6214.yaml
> > > > new file mode 100644
> > > > index 0000000000000..d4a3a3df9ceb9
> > > > --- /dev/null
> > > > +++ b/Documentation/devicetree/bindings/clock/ti,cdce6214.yaml
> > > > @@ -0,0 +1,155 @@
> > > > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> > > > +
> > > > +patternProperties:
> > > > +  '^clk@[0-1]$':
> > > > +    type: object
> > > > +    description:
> > > > +      optional child node that can be used to specify input pin parameters. The reg
> > > > +      properties match the CDCE6214_CLK_* defines.
> > > 
> > > Presumably the EEPROM is typically used to configure all this stuff? Do
> > > you actually need to program this from the kernel, or are you
> > > implementing all this for development purposes?
> > 
> > The EEPROM could be used to configure this. I don't know if the final
> > product will have the EEPROM programmed, but even if it is, should we
> > make this mandatory?
> 
> No I'm not asking about making the property/node required. I'm wondering
> if you're actually using these bindings. If they're not used then I
> worry we're putting a bunch of configuration in here that we'll never
> use.

At the moment we are using the device tree binding. I asked our customer if
they plan to use it in production as well.

> 
> > 
> > Speaking of the EEPROM I think we should make sure that the pin
> > configuration in the device tree is optional so that we do not overwrite
> > settings from the EEPROM if it contains valid values.
> 
> Ok. Aren't the pinctrl settings already optional?

Yes, they are, but when the pin setup is missing I haven't explicitly taken
care to not overwrite any settings made by the EEPROM. Likely the driver
just does it right. Without pin setup the registers are just not
touched.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

  reply	other threads:[~2025-05-08  7:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-30  9:01 [PATCH v4 0/3] clk: add support for TI CDCE6214 Sascha Hauer
2025-04-30  9:01 ` [PATCH v4 1/3] clk: make determine_rate optional for non reparenting clocks Sascha Hauer
2025-04-30 22:15   ` Stephen Boyd
2025-04-30  9:01 ` [PATCH v4 2/3] dt-bindings: clock: add TI CDCE6214 binding Sascha Hauer
2025-05-01 11:54   ` Krzysztof Kozlowski
2025-05-05 17:50   ` Stephen Boyd
2025-05-07  8:05     ` Sascha Hauer
2025-05-07 20:11       ` Stephen Boyd
2025-05-08  7:22         ` Sascha Hauer [this message]
2025-06-16 10:02           ` Sascha Hauer
2025-04-30  9:01 ` [PATCH v4 3/3] clk: add TI CDCE6214 clock driver Sascha Hauer
2025-05-01 18:48   ` Stephen Boyd
2025-05-05 10:02     ` Sascha Hauer
2025-05-07  7:07   ` kernel test robot
2025-05-09  6:39 ` [PATCH v4 0/3] clk: add support for TI CDCE6214 Sascha Hauer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aBxbr8CyKmdZQobS@pengutronix.de \
    --to=s.hauer@pengutronix.de \
    --cc=alsi@bang-olufsen.dk \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kernel@pengutronix.de \
    --cc=krzk+dt@kernel.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=robh@kernel.org \
    --cc=sboyd@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.