[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <uvgeuxf7cpnlypif35lvzatdkwrnxynhvf43qw2nc2bvt3zcf3@75kkwp3raqfm>
Date: Wed, 17 Sep 2025 14:43:51 -0500
From: Bjorn Andersson <andersson@...nel.org>
To: Jonathan Cameron <jonathan.cameron@...wei.com>
Cc: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>,
Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>, Jishnu Prakash <jishnu.prakash@....qualcomm.com>,
jic23@...nel.org, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
agross@...nel.org, lumag@...nel.org, konradybcio@...nel.org,
daniel.lezcano@...aro.org, sboyd@...nel.org, amitk@...nel.org, thara.gopinath@...il.com,
lee@...nel.org, rafael@...nel.org, subbaraman.narayanamurthy@....qualcomm.com,
david.collins@....qualcomm.com, anjelique.melendez@....qualcomm.com,
kamal.wadhwa@....qualcomm.com, rui.zhang@...el.com, lukasz.luba@....com,
devicetree@...r.kernel.org, linux-arm-msm@...r.kernel.org, linux-iio@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, cros-qcom-dts-watchers@...omium.org,
quic_kotarake@...cinc.com, neil.armstrong@...aro.org, stephan.gerhold@...aro.org
Subject: Re: [PATCH V7 0/5] Add support for QCOM SPMI PMIC5 Gen3 ADC
On Fri, Aug 29, 2025 at 05:31:17PM +0100, Jonathan Cameron wrote:
> On Fri, 29 Aug 2025 12:20:45 +0300
> Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com> wrote:
>
> > On Fri, Aug 29, 2025 at 11:11:48AM +0200, Krzysztof Kozlowski wrote:
> > > On 29/08/2025 10:09, Dmitry Baryshkov wrote:
> > > > On Fri, Aug 29, 2025 at 09:12:59AM +0200, Krzysztof Kozlowski wrote:
> > > >> On Tue, Aug 26, 2025 at 02:06:52PM +0530, Jishnu Prakash wrote:
> > > >>> create mode 100644 drivers/iio/adc/qcom-spmi-adc5-gen3.c
> > > >>> create mode 100644 drivers/thermal/qcom/qcom-spmi-adc-tm5-gen3.c
> > > >>> create mode 100644 include/dt-bindings/iio/adc/qcom,pm8550-adc5-gen3.h
> > > >>> create mode 100644 include/dt-bindings/iio/adc/qcom,pm8550b-adc5-gen3.h
> > > >>> create mode 100644 include/dt-bindings/iio/adc/qcom,pm8550vx-adc5-gen3.h
> > > >>> create mode 100644 include/dt-bindings/iio/adc/qcom,pmk8550-adc5-gen3.h
> > > >>> rename include/dt-bindings/iio/{ => adc}/qcom,spmi-adc7-pm7325.h (98%)
> > > >>> rename include/dt-bindings/iio/{ => adc}/qcom,spmi-adc7-pm8350.h (98%)
> > > >>> rename include/dt-bindings/iio/{ => adc}/qcom,spmi-adc7-pm8350b.h (99%)
> > > >>> rename include/dt-bindings/iio/{ => adc}/qcom,spmi-adc7-pmk8350.h (97%)
> > > >>> rename include/dt-bindings/iio/{ => adc}/qcom,spmi-adc7-pmr735a.h (95%)
> > > >>> rename include/dt-bindings/iio/{ => adc}/qcom,spmi-adc7-pmr735b.h (95%)
> > > >>> rename include/dt-bindings/iio/{ => adc}/qcom,spmi-adc7-smb139x.h (93%)
> > > >>> rename include/dt-bindings/iio/{ => adc}/qcom,spmi-vadc.h (78%)
> > > >>> create mode 100644 include/linux/iio/adc/qcom-adc5-gen3-common.h
> > > >>>
> > > >>>
> > > >>> base-commit: 0f4c93f7eb861acab537dbe94441817a270537bf
> > > >>
> > > >> What's the base commit?
> > > >>
> > > >> git show 0f4c93f7eb861acab537dbe94441817a270537bf
> > > >> fatal: bad object 0f4c93f7eb861acab537dbe94441817a270537bf
> > > >
> > > > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?h=next-20250822&id=0f4c93f7eb861acab537dbe94441817a270537bf
> > >
> > > I see:
> > > "Notice: this object is not reachable from any branch."
> > >
> > > I guess you think this is 20250822?
> >
> > Well, it kinda is. It's a commit by Stephen, it has proper contents,
> > etc. next-20250822 is not a branch, but a tag, that's why you observe
> > the warning from gitweb. You can verify it yourself by manually pulling
> > the tag from the repo.
> >
>
> Kind of immaterial. Typically subsystem maintainers want a base of
> *-rc1 unless there is a dependency in their tree.
>
Basing the work on -rc1 is nice, but unless I'm missing something, patch
1 depend on changes that only exists in your -next branch and changes
that only exists in my (the qcom/dts) -next branch.
So, it seems that this can only be merged into next-20250822, not into
any actual maintainer's branch.
In the current form, the only sensible way I see to merge this is to get
a version freshly rebased on v6.18-rc1 (before we pile up any other
conflicts), we merge patch 1 into a immutable branch and then you take
the rest of the patches on top of this in your tree. Does this sound
reasonable? I'm open for suggestions...
Regards,
Bjorn
Powered by blists - more mailing lists