On 18/07/2024 11:48, Jagadeesh Kona wrote: > > > On 7/18/2024 12:18 PM, Krzysztof Kozlowski wrote: >> On 07/07/2024 17:20, kernel test robot wrote: >>> tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master >>> head: 0b58e108042b0ed28a71cd7edf5175999955b233 >>> commit: 09ea421652a832083ea380a72addf383965f3682 [7766/10451] clk: qcom: camcc-sm8650: Add SM8650 camera clock controller driver >>> config: x86_64-allyesconfig (https://download.01.org/0day-ci/archive/20240707/202407072331.baglL4Sd-lkp@xxxxxxxxx/config) >>> compiler: clang version 18.1.5 (https://github.com/llvm/llvm-project 617a15a9eac96088ae5e9134248d8236e34b91b1) >>> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20240707/202407072331.baglL4Sd-lkp@xxxxxxxxx/reproduce) >> >> This and this: >> https://lore.kernel.org/all/202407072212.WptVaUDt-lkp@xxxxxxxxx/ >> >> are reports on linux-next. They were addressed to you/ >> >> Jagadeesh, how did you respond to public reports that your commit has >> build failures in linux-next? >> >> It reached now Linus' tree causing huge rant, unfortunately not in the >> direction we would like that rant to go. >> >> If you receive a report that your code does not even compile, it is YOUR >> DAMN MOST IMPORTANT TASK to address it IMMEDIATELY. >> >> I don't think such code should be ever accepted if contributors do not >> take responsibility for their commits. >> >> Krzysztof >> > > I initially submitted my change [1] by passing pdev to > qcom_cc_really_probe(). Seems like due to [2] which changed the > qcom_cc_really_probe() parameters from pdev to dev, my change was > updated from pdev to &pdev->dev while applying. > > When this issue was reported by kernel bot, I checked out the linux-next > tree but I didn't see this failure since the common change [2] was So tree is not bisectable but that's fine? How about telling the maintainer: listen, your tree is now broken? > already merged into linux-next. I apologize for not reverting the same > over the email thread. > > But change [2] was somehow missed and only my change [1] landed up in > Linus's tree, which led to this failure as Arnd described in [3]. Nothing was missed. That commit should have never been accepted to that branch, but, since it happened, you claim that dependency in clk drivers should as well go to DTS branch? No, that's just wrong. Mistake was that particular commit going to that branch and kernel robot told you that which you (and Bjorn, but Bjorn is busy so it is your job as contributor) should investigate. If that's how commits from quicinc look like I am afraid to take anything. I will be on my own, stuck with such issues, because for contributor "it is fine". Best regards, Krzysztof
