Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock parents
Peter Griffin <[email protected]>
| Newsgroups | org.kernel.vger.linux-samsung-soc,org.infradead.lists.linux-arm-kernel,org.kernel.vger.linux-clk,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <CADrjBPrG7bo1i6YcxuwNKnYmKF=d-MXXMWSNdu+KfF7hhqQMXg@mail.gmail.com> |
Hi Krzysztof, On Tue, 30 Jun 2026 at 12:12, Krzysztof Kozlowski <[email protected]> wrote: > > On 30/06/2026 13:02, Peter Griffin wrote: > > Hi Alim, > > > > On Tue, 30 Jun 2026 at 04:53, Alim Akhtar <[email protected]> wrote: > >> > >> > >> > >>> -----Original Message----- > >>> From: Peter Griffin <[email protected]> > >>> Sent: Monday, June 29, 2026 6:02 PM > >>> To: Denzeel Oliva <[email protected]> > >>> Cc: Krzysztof Kozlowski <[email protected]>; Sylwester Nawrocki > >>> <[email protected]>; Chanwoo Choi <[email protected]>; > >>> Alim Akhtar <[email protected]>; Michael Turquette > >>> <[email protected]>; Stephen Boyd <[email protected]>; Brian > >>> Masney <[email protected]>; Rob Herring <[email protected]>; Conor > >>> Dooley <[email protected]>; [email protected]; linux- > >>> [email protected]; [email protected]; linux-arm- > >>> [email protected]; [email protected] > >>> Subject: Re: [PATCH v3 3/3] clk: samsung: exynos990: Fix PERIS gate clock > >>> parents > >>> > >>> Hi Krysztof & Denzeel, > >>> > >>> On Sat, 13 Jun 2026 at 13:36, Denzeel Oliva <[email protected]> > >>> wrote: > >>>> > >>>> Correct eight PERIS gate clock parents to match the hardware clock > >>>> tree and reorder the GIC mux parents so mout_peris_bus_user is the > >>>> default source. > >>>> > >>>> Signed-off-by: Denzeel Oliva <[email protected]> > >>>> --- > >>> > >>> Reviewed-by: Peter Griffin <[email protected]> > >>> > >>> @Krysztof: I was thinking, maybe we should establish a new rule/best > >>> practice for Samsung clock upstream submissions whereby patch > >>> contributors should link to the downstream cal-if code for the SoC after the -- > >>> - line. That would make reviewing the patches' correctness a bit easier, as the > >>> downstream cal-if code would be readily available to the reviewer. > >>> > >> We can leave this choice to the reviewer if they want to refer to downstream cal-if code. > > > > Generally I would like to, but I also don't have time to hunt around > > the internet for a downstream kernel tree. My rationale was that the > > submitter is most likely to know where the downstream code is, and is > > likely using it for the upstream clock implementation. So, linking to > > it as part of the submission should hopefully be fairly easy. > > > > If it is a Samsung SoC for which no public code is available that's > > fine. I didn't intend this to be a hard requirement: "you can't > > upstream x,y,z unless you link to the cal-if code". I meant it more as > > "best practice/guidance"; if the cal-if code is publicly available, > > linking to it would be a useful reference for reviewers. > > cal-if as vendor tree? Some contributors just base their work on > downstream GPL-compliance dumps from opensource.samsung.com, so not sure > how that link would work. Urgh, I see. My suggestion kind of assumed the downstream vendor tree had been pushed to a public Git repository, similar to how Google used to push their gs101 sources, for example: https://android.googlesource.com/kernel/google-modules/raviole-device/+/refs/heads/android-gs-raviole-mainline/drivers/soc/google/cal-if/ A link to a tarball for sure isn't as easy to just click through and take a look which is what I was hoping to achieve. Thanks for the link though, maybe that will come in useful at some point. Peter