[U-Boot] [U-Boot,v2,4/5] clk: implement clk_set_defaults()

[Dr. Philipp Tomsich]

> On 28 Jan 2018, at 18:21, Michael Nazzareno Trimarchi <michael at amarulasolutions.com> wrote:
> 
> Hi
> 
> 
> 
> On 28 Jan. 2018 6:15 pm, "Dr. Philipp Tomsich" <philipp.tomsich at theobroma-systems.com <mailto:philipp.tomsich at theobroma-systems.com>> wrote:
> Michael,
> 
>> On 28 Jan 2018, at 17:54, Michael Nazzareno Trimarchi <michael at amarulasolutions.com <mailto:michael at amarulasolutions.com>> wrote:
>> 
>> Hi
>> 
>> 
>> 
>> On 28 Jan. 2018 5:50 pm, "Philipp Tomsich" <philipp.tomsich at theobroma-systems.com <mailto:philipp.tomsich at theobroma-systems.com>> wrote:
>> > Linux uses the properties 'assigned-clocks', 'assigned-clock-parents'
>> > and 'assigned-clock-rates' to configure the clock subsystem for use
>> > with various peripheral nodes.
>> >
>> > This implements clk_set_defaults() and hooks it up with the general
>> > device probibin in drivers/core/device.c: when a new device is probed,
>> > clk_set_defaults() will be called for it and will process the
>> > properties mentioned above.
>> >
>> > Note that this functionality is designed to fail gracefully (i.e. if a
>> > clock-driver does not implement set_parent(), we simply accept this
>> > and ignore the error) as not to break existing board-support.
>> >
>> > Signed-off-by: Philipp Tomsich <philipp.tomsich at theobroma-systems.com <mailto:philipp.tomsich at theobroma-systems.com>>
>> > Tested-by: David Wu <david.wu at rock-chips.com <mailto:david.wu at rock-chips.com>>
>> > ---
>> >
>> > Changes in v2:
>> > - Fixed David's email address.
>> >
>> >  drivers/clk/clk-uclass.c | 118 +++++++++++++++++++++++++++++++++++++++++++++++
>> >  drivers/core/device.c    |   6 +++
>> >  include/clk.h            |  17 +++++++
>> >  3 files changed, 141 insertions(+)
>> >
>> 
>> Applied to u-boot-rockchip, thanks!
>> 
>> Is the right thing to do to apply a general change without more review?
> 
> Generally not, but this one has been floating around for a while, received
> testing and blocks a very lengthy series from David that has already been
> been submitted for the previous iteration.
> 
> Plus: it simply mimics the Linux behaviour in U-Boot.
> 
> In other words: this feels like something that needs to go into rc1 and with
> the window closing rapidly, I am between a rock and a hard place...
> 
> Understand the point but changes that are bounded on some subsystem should be picked up from the manteiner and accepted. I'm not against those changes because I have done a quick check but this break a bit what should be the correct flow.
> 
> Anyway David Wu is rockchip or theobroma because I have seen both emails ;)

David is Rockchip and I screwed up when adding the “Tested-by”.
So you may have seen both emails, but one was just my reflexive typing on
my end (I realised that, when I received bounces from our own mail-server).

Cheers,
Phil.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180128/72992141/attachment.sig>