On Mon, Mar 18, 2024 at 05:20:50PM +0100, Krzysztof Kozlowski wrote: > On 17/03/2024 16:49, Conor Dooley wrote: > > On Sun, Mar 17, 2024 at 04:26:55PM +0100, Krzysztof Kozlowski wrote: > >> On 17/03/2024 16:23, Conor Dooley wrote: > >>> On Tue, Mar 12, 2024 at 07:50:35PM +0100, Krzysztof Kozlowski wrote: > >>>> Convert Samsung S3C6400/S3C6410 SoC clock controller bindings to DT > >>>> schema. > >>> > >>>> +description: | > >>>> + There are several clocks that are generated outside the SoC. It is expected > >>>> + that they are defined using standard clock bindings with following > >>>> + clock-output-names: > >>>> + - "fin_pll" - PLL input clock (xtal/extclk) - required, > >>>> + - "xusbxti" - USB xtal - required, > >>>> + - "iiscdclk0" - I2S0 codec clock - optional, > >>>> + - "iiscdclk1" - I2S1 codec clock - optional, > >>>> + - "iiscdclk2" - I2S2 codec clock - optional, > >>>> + - "pcmcdclk0" - PCM0 codec clock - optional, > >>>> + - "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410. > >>> > >>> I know you've only transfered this from the text binding, but what is > >>> the relevance of this to the binding for this clock controller? This > >>> seems to be describing some ?fixed? clocks that must be provided in > >>> addition to this controller. I guess there's probably no other suitable > >>> place to mention these? > >> > >> To make it correct, these should be made clock inputs to the clock > >> controller, even if the driver does not take them, however that's > >> obsolete platform which might be removed from kernel this or next year, > >> so I don't want to spend time on it. > > > > I think the comment should probably mention that these are the expected > > inputs, part of me thought that that was what you were getting at but I > > wasn't sure if instead they were inputs to some other IP on the SoC. > > I can change it, but just to emphasize: in half a year or next year we > will probably remove entire platform, thus also this binding. I know, I saw that. I don't really care what you do given the platform is being deleted and it is unlikely that anyone is actually going to be assembling a from-scratch dtsi for this SoC. On the other hand, if you're doing a conversion, even in this scenario, I think it should be clear. I didn't ack the patch cos I figured you were taking the patch via the samsung tree (and on to Stephen) yourself, but here: Acked-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> I'd rather argue about the definition of erratum instead of this :)
Attachment:
signature.asc
Description: PGP signature