On 7/18/2024 3:36 PM, Krzysztof Kozlowski wrote:
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.
Yeah, it's my bad that I did not point out this issue. I will be more
careful from next time. Thank you.
Regards,
Jagadeesh
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
