Re: [PATCH v4 0/3] clk: bcm: rpi: Add support for three more clocks

[Ivan Ivanov <iianov@suse.de>]

Hi,

> On 12 May 2022, at 11:53, Maxime Ripard <maxime@cerno.tech> wrote:
> 
> On Thu, May 12, 2022 at 11:10:00AM +0300, Ivan Ivanov wrote:
>> Hi,
>> 
>>> On 12 May 2022, at 10:57, Maxime Ripard <maxime@cerno.tech> wrote:
>>> 
>>> On Wed, May 11, 2022 at 08:10:50AM +0200, Stefan Wahren wrote:
>>>> Am 10.05.22 um 15:30 schrieb Maxime Ripard:
>>>>> Hi,
>>>>> 
>>>>> On Tue, May 10, 2022 at 01:20:18PM +0000, Guillaume Gardet wrote:
>>>>>> May I ask what's the status/plan of  this patch series?
>>>>> As far as I know it hasn't been merged yet.
>>>>> 
>>>>>> It seems it has not been merged yet, and I know we are a bit late in
>>>>>> the 5.18 schedule, but I think this is a good fix for 5.18.
>>>>> Fix for what? I don't think this series fix any bug?
>>>> 
>>>> This seems to be a "fix" for the Frankenstone scenario: mainline kernel +
>>>> vendor DT
>>> 
>>> Did we ever support this?
>>> 
>>> I don't think we did, so even though it can be nice to improve that
>>> situation, I don't think it's worth sending this to stable
>> 
>> Yes, maybe not stable material, but considering support for devices
>> which are shipped with upstream Linux and vendor device tree blobs,
>> saved somewhere on them, should be pretty normal to expect, right?
> 
> Not really?
> 
> If the vendor in question uses a binding that has never been reviewed,
> accepted, and supported by upstream, then I don't see what upstream
> should be doing to accommodate for that situation?


Ok, let do not generalise this discussion too much :-)

I bringed above as example that some times device tree could not
be changed and it is provided by board supplier, not by Linux OS
supplier.

In this particular case vendor device tree blob is using standard 
clock bindings. Just upstream Linux clock driver don’t have support
for some of the clocks. This is what these patches fix.

Regards,
Ivan