LKML Archive mirror
 help / color / mirror / Atom feed
From: Krzysztof Adamski <k@japko.eu>
To: Maxime Ripard <maxime.ripard@free-electrons.com>
Cc: Jean-Francois Moine <moinejf@free.fr>,
	inus Walleij <linus.walleij@linaro.org>,
	Chen-Yu Tsai <wens@csie.org>, Hans de Goede <hdegoede@redhat.com>,
	Lee Jones <lee@kernel.org>, Rob Herring <robh@kernel.org>,
	Jens Kuske <jenskuske@gmail.com>,
	Fabian Frederick <fabf@skynet.be>,
	Vishnu Patekar <vishnupatekar0510@gmail.com>,
	linux-gpio@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com
Subject: Re: [linux-sunxi] Re: [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3
Date: Wed, 10 Feb 2016 08:17:14 +0100	[thread overview]
Message-ID: <20160210071713.GA19622@box2.japko.eu> (raw)
In-Reply-To: <20160209171040.GR31506@lukather>

On Tue, Feb 09, 2016 at 06:10:40PM +0100, Maxime Ripard wrote:
>> >>It seems that the other compatible strings are there for historical
>> >>reasons. Why do you need a new one with such a specific name?
>> >>
>> >>It would have been more sensible to add a generic compatible string as
>> >>"allwinner,apb-gates", letting the removal of the other strings for a
>> >>later patch...
>> >
>> >Yeah, it's a good idea, and it's probably time that we move to that.
>> >
>> >However, I'd like to keep per-soc and per-clocks compatibles in the
>> >DT, in case we need to protect a clock in the future. That doesn't
>> >prevent to have two compatibles thoughe, the specific and the generic.
>> >
>>
>> So now I'm not sure what you mean. You suggest that I should keep using
>> specific (sun8i_h3_apb0) or change to generic (apb-gates) in my patch?
>
>Both.
>
>To have something like that:
>
>compatible = "allwinner,sun8i-h3-apb0-gates-clk", "allwinner,sun4i-a10-gates-clk";
>
>sun4i-a10-gates-clk being the generic compatible that we would use,
>and we can always match against the h3 specific compatible if we need
>to have a different behaviour.

This seems like a good idea to me but since this is new thing anyways 
(other sunxi SoCs don't do this right now) shouldn't we introduce other
more generic name for generic clock (like "allwinner,apb-gates" 
mentioned earlier, or maybe "allwinner,simple-apb-gates")?

Also, wouldn't this be cleaner if I use only specific compatible string 
right now and provide separate patch that adds generic compatible string 
to all current SoCs at once? The downside of this is that it's easier to 
get merge conflicts unless I wait for applying this patchset.

Best regards,
Krzysztof Adamski

  reply	other threads:[~2016-02-10  7:18 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-03 23:33 [PATCH v3 0/5] pinctrl: sunxi: Add H3 R_PIO controller support Krzysztof Adamski
2016-02-03 23:33 ` [PATCH v3 1/5] clk: sunxi: Add apb0 gates for H3 Krzysztof Adamski
2016-02-04 14:47   ` Jean-Francois Moine
2016-02-04 20:56     ` Krzysztof Adamski
2016-02-05 11:14       ` Maxime Ripard
2016-02-05 11:11     ` Maxime Ripard
2016-02-05 11:58       ` Krzysztof Adamski
2016-02-09 17:10         ` Maxime Ripard
2016-02-10  7:17           ` Krzysztof Adamski [this message]
2016-02-10 15:06             ` [linux-sunxi] " Maxime Ripard
2016-02-06 10:26       ` Jean-Francois Moine
2016-02-09 17:11         ` Maxime Ripard
2016-02-03 23:33 ` [PATCH v3 2/5] dts: sun8i-h3: Add APB0 related clocks and resets Krzysztof Adamski
2016-02-03 23:33 ` [PATCH v3 3/5] pinctrl: sunxi: Add H3 R_PIO controller support Krzysztof Adamski
2016-02-05  9:44   ` Chen-Yu Tsai
2016-02-05  9:46   ` Maxime Ripard
2016-02-03 23:33 ` [PATCH v3 4/5] ARM: dts: sun8i-h3: Add R_PIO controller node to the dtsi Krzysztof Adamski
2016-02-05  9:46   ` Chen-Yu Tsai
2016-02-08  8:39     ` Krzysztof Adamski
2016-02-03 23:33 ` [PATCH v3 5/5] pinctrl: sunxi: Use pin number when calling sunxi_pmx_set Krzysztof Adamski
2016-02-05  9:45   ` Chen-Yu Tsai
2016-02-05 11:15   ` Maxime Ripard

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=20160210071713.GA19622@box2.japko.eu \
    --to=k@japko.eu \
    --cc=fabf@skynet.be \
    --cc=hdegoede@redhat.com \
    --cc=jenskuske@gmail.com \
    --cc=lee@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=maxime.ripard@free-electrons.com \
    --cc=moinejf@free.fr \
    --cc=robh@kernel.org \
    --cc=vishnupatekar0510@gmail.com \
    --cc=wens@csie.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).