All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yadwinder Singh Brar <yadi.brar01@gmail.com>
To: Andi Shyti <andi.shyti@samsung.com>
Cc: linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	Sangbeom Kim <sbkim73@samsung.com>,
	Krzysztof Kozlowski <k.kozlowski@samsung.com>,
	Michael Turquette <mturquette@baylibre.com>,
	Stephen Boyd <sboyd@codeaurora.org>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	linux-clk@vger.kernel.org, Andi Shyti <andi@etezian.org>
Subject: Re: [PATCH 2/2] clk: s2mps11: allocate only one structure for clock init
Date: Tue, 19 Jan 2016 00:00:52 -0800	[thread overview]
Message-ID: <CAKew6eWRev=U_4LeptMGjhz1-zNG1djiZJx4NLf0LoLQMNHQTg@mail.gmail.com> (raw)
In-Reply-To: <20160119024316.GA3793@samsunx.samsung>

On Mon, Jan 18, 2016 at 6:43 PM, Andi Shyti <andi.shyti@samsung.com> wrote:
> Hi Yadwinder,
>
>>     The driver allocates three structures for three different clock
>>     types. They are quite similar and in the clock init data they
>>     differ only by the name. Only one of these structure is used,
>>     while the others lie unused in the memory.
>>
>>
>> If you are worried about memory, they can be made __initdata by
>> creating a copy during probe.
>
> mmmhhh... allocating in boot time as much as we want and then copy
> what we need? It doesn't look that pretty to me.
>

I think its not a new practice and I don't see any issue with it.

>>     The clock's name, though, is not such a meaningful information
>>
>>
>> I think it can be meaningful in debugging.
>
> Can you explain what's the use of the naming other than
> debugging?
>

Isn't debugging important enough ?  :)

I had misunderstood your below statement.
Looking at code, it seems its still using different names for different clocks.

>>     and by assigning the same name to the initial data we can avoid
>>     over allocation. The common name chosen will be s2mps11,
>>     coherently with the device driver name, instead of the clock
>>     device.
>>
>>     Therefore, remove the structures associated to s2mps13 and
>>     s2mps14 and use only the one referred to s2mps11 for all kind of
>>     clocks.
>>
>>
>> IMHO, with all these modifications, it will leave driver with some extra
>> checks and reduced readability, perhaps will make it complex to add
>> support for similar clocks but with different clk_ops, if next version or
>>  any similar mfd chip comes up in future.
>
> In that case, when the new chip will come, we would need to
> figure out something,

Different structures were introduced to handle such cases and keep
driver simple and clean by keeping keep no. of if() checks as limited
as possible.

> but for sure I don't see it as a good idea
> to leave allocated unused structures.
>

Even a single unused structure isn't a good idea, in case where this driver
doesn't get probed. :)

Regards,
Yadwinder

> Thanks,
> Andi
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

      reply	other threads:[~2016-01-19  8:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-18  8:25 [PATCH 0/2] s2mps11 code refactoring Andi Shyti
2016-01-18  8:25 ` [PATCH 1/2] clk: s2mps11: remove redundant variable Andi Shyti
2016-01-18 23:34   ` Krzysztof Kozlowski
2016-01-18  8:25 ` [PATCH 2/2] clk: s2mps11: allocate only one structure for clock init Andi Shyti
2016-01-18 23:44   ` Krzysztof Kozlowski
2016-01-19  0:42   ` Yadwinder Singh Brar
2016-01-19  0:48     ` Krzysztof Kozlowski
2016-01-19  1:11       ` Yadwinder Singh Brar
2016-01-19  2:43     ` Andi Shyti
2016-01-19  8:00       ` Yadwinder Singh Brar [this message]

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='CAKew6eWRev=U_4LeptMGjhz1-zNG1djiZJx4NLf0LoLQMNHQTg@mail.gmail.com' \
    --to=yadi.brar01@gmail.com \
    --cc=andi.shyti@samsung.com \
    --cc=andi@etezian.org \
    --cc=k.kozlowski@samsung.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=sbkim73@samsung.com \
    --cc=sboyd@codeaurora.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.